Weiter aus der Reihe pimp-up-your-tool.
Es ist wirklich ziemlich logisch aufgebaut:
Eclipse ist eine Sammlung an Plug-ins. Plug-ins haben haufenweise extension points. Z.B. gibt es einen extension point für Einträge in Kontext-Menüs von Ansichten. Da dockt man in dem plugin-xml seines eigenen plug-ins an.
<extension
point="org.eclipse.ui.popupMenus">
<objectContribution
objectClass="org.eclipse.core.resources.IProject"
id="de.axel.menu">
<action
label="Export Into Portal"
icon="icons/notes.gif"
class="de.axel.menu.ExportToDominoAction"
id="DirectAction"/>
</objectContribution>
</extension>
<extension
point="org.eclipse.ui.popupMenus">
<objectContribution
objectClass="org.eclipse.core.resources.IProject"
id="de.axel.menu">
<action
label="Import ConfigBuilder Output"
icon="icons/excelzeichen.gif"
class="de.axel.ImportXmlArtefactsAction"
id="DirectAction"/>
</objectContribution>
</extension>
Bei Guis und langläufigen Aufgaben, ist es oft gut die GUI und die langläufige Aufgaben (hier kopieren von files) in unterschiedliche Threads zu legen. Dafür gibts bei Eclipse extra Job Apis. Das ist einfacher als invokeLater() und invokeAndWait() in Swing. Für das rumhampeln mit Files gibts mit IFile, IResource, etc eigene Klassen. Bisher klappt alles.
Es ist in einem Aspekt auf jeden Fall sehr ähnlich wie Notes programmieren: Man programmiert auf Basis eines komplexen Produktes an wohl definierten Stellen ein paar Erweiterungen. Vom unterliegenden Produkt (Eclipse oder Notes) ist man sehr abhängig und beide haben sicher noch Tücken, die ich nicht kenne. Vorteil ist aber, dass man da im Idealfall nur noch seine eigene Businesslogik in etwas einklinkt, dass wohlgetestet ist, gut funktioniert, den Anwendern vertraut, usw.
Aber das weiss eh jeder.
Gruß Axel
Die Erfahrungen bleiben weitgehend positiv.
Ein bischen ein gotcha war, dass man tatsächlich jedes genutzte jar im plug-in xml, Abteilung runtime anmelden muß. Bisher sind das.
<runtime>
<library name="integration_tool.jar">
</library>
<library name="lib/dom4j-1.6.1.jar">
<export name="*"/>
</library>
<library name="lib/domingo-1.1.jar">
<export name="*"/>
</library>
<library name="lib/jaxen-1.1-beta-8.jar">
<export name="*"/>
</library>
<library name="lib/Notes.jar">
<export name="*"/>
</library>
</runtime>
Classloader Probleme in Java sind natürlich immer Sch... .
Was z.Zt. ziemlich verwirrend ist, ist zu kontrollieren, wo meine extensions landen.
<extension
point="org.eclipse.ui.popupMenus">
<objectContribution
objectClass="org.eclipse.jdt.core.IJavaProject"
id="com.ibm.jdg2e.resources.programming.menu">
<action
label="Import ConfigBuilder Output"
icon="icons/excelzeichen.gif"
class="de.aja.eip.integration_tool.interact.ImportXmlArtefactsAction"
id="DirectAction"/>
</objectContribution>
</extension>
Dafür muss man aber erst mal wissen, wie extension class und Object class heissen. Und das hat jetzt 2 Stunden gedauert.
V.a. die Objectclass org.eclipse.jdt.core.IJavaProject find ich schwer herauszufinden. Weiss auch nicht, wo das dokumentiert ist. ???
ZUR Zeit behelfe ich mir damit, dass ich mir die plug-in xmls von mir bekannten plug-ins anschaue. Eclipse selbst ist mir noch zu verwirrend.
Es gibt jedenfalls Tonnen von extension points und object classes von object contributions, die regeln, wo sich meine Erweiterung reinpluggt.
Falls jemand dafür eine gute Doku kennt, immer her damit.
And now the weird part:
46 Zeilen xml, um eine einfache hide when Funktionalität zu implementieren:
Das ist aus dem plug-in.xml von org.codehaus.xfire.eclipse.ui_1.0.0.xfire112.jar
<extension
point="org.eclipse.ui.popupMenus">
<objectContribution
adaptable="true"
id="org.codehaus.xfire.eclipse.ui.xfireProject"
objectClass="org.eclipse.core.resources.IProject">
<visibility>
<and>
<objectState
name="nature"
value="org.eclipse.jdt.core.javanature"/>
<objectState
name="nature"
value="org.codehaus.xfire.eclipse.xfirenature"/>
</and>
</visibility>
<action
class="org.codehaus.xfire.eclipse.ui.popup.actions.AddRemoveNature"
enablesFor="+"
icon="icons/x16.png"
id="org.codehaus.xfire.eclipse.ui.actions.removeNature"
label="%popup.menu.nature.remove"/>
</objectContribution>
<objectContribution
adaptable="true"
id="org.codehaus.xfire.eclipse.ui.noXfireProject"
objectClass="org.eclipse.core.resources.IProject">
<visibility>
<and>
<objectState
name="nature"
value="org.eclipse.jdt.core.javanature"/>
<not>
<objectState
name="nature"
value="org.codehaus.xfire.eclipse.xfirenature"/>
</not>
</and>
</visibility>
<action
class="org.codehaus.xfire.eclipse.ui.popup.actions.AddRemoveNature"
enablesFor="+"
icon="icons/x16.png"
id="org.codehaus.xfire.eclipse.ui.actions.addNature"
label="%popup.menu.nature.add"/>
</objectContribution>
</extension>
Wie kann man nur so dumm sein, darauf nicht zu kommen.
Schliesslich gibts neben dem <visibility> nur <filter> und <selection> für Funktionalität, die ich erstmal unter dem zugegeben etwas grobkörnigen Begriff hide-when subsumiere. ;D
Ende gut alles gut. Und xml ist wirklich der absolute Burner zur Deklaration von Boolescher Logik:
<and>
<objectState
name="nature"
value="org.eclipse.jdt.core.javanature"/>
<not>
<objectState
name="nature"
value="org.codehaus.xfire.eclipse.xfirenature"/>
</not>
</and>
</visibility>
Ich kann das jetzt gut auf meinen eigenen Bedarf anpassen.
Am Wochenende werd ich ein kleines Programm schreiben, dass mir jederzeit sämtliche plugin.xml von meiner Festplatte scanned und in ein großes File packt :-) Die Dinger beginnen für mich eine Bedeutung zu gewinnen wie Gold-Nuggets in Klondike für Dagobert Duck.
Ein Vorteil von openSource ist wirklich, dass jederzeit geschaut werden kann was andere bereits gemacht haben.
Gruß Axel
Eine unschuldiges
throw new RuntimeException("test-Exception");
java.lang.RuntimeException: test-Exception
at com.eip.cbeed.integration_tool.interact.ImportXmlArtefactsAction.doImport(ImportXmlArtefactsAction.java:246)
at com.eip.cbeed.integration_tool.interact.ImportXmlArtefactsAction.createDirectly(ImportXmlArtefactsAction.java:163)
at com.eip.cbeed.integration_tool.interact.ImportXmlArtefactsAction.run(ImportXmlArtefactsAction.java:145)
at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:254)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
at org.eclipse.core.launcher.Main.run(Main.java:977)
at org.eclipse.core.launcher.Main.main(Main.java:952)
Axel
Tja. Und irgendwann verlässt man die Grundschule und schaut sich in den eclipse-plugin Foren um.
Es gibt ein Webinterface sowie eine nach Themenbereichen detailliert untergliederte Suche.
Ohne die hätte ich es nicht geschafft:
http://dev.eclipse.org/newslists/news.eclipse.tools.jdt/msg01000.html
So macht man programmatisch aus einen "normalen" Ordner einen Source-Folder, Bestandteil des Classpath des Projekts.
Als Beispiel dafür, dass ich manche Teile für historisch gewachsen halte. Geht aber. Oder besser: Geht nur, wenn man weiss, wo man nachschauen könnte und selbst dann braucht es ein wenig für die Suche.
// Add a folder to the classpath.
// IJavaProject jProject = project.getProject();
//1. create the folder (new File()...)
//2. Obtain a reference to your project (as IProject)
//3. Obtain a reference to your java project (as IJavaProject)
//4. Fetch e.g. the raw classpath with getRawClasspath() (on IJavaProject)
//5. Add your new entry (set the type to IClasspathEntry.CPE_SOURCE) to the
//previously fetched classpath array.
//6. Set the new raw classpath on your IJavaProject.
//folder.getR
IJavaProject jProject = JavaCore.create(project);
IFolder folder = project.getFolder("/src1");
IPath newPathEntry = folder.getFullPath();
IClasspathEntry[] cpEntries = jProject.getRawClasspath();
/*
for (IClasspathEntry cpEntry : cpEntries) {
System.out.println("cpEntry=" + cpEntry);
}
*/
IClasspathEntry pSourceEntryNew = JavaCore.newSourceEntry(newPathEntry);
List <IClasspathEntry> pEntriesList = new ArrayList(Arrays.asList(cpEntries));
pEntriesList.add(pSourceEntryNew);
IClasspathEntry[] cpEntriesNew = new IClasspathEntry[cpEntries.length + 1];
pEntriesList.toArray(cpEntriesNew);
jProject.setRawClasspath(cpEntriesNew, null);
Tja. Und irgendwann verlässt man die Grundschule
Tja_2. Und am Folgetag fällt einem auf, dass man wieder in den Kindergarten zurücksollte.
Einen Array um 1 Mitglied zu erweitern geht natürlich mit Systems.arraycopy und nicht mit der Unendlichen Geschichte da oben. ::)
IJavaProject jProject = JavaCore.create(project);
IPath newPathEntry = folder.getFullPath();
IClasspathEntry[] cpEntries = jProject.getRawClasspath();
/*
* for (IClasspathEntry cpEntry : cpEntries) {
* System.out.println("cpEntry=" + cpEntry); }
*/
IClasspathEntry pSourceEntryNew = JavaCore.newSourceEntry(newPathEntry);
// if a sourcefolder with the same path does allready exist, return
for (IClasspathEntry cpEntry : cpEntries) {
if (cpEntry.getPath().equals(pSourceEntryNew.getPath())) {
return false;
}
}
// add the new sourceFolder at the 1st position.
IClasspathEntry[] newCPEntries = new IClasspathEntry[cpEntries.length + 1];
System.arraycopy(cpEntries, 0, newCPEntries, 1, cpEntries.length);
newCPEntries[0] = pSourceEntryNew;
jProject.setRawClasspath(newCPEntries, null);
return true;
bzgl. rechtes Maustastenmenü: Meinst du folgendes?
// create context menu
MenuManager manager = new MenuManager();
Menu menu = manager.createContextMenu(viewer.getControl());
viewer.getControl().setMenu(menu);
manager.add(new UnrelateCiContextAction(viewer));
Dies ist der Kot um ein Kontextmenü einzubinden. So kannst du eine ganz normale Action einbinden.
Vielleicht so ähnlich oder ganz anders.
Ich hab die Kontextmenüs jetzt so:
<extension
point="org.eclipse.ui.popupMenus">
[...]
<!-- 1. -->
<objectContribution
id="com.eip.cbeed.programming.menu"
objectClass="org.eclipse.jdt.core.IJavaProject">
<visibility>
<and>
<objectState
name="nature"
value="org.eclipse.jdt.core.javanature"/>
<objectState
name="nature"
value="com.eip.cbeed.eipNature"/>
</and>
</visibility>
<action
label="Export Into Ergo Portal"
icon="icons/notes.gif"
class="com.eip.cbeed.interact.ExportToDominoAction"
id="Project"/>
</objectContribution>
<!-- 2. -->
<objectContribution
id="com.eip.cbeed.programming.menu"
objectClass="org.eclipse.core.resources.IFolder">
<action
label="Export Into Ergo Portal 2"
icon="icons/notes.gif"
class="com.eip.cbeed.interact.ExportToDominoAction"
id="Folder"/>
</objectContribution>
<!-- 3. -->
<objectContribution
id="com.eip.cbeed.programming.menu"
objectClass="org.eclipse.core.resources.IFile">
<action
label="Export Into Ergo Portal 3"
icon="icons/notes.gif"
class="com.eip.cbeed.interact.ExportToDominoAction"
id="File"/>
</objectContribution>
[...]
</extension>
Praktisch in 3facher Ausführung. Das oberste ist für rechte Maustaste/Projekt sichtbar, das 2. für rechte Maustaste/Folder und die 3. und letzte für rechte Maustaste/File.
Das funktioniert auch soweit. Das Problem ist nur, dass ich nur die erste Aktion schön verborgen bekomme für Projekte, die nicht EIP Nature haben. Bei den anderen Aktionen klappt das nicht. Die sind dann in allen Projekten sichtbar und das soll nicht so sein.
Diese 3 popup Extensions rufen jeweils automatisch die Methode dieser Klasse auf. Nach der ID (s. action.id im xml):
public class ExportToDominoAction extends ActionResourceAction implements
IViewActionDelegate, IWorkspaceRunnable {
[...]
public void run(IAction action) {
LogHelper.logInfo("run(IAction action) called [action=" + action + "]");
if (action.getId().equals("Project")) {
project = getIProject(this.selection.getFirstElement());
doExport();
} else if (action.getId().equals("Folder")) {
IFolder folder = (IFolder) this.selection.getFirstElement();
project = folder.getProject();
} else if (action.getId().equals("File")) {
IFile file = (IFile) this.selection.getFirstElement();
project = file.getProject();
}
zurück zu RCP: ich kriege keinen LoginDialog hin :'( >:(
In meiner Application (IPlatformRunnable) möchte ich vor Erstellen der Workbench eine Authentifizierung haben:
public Object run(Object args) {
WorkbenchAdvisor workbenchAdvisor = new ApplicationWorkbenchAdvisor();
Display display = PlatformUI.createDisplay();
if (authenticate(display)) {
int returnCode = PlatformUI.createAndRunWorkbench(display,
workbenchAdvisor);
if (returnCode == PlatformUI.RETURN_RESTART) {
return IPlatformRunnable.EXIT_RESTART;
} else {
return IPlatformRunnable.EXIT_OK;
}
} else
return IPlatformRunnable.EXIT_OK;
}
private boolean authenticate(Display display) {
Shell shell = new Shell(display, SWT.NONE);
LoginDialog loginDialog = new LoginDialog(shell);
loginDialog.setBlockOnOpen(true);
loginDialog.open();
Application.serverConnection = loginDialog.serverConnection;
return loginDialog.isAuthenticated;
}
Den Login-Dialog erzeuge ich mit dem VisualEditor, geht ganz einfach und sieht genau so aus wie ich mir das vorstelle...Nur leider wird er leer angezeigt wenn meine Anwendung ihn aufruft. Hier ist der Code:
public class LoginDialog extends TitleAreaDialog {
private Shell sShell = null; // @jve:decl-index=0:visual-constraint="0,0"
private Composite composite = null;
private Group logonGroup = null;
public boolean isAuthenticated;
private Label labelServer = null;
public ApiSDSession serverConnection;
public LoginDialog(Shell arg0) {
super(arg0);
// TODO Auto-generated constructor stub
}
/**
* This method initializes sShell
*
*/
private void createSShell() {
sShell = new Shell();
sShell.setLayout(new GridLayout());
sShell.setText("Login Dialog");
createComposite();
sShell.setSize(new Point(447, 260));
}
/**
* This method initializes composite
*
*/
private void createComposite() {
composite = new Composite(sShell, SWT.NONE);
composite.setLayout(new GridLayout());
createLogonGroup();
}
/**
* This method initializes logonGroup
*
*/
private void createLogonGroup() {
logonGroup = new Group(composite, SWT.NONE);
logonGroup.setLayout(new GridLayout());
labelServer = new Label(logonGroup, SWT.NONE);
labelServer.setText("Label");
}
} // @jve:decl-index=0:visual-constraint="0,0"
Komisch ist, dass normalerweise immer createContentArea implementiert wird im TitleAreaDialog, aber der VisualEditor macht das leider anders. Ausserdem habe ich sonne komische JavaBean this im VisualEditor, die mir seit kurzem immer ein NullpointerException(null) anzeigt (der VisualEditor arbeitet aber normal weiter). Also alles Mist mit VE (ich habe übrigens Callisto 3.2) Was fehlt denn an meinem LoginDialog? Kann ich da was ergänzen oder wie schreibe ich den ohne Visual Dreck?