Use Tycho

[GoogleCodeExporter]

Automate the build with Tycho: update site generation and deployment, and 
optionally export an RCP application.

Original issue reported on code.google.com by harmathdenes on 27 Apr 2014 at 4:55

[thSoft]

This is also also necessary to automate running the tests on each build.

[nittka]

Note that recent Xtext versions come with a wizard that creates a project infrastructure for maven (and gradle). Also since 2.9 there are grammar features (fragments and conditional alternative; see http://zarnekow.blogspot.de/2015/10/the-xtext-grammar-learned-new-tricks.html) that might be helpful for getting rid of backtracking. My next big Elysium TODO is looking into these features, so maybe an update to a new Xtext version makes sense, anyway. With that the mavenization of Elysium comes almost for free (migrating the old code to the new project infrastructure).

Mavenizing the commons project is necessary anyway. But what's the most reasonable approach for Elysium.

• do it for the current Xtext 2.7 code base (possible still having to migrate later)
• migrate to Xtext 2.10 immediately (even if the new grammar features will not help with the backtracking issue in the end)

[thSoft]

Yes, I think we should upgrade to Xtext 2.10 before doing this! I'm reopening that issue.

[nittka]

As described in #85, the maven build currently does not yet work because of the commons project dependency. Further open issues wrt. the mavenization:

• I did not merge the original target definition and the generated one in the new (distict) target project.
• I did not merge the original category.xml in the old feature project (which I simply copied to the new one) and the one contained in the new repository project.

[thSoft]

What if we also included the eclipse-commons Maven modules in the whole multi-module build?

[nittka]

That's certainly an option. Versioning will be a problem, though - keeping pom and manifest versions in synch will not work out of the box. As far as I know, the tycho plugin transfers the parent version to all modules, so that different versions for Elysium and Commons will be harder to maintain.

I was thinking of a build that assumes a local update site to exist. Check out both projects, first build commons including an update site project, then build Elysium. I don't know whether an update site can be defined via a variable. In this case the variable could point to the real update site by default and be redirected to a local update site for development...

[thSoft]

Parent versions can be overriden in inheriting modules, so I don't think versioning will be a problem.

Variables can be used in repository-based Tycho target platform configurations, but it would be better to work from a target definition file (which can be autogenerated from the Oomph targlet task), and variables are not supported there. That's why I thought of including eclipse-commons in the the same multimodule build as elysium.

[nittka]

I was referring to the tycho versions plugin, which facilitates keeping pom and manifest versions in synch. I am fine with your approach.

Another question: I'd like to keep a preXtext210 branch of Elysium and Commons open for some time - not for active development, but in case issues were introduced by the migration that simplifies setting up parallel installations. The Oomph-setup could support both branches, using appropriate Xtext versions etc. for each one. I could open these branches in my clone and point directly to those from the setup or we both have these branches and the setup can use whatever location is entered by the user.