Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-dev] Improved dependency management in RCP/Tycho - (request for comments)


Thanks for your answer and sorry for my late reply.

Somehow, I have the feeling that we are not comparing apples with apples in this discussion. I understand your point that you have to work across the entire set of dependencies (modify, compile, run/debug)  so in your case the m2e wrapper bundler is the perfect match. It's not a common case, though, if you work on a custom RCP/Tycho project and you simply want to add a bunch of 3rd party dependencies such as commons, guava or mockito. You simply want to reference and use them in your project and then you want your project to compile in the console AND in the PDE. It's not a problem that they are statically included, since you hardly every want to modify them - and if so, it's no a problem to recompile and reinstall them to your local repo (or repository manager).

In order to provide you with more info about my solution (p2-maven-plugin) we could say that it does similar things that were provided by the nexus-p2-repository-plugin and the nexus-bundle-maker-plugin.
My stuff however:
- concentrates on 3rd party maven deps (not on eclipse plugins/features)
- supports source bundles (generates Eclipse-SourceBundles)
- fetches transitive dependencies (independently for every dependency -> not as a single dependency tree)
- enables the user to customize the bundler instructions (Import-Export packages)
- enables the user to overwrite the existing MANIFEST.MF (if required - not recommended though)

As I understand you all see the need of such tool since you created the aforementioned nexus artifacts. I cannot understand why not to go one step further and not to include such a thing in the Tycho/PDE build cycle so that everybody is happy? I am not trying to duplicate anything - I have hardly written my own code in the p2-maven-plugin. It's an integration and compilation of the aether, bnd-tool, maven-bundle-plugin, tycho-p2-extras-plugin and CategoryPublisher tools. I am just trying to fill the gap that I find really annoying in the Eclipse / Tycho / Maven ecosystem. If somebody has a really corporate background it's probably not a problem to have an instance of nexus, artifactory or to configure advanced bash scripts to generate bundles and then build and deploy p2 sites. I am, however, trying to be very pragmatic, think in a simplistic way, and look at the problem as I knew nothing about RCP, OSGi or Tycho - I want the simplest possible solution just like I was using Maven in a standalone app.

So (to repeat myself), the problems that I find annoying in the current setup:
Problem nr. 1): I setup a Mavenized RCP project, import it to Eclipse, add an dependency to the pom.xml (that part I am acquainted with), and a bummer - it compiles in the console, but I cannot import it in the IDE. How this poor people could understand in 5 minutes that they need complex p2 proxies and nexus-pro editions to add a simple mockito.jar to their project in an automated and repeatable way (so they don't have to generate the MANIFEST.MF themselves and commit the jar into the lib folder)?
Problem nr. 2): I want to customize the generation of the MANIFEST.MF for the dependencies that are not OSGi bundles, in case when the artifact is not an OSGi bundle. How can I do it know with the tycho wrapper invoked behind the scenes?
Problem nr. 3): I want to add two versions of the same dependency (for example commons-lang 2.2 and 2.6) to the same project and import 2 packages from two different versions (OSGi enables me to do it), but the tycho-maven dependency resolution does not support it, since maven will ignore one of them.

This is really a complex stuff to configure, and unless you are really experiences in Maven, OSGi and Tycho you simply cannot solve it. RCP and Tycho are really popular in the DACH region (Germany, Switzerland, Austria) - and I have attended many JUG/conference sessions about Tycho - but every person presents a custom/complex/proprietary solution how to solve the problem of 3rd party dependencies. Every presentation contains a point which sounds more or less like this: "Problems with 3rd party dependencies". Here another example (in german though, however you will understand the keywords: Probleme,  Third-Party):

My goal was to make the usage of tycho and PDE as simple as the usage of Maven and IDE (in a standalone app). I just simply want to create a project, import it to eclipse, add a dependency (no matter if located in an update site, no matter if it's an OSGi bundle), compile and run it. It should be as simple as that. 

So my proposal are as follows:
a.) external 3rd party dependencies are specified in the project descriptor (not as maven dependencies, to overcome the multiple version of the same artifact mismatch), generally speaking the pom-first tycho approach is not the best practice - so I would recommend using the manifest first approach
b.) Tycho build produces a referencable p2-update-sites somewhere in a local folder containing artifacts that are specified as 3rd party dependencies. The folder may be either in the project/target folder, or in the drive/.tycho folder (just like .m2). 
c.) the wrap of 3rd party dependencies that are not bundles should be customizable (import-export packages, etc.)
d.) resolution of the 3rd party dependencies should include transitive dependencies (like in maven)
e.) Tycho dependency resolver should be extended so that it may consume p2-update sites that are located in a local folder
f.) m2e tycho plugin should be modified so that it automatically adds the 3rd party local update sites to the target definition (it may be manually included by the user as well, since PDE already supports update sites located in a local folder).

Using this approach I can also easily debug these dependencies (without modifying them of course) - I have just tested it since p2-maven-plugin now supports the generation of the Eclipse-SourceBundles.
All of these could be easily done with my p2-maven-plugin (or anything else, but that's not the point), to make the eclipse-rcp, tycho, maven, PDE environment more user-friendly for the technology newcomers…

I would really appreciate to get some constructive responses (positive/negative) from the community on that topic. So far I have not got it.

Tom Bujok
Reficio™ - Reestablish your software!

On Aug 21, 2012, at 3:07 PM, Jason van Zyl wrote:

Without creating something that referenceable from a target definition, no. But I believe you're duplicating much of what already exists. 

In m2e for example it's already part of the target platform while developing so the wrapper bundle works great there (we install juno and install m2e and we have our target platform). The wrapper bundles have the distinct advantage of being able to run/debug projects you are working on from within the Eclipse workspace. The work we did creates a bridge between the Maven world and the Eclipse world through m2e (and the work done in PDE, the maven bundle plugin and m2e). I can work on Maven as a wrapper bundle with m2e seamlessly in the workspace. Our use case is a little different with m2e as working across the entire set of dependencies is important. Unfortunately Tycho/Maven just works entirely differently than PDE. I understand what you're trying to do where statically importing the Maven dependencies as part of the target definition is workable for you but seems not that much different than what's been done aside from making it referenceable from a target definition. 

Maybe there is a way you can augment what already exists by creating something using the wrapper bundle method that would allow it to be referenced in a target platform definition?
On Aug 20, 2012, at 3:52 PM, Tom Bujok wrote:


Thanks for your reply.   AFAIK  it will not work in this use-case:
- create a tycho RCP project
- declare a Maven dependency in pom.xml (with pomDependencies set to consider) 
- import project to Eclipse IDE (with m2Eclipse)

Or am I wrong?


tycho-dev mailing list

Back to the top