Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Please, make Tycho 1 more Maven friendly

I think you missed the origin objectives of Tycho


On Wed, Nov 2, 2016 at 3:43 PM, Charlie Mordant <cmordant1@xxxxxxxxx> wrote:

I've been using Maven for about 10 years from now and Tycho for about 2.
Concerning my background, I've been a JavaEE applicative architect for about 7 years and an Eclipse plugin developer for 4, I'm an Eclipse modeling/Polarsys/Amalgam and Apache commiter.

For the context, my company wants  that I migrate their infrastructure from buckminster to Tycho.

First, I want to thank you to have brought the MVN world to Eclipse because the old way was...

But, IMHO, the way Tycho works for now is not really Maven friendly, and there are many improvments that should be done in order to be really 'production ready'.

Here are some advices on what should be THE Maven based Eclipse tooling. If you're interested in the idea, I could fill as many bugzilla tickets as there are advices in this mail.

* First, that tooling should be more Maven than Eclipse:

* * It should have a Maven structure (src/main/java, src/main/resources, src/tests/java... outputing to target/classes, etc...): this structure encourages to make unit tests, TDD and so on, which could be helpful for the Eclipse community.

* * Based on Archetype generation (not hand made).

* *  Additional (re)sources directories should be managed via the build-helper plugin, not the

* * Packaging must be jar: no need to have an extension (at least for plugin, feature and product, also build-helper with attach-artifacts goal could be nice for other formats). Extensions are really problematic in many ways: for example, referencing eclipse-plugin dependencies is harder and does not works well within plugins (see the number of threads on the xtend-maven-plugin in the xtext forum).

* *  Dependencies should be managed via pom.xml not Manifest.
Manifests are really hard to maintain and can easily be generated with maven-bundle-plugin or bnd-maven one. This could boost the osgi adoption, also the number of eclipse contributors.
For the non-mavenized deps (p2 ones), we could for example imagine a dummy groupId (org.eclipse.tycho.p2.plugin) with the SymbolicName as artifactId.

* * Tycho should be compatible with all maven plugins (maven-release plugin, maven source-pg, surefire, failsafe, site...)

* * Tycho surefire plugin should become an extension of pax-exam (like the karaf extension), it should just provide a way to reference a target platform for executiong them.

* Concerning the minor improvements:

* * tycho-Surefire-plugin should be executed during the integration-test-phase, not the test one, because you're launching integration-tests. As an addition, it would allow to run pre-it scripts and post-it ones
* * tycho-surefire should be renamed tycho-failsafe...
* * do not define an arbitrary  ${tycho.testArgLine}, force the user to be aware about it (i.e. for jacoco) and never reference it in your doc.
* * tycho-version is useless as maven-release is far better...

* So to sum up, tycho should just IMHO:

* * Give the ability to reference a p2 layout repository and express tp/ feature/p2 plugin reference within module dependency.(including a Manifest version to Maven -SNAPSHOT converter)
* * Provide a target platform reference extension for pax-exam, also maybe a kind of eclipse extension point reference on the IT test.
* * Maybe defining a product-maven-plugin or oomph-maven-plugin (like the kar-maven-plugin does) in order to ease product packaging.
* * Provide a deploy plugin/wagon extension to release as p2 site
* * And let Maven do its job, e.g. all the remaining.

If you want to see a nice osgi support within Maven, you can take a look at this example (made for Karaf):

​Best regards,​

Charlie Mordant

Full OSGI/EE stack made with Karaf:

tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit


"Legacy code" often differs from its suggested alternative by actually working and scaling.
 - Bjarne Stroustrup

Back to the top