Hi guys,
I am an experienced java developer who was "thrown" into the backend layer of an Eclipse RCP project some time ago. At first, I thought I was gonna enjoy it, since my expertise includes OSGi, but I was shocked to end up in an "un-mavenized" piece of work with one eclipse-plugin per external dependency. If you wanted to add an additional dependency an extra eclipse plugin had to be created, jar had to be stored in the lib folder (in the SVN as well), and what is more, MANIFEST.MF had to be created manually by hand! (sic!) At some companies that I know, that are even special job positions (called dependency configurators) where there is a special guy who's responsibility is to add a dependency to a RCP project whenever a new ticket is created…
Cutting the long story short, I was shocked how difficult it was to fully "mavenize" the project and to configure a proper dependency management in Eclipse RCP together with Tycho.
The problems that I met:
1.) not all dependencies are located in well-known p2 update sites
2.) not all dependencies are OSGi bundles
3.) pomDependencies consider -> solves the problem half-way only, since dependencies defined in such a way cannot be referenced in the target platform so the project does not compile in the Eclipse IDE
4.) if I use pomDependencies->consider I cannot include two versions of the same dependency (standard maven mechanism)
5.) then I (of course) played with the maven-bundle-plugin. I created a separate 3rd party project to automate it a bit, but it creates one bundle for all dependencies, it's not that flexible and its build cannot be included in the same reactor build than the Eclipse-RCP project itself, so the builds had to be invoked one after the other. I somehow managed to import it to Eclipse IDE so that everything works, but I got 10 calls a day from people who used to get compilation problems after adding a singe dependency to that construct (sic^2)
My conclusion was:
- pom first projects sucks (problems described above)
- manifest-first projects would rock, if only we had all dependencies in a generally available p2 site (which we of course did not have)
Basically, I read a lot of forums, blogs, etc, and people keep struggling with relatively simple things (that I have described above) all the time.
Here's a blog entry listing the problems (posted by somebody else):
http://bit.ly/PypQEy I followed the same path almost one year ago.
So, I decided to contribute a bit to the great job that you are doing with Tycho and I create a p2-maven-plugin - he link is here ->
https://github.com/reficio/p2-maven-pluginIt was supposed to be a remedy to the Eclipse-RCP/Maven/Tycho/IDE dependency management problems.
It's main goal is to:
- download all required dependencies (from maven repositories) to a local folder
- recognize which dependencies are not OSGi bundles and bundle them using the "bnd" tool (the ones that are bundles are simply copied)
- take all the files (now bundles) and invoke a P2 tool to generate the P2 site (with categories) that can be directly consumed by the Target Definition in the Eclipse IDE
I think that I create something that was described by Igor Fedorenko in this post:
http://www.eclipse.org/forums/index.php/mv/msg/6192/18769/#msg_18769Please see some example, how to use it: the following snippet will generate a sample p2-site (fetching all transitive dependencies and bundling jars that are not OSGi bundles).
<plugin>
<groupId>org.reficio</groupId>
<artifactId>p2-maven-plugin</artifactId>
<version>1.0.0-SNAPSHOT</version>
<executions>
<execution>
<id>default-cli</id>
<configuration>
<artifacts>
<artifact><id>commons-io:commons-io:2.1</id></artifact>
<artifact><id>commons-lang:commons-lang:2.4</id></artifact>
<artifact><id>commons-lang:commons-lang:2.5</id></artifact>
<artifact><id>commons-lang:commons-lang:2.6</id></artifact>
<artifact><id>org.apache.commons:commons-lang3:3.1</id></artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
The fetch of transitive dependencies may be disabled using the <transitive>false</transitive> option on the <artifcat> level.
The MANIFEST.MF directives may be specified using the <instructions>, known from the maven-bundle-plugin:
<artifact>
<id>commons-io:commons-io:2.1</id>
<transitive>false</transitive>
<instructions>
<Import-Package>*;resolution:=optional</Import-Package>
<Export-Package>*</Export-Package>
(…)
</instructions>
</artifact>
Finally, the default MANIFEST.MF can be regenerated and overwritten (specific Imports/Exports may be then specified) using the <override>true</override> option .
Then the generated site may be exposed using a jetty-plugin and consumed in the Eclipse IDE.
Please, see the examples section (I described everything there):
https://github.com/reficio/p2-maven-plugin#examplesI would like to ask you a few questions, since you guys are developers of Tycho:
- How do you like that plugin? Do you think it is of any good?
- What should be improved?
I am willing to contribute - and I think that the whole mechanism may be improved further. I was trying to invoke the plugin automatically before Tycho starts its project configurators:
http://dev.eclipse.org/mhonarc/lists/tycho-dev/msg00541.htmlhttp://dev.eclipse.org/mhonarc/lists/tycho-user/msg02103.htmlbut because of some Maven/Plexus limitations it was not that simple. It's impossible now to invoke any Maven logic before Tycho, there are some problems with sharing classes across class-loaders.
My perfect case would be if the plugin was invoked seamlessly by Tycho during the compilation, so that the generated p2-site is automatically added to the Tycho repositories.
Then the perfect case would be if this repository could be referenced from Eclipse IDE, so that the project compiles in the IDE without any duplication in the dependency handling.
Right now, it's not that simple since the local-folder "repository" is not handled properly.
I would be very grateful for any comments.
Regards,
Tom Bujok
http://www.reficio.org_______________________________________________
tycho-dev mailing list
tycho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-dev
