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

Hi Jeff,

That's why the title of my mail was 'Make Tycho "1"...', the origin objectives of Tycho (which I guess was to avoid already defined eclipse projects to switch to maven without modifying too much their plugin architecture) may have changed over the time. Tycho is now the only way to build Eclipse projects.

If we want to keep Eclipse at a certain level of maturity, quality and so on, we should provide a way to contribute the easiest and more efficient way.

Not being able to use mvn site, mvn release, and not being able to contribute to the generate-resource phase to automatically generate manifest are making that projects maturity level difficult (nor to say prevents).
Executing integration test during the maven test phase (which make the jacoco integration painful), not having a src/test folder do not encourage users to make tests (how many Eclipse project do have unit tests? I can bet on a 0 only due to the non-standard Maven structure), which are leading to bugs also limit the number of contributors.
Finally, not supporting a mix between Maven-layouted repos (expressed in pom.xml) and p2 layouted ones (expressed in manifest) do not encourage knowledge share and cots reuse between communities: I would be happy to use EMF/Xtext in some of my JavaEE (or Karaf) projects as well as I would like to make/consume some ActiveMQ queues/topics in my Eclipse (or even using Spring).

I didn't want to be rude or nothing giving my opinion, don't take it personally, I'm just trying like you to improve things.


2016-11-10 8:04 GMT+01:00 Jeff MAURY <jeffmaury@xxxxxxxxxxxxx>:
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

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

Charlie Mordant

Full OSGI/EE stack made with Karaf:

Back to the top