A common approach is to use a splash handler to manage login. Splash handlers execute after the workbench has been started.

Login logic can also be tied to JAAS, if you’re interested in that. Check out this link for more details:

http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/login_extensions.html

Hope this helps,

— Patrick

Thanks for the best practices! I hope I can use them down the track…

I am only starting with RCP/OSGi/Java actually. I come from a .NET Windows Forms /ASP.NET world.

The first hurdle I have encountered is authentication with a Login screen. I noticed I can’t access services until the workbench has been started, so I’m not sure what the normal “practice” is here. How do you do authentication with RCP?

Based on my tests, it appears that the new version of the bundle (from source) is included in the distribution. As a best practice, I would avoid having the bundle in both places, though.

— Patrick

Another question: when doing headless builds, are the plugins in the buildDirectory taken into consideration by eclipse with higher priority then the ones found in the eclipse/plugins directory.
Example:
1. I have deployed the de.inframe.synapse.client.jobmanager_3.0.0.beta-002.jar into eclipse/plugins.
2. In the buildDirectory the same plugin project exists.
When I run the build I the lines above in the log.

[java] [eclipse.buildScript] Bundle de.inframe.synapse.client.jobmanager:
[java] [eclipse.buildScript] Another singleton version selected: de.inframe.synapse.client.jobmanager_3.0.0.beta-002

Does this mean that eclipse will use the plugin found in its eclipse/plugins directory. If yes, why gets this plugin recompiled?

Thanks!
Diana.

It’s a common case to want to build on top of other resources that have already been built. And yes, moving these pre-built resources into your build target is the way to go. BTW, it’s generally not a good idea to use your Eclipse install as the build target (baseLocation property).

It’s much better to create a separate directory and unpack the RCP SDK, RCP Delta Pack, and whatever you need into it. It’s also a good idea to create the build target from scratch during a build because (as you’ve seen) it can vary from build to build.

As for the 2 plugins that it’s taking from the buildDirectory, I’m guessing these are neither of these is the plugin you’re trying to build. Is that right? Is there anything these two plug-ins have in common?

— Patrick

Regarding my building issue problem, I have tried out this solution. (I will explain it in very short steps, and I need somebody to review it :) )

1. in the build_directory/plugins update plugins that have been modified
2. copy all unmodified plugins to the headless-eclipse/plugins directory
3. run build (at this step all the plugins that eclipse finds in its “plugins” directory will be used in the build process i.e “Another singleton version selected” will appear for each unmodified plugin?- correct me if I’m wrong)

What do you think about the above steps? Will I manage to avoid the compiling step for the unmodified plugins?
———————————————————–

I have put in practice the steps described above and copied all of the jars generated by the feature build, unpacked them to eclipse plugins directory. For 2 plugins out of 62, eclipse doesn’t use the plugins from its directory but takes the 2 plugins from the buildDirectory :((
Could it be that the 2 jars for haven’t been correctly build. After what details should I look in order to find the cause?

Thank you!
Regards,
Diana.

Thank you very kindly for your answer, I have tried out your first suggestion on the build directory. More precisely I have changed the following 2 lines in the build.properties file.

topLevelElementType = plugin
topLevelElementId = de.inframe.synapse.client.framework

The compilation seemed to work OK but at the assamble-step I received the following error:

[java] init:
[java] assembleElement:
[java] Java Result: 13
[echo] BUILD FAILED
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\build.xml:27: The following error occurred while executing this line:
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\build.xml:92: The following error occurred while executing this line:
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\customTargets.xml:12: The following error occurred while executing this line:
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\allElements.xml:16: The following error occurred while executing this line:
[echo] C:\builds\workspace\de.inframe.synapse.client.builder.simple\featurebuilder\genericTargets.xml:134: The following error occurred while executing this line:
[echo] java.io.FileNotFoundException: C:\builds\featurebuilder\assemble.de.inframe.synapse.client.framework.all.xml (Das System kann die angegebene Datei nicht finden)

Do you have any clue why?

Thanks again,
Diana.

PDE Build can build a specific plug-in. You can use the topLevelElementType and topLevelElementId properties to set this up, and I imagine you could use variable substitution in an Ant script to build one or more plug-ins that have changed.

Whether this will work or not depends on your goals for the build. If you’re building to verify the process and run unit tests, this shouldn’t be a problem. If you’re building to deploy (e.g. to a p2 repository), then the feature version will need to be incremented every time a plug-in is built, even if this is only the qualifier section.

Another alternative might be to create more fine-grained features.

— Patrick

I use a feature-build that manages more then 60 eclipse plugins. When somebody makes changes on one plugin, the build process is triggered for all the plugins in the feature.
Do you know if there is a way to customize the headless builds in such a way that only the plugins changed through the last commit are re-build?

Thanks,
Diana.