Les plug-ins de JDT comprennent un compilateur Java incrémentiel et par lots qui sert à générer des fichiers .class Java à partir d'un code source. Le compilateur ne fournit pas d'API directe. Il est installé comme générateur dans les projets Java. La compilation est déclenchée au moyen des mécanismes de génération standard de la plateforme.
Le mécanisme de génération de la plateforme est décrit en détail dans la rubrique relative aux générateurs de ressources.
En utilisant l'API de génération, vous pouvez compiler programmatiquement les fichiers source Java d'un projet.
IProject myProject; IProgressMonitor myProgressMonitor; myProject.build(IncrementalProjectBuilder.INCREMENTAL_BUILD, myProgressMonitor);
Pour un projet Java, cette instruction appelle le générateur de projet incrémentiel Java (avec les autres générateurs de projet incrémentiels qui ont éventuellement été ajoutés à la spécification de génération du projet). Les fichiers .class générés sont enregistrés dans le dossier de sortie indiqué. Dans le cas d'une compilation de lots entiers, tous les fichiers .class du dossier de sortie sont vérifiés pour assurer qu'aucun fichier périmé ne sera trouvé. Veillez à bien placer tous les fichiers .class pour lesquels vous ne disposez pas de fichiers source correspondants dans des dossiers de fichiers de classe distincts dans le chemin d'accès aux classes et non dans le dossier de sortie.
Les fichiers de ressources supplémentaires sont également copiés dans le dossier de sortie.
Vous pouvez contrôler les fichiers de ressource copiés à l'aide du filtre de ressources.
Par exemple, pour filtrer les fichiers se terminant par '.ignore' et les dossiers appelés 'META-INF', utilisez :
Hashtable options = JavaCore.getOptions();
options.put(JavaCore.CORE_JAVA_BUILD_RESOURCE_COPY_FILTER, "*.ignore,META-INF/");
JavaCore.setOptions(options);
Les noms des fichiers sont filtrés s'ils correspondent à l'un des modèles spécifiés. Des dossiers entiers sont filtrés si leur nom correspond à l'un des noms de dossier spécifié se terminant par un séparateur de chemin.
Vous pouvez également configurer les compilateurs incrémentiels et de lots pour ne générer qu'une seule erreur lorsque le fichier .classpath contient des erreurs. Cette option est définie par défaut et élimine la spécification de plusieurs erreurs, toutes généralement causées par un fichier jar manquant. Reportez-vous à l'option CORE_JAVA_BUILD_INVALID_CLASSPATH dans la rubrique JavaCore .
<?xml version="1.0" encoding="UTF-8"?>La syntaxe utilisée pour la tâche Ant javac se trouve dans la documentation sur les tâches Ant javac. L'adaptateur actuel prend en charge la tâche Ant Javac 1.4.1. La version 1.5 sera disponible lorsqu'Ant 1.5 sera publié.
<project name="compile" default="main" basedir="../.">
<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter"/> <property name="root" value="${basedir}/src"/> <property name="destdir" value="d:/temp/bin" /> <target name="main"> <javac srcdir="${root}" destdir="${destdir}" debug="on" nowarn="on" extdirs="d:/extdirs" source="1.4"> <classpath> <pathelement location="${basedir}/../org.eclipse.jdt.core/bin"/> </classpath> </javac> </target> </project>
L'API principale (core) du JDT définit un marqueur spécialisé (type "org.eclipse.jdt.core.problem") pour indiquer les incidents de compilation. Pour découvrir programmatiquement les problèmes détectés par le compilateur, vous devez utiliser le protocole de marqueurs standard de la plateforme. Reportez-vous à la rubrique Marqueurs de ressources pour des informations générales sur l'utilisation des marqueurs.
Le fragment de code suivant localise tous les marqueurs de problèmes Java dans une unité de compilation.
public IMarker[] findJavaProblemMarkers(ICompilationUnit cu)
throws CoreException {
IResource javaSourceFile = cu.getUnderlyingResource();
IMarker[] markers =
javaSourceFile.findMarkers(IJavaModelMarker.JAVA_MODEL_PROBLEM_MARKER,
true, IResource.DEPTH_INFINITE);
}
Les marqueurs de problèmes Java sont gérés par le générateur de projet Java ; ils sont supprimés automatiquement à mesure que les problèmes sont résolus et que la source Java est recompilée.
La valeur de l'ID du problème est définie par l'une des constantes indiquées dans IProblem . L'ID du problème est fiable mais le message est traduit et peut par conséquent changer selon l'environnement local par défaut. La description des constantes définies dans IProblem est explicite.
Une implémentation d'
IProblemRequestor
doit être définie pour regrouper les incidents détectés lors d'une opération Java.
Les copies de travail peuvent être adaptées à la détection des incidents si un élément
IProblemRequestor
a été fourni pour leur création. Pour ce faire, vous pouvez utiliser la méthode
reconcile. Exemple :
ICompilationUnit unit = ..; // obtention d'une unité de compilation
// création d'un demandeur pour le regroupement des incidents détectés
IProblemRequestor problemRequestor = new IProblemRequestor() {
public void acceptProblem(IProblem problem) {
System.out.println(problem.getID() + ": " + problem.getMessage());
}
public void beginReporting() {}
public void endReporting() {}
public boolean isActive() { return true; } // détecte les incidents si actif
};
// utilisation de la copie de travail pour conserver la source contenant l'erreur
IWorkingCopy workingCopy = (IWorkingCopy)unit.getWorkingCopy(null, null, problemRequestor);
((IOpenable)workingCopy).getBuffer().setContents("public class X extends Zork {}");
// déclenchement de la réconciliation
workingCopy.reconcile(true, null);
Vous pouvez ajouter une opération sur les incidents détectés dans la méthode acceptProblem(IProblem). Dans cet exemple, l'incident détecté est le suivant : Zork ne peut pas être résolu ou n'est pas une superclasse valide et son ID est IProblem.SuperclassNotFound.