Details
-
Sub-task
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.2.0
-
None
-
Maven 2.0.x
Description
While trying to create a complex custom Jetspeed Portal project for a customer using the new Maven-2 build procedure and plugins, it became quickly clear that the current build configuration still isn't good enough.
Especially merging in and managing custom configurations outside of the standard Maven-2 project definitions while keeping everything within the same source (control) tree turned out to be almost impossible.
Furthermore, the current jetspeed-db and jetspeed-deploy Maven-2 plugins can only (and rightfully so) properly be used outside the standard Maven build lifecycle (e.g. as standalone plugins).
This turned out to become difficult to manage as for our custom project we had several additional tasks which needed to be plugged in during the database and deploy integration tasks.
Getting that to work with standalone plugins would mean further extending (or rather: exploding) the configuration options of the plugins as they shouldn't be hooked into a normal Maven lifecycle build.
After several days painfully trying to get this working I gave up and started to rethink the whole build process anew.
The only logical conclusion I could come up with was: we shouldn't try to execute target environment related integration tasks, which have nothing to do with the "normal" Maven artifact build process,
with the same project definition as used for this normal/standard Maven build process.
What we really need is an independent (build) lifecycle to which we can attach our specific integration tasks, so that Maven lifecycle handling can be leveraged in a standard way, but without
interfering with the normal artifact build process.
After several days research (diving deeply in the Maven core and reviewing what other plugins are using), I decided to start writing a new plugin, called jetspeed:mvn, to handle this requirement.
The jetspeed:mvn plugin is based upon and expand on the Maven invoker plugin which can automatically execute additional (and separate/standalone) Maven project files during the integration-test lifecycle phase.
While we don't need or want the exact same behavior as the Maven invoker plugin, the core functionality of executing other Maven projects actually can provide us that.
After a full weeks work, I finally got it working exactly how I wanted and with the flexibility I think very much is need for the myriad of different environments custom Jetspeed Portal projects can be used for.
As implementing and using this new jetspeed:mvn plugin (again) causes quite a few changes to the current Maven-2 build configuration, and I still hadn't written much (if any) documentation for using it yet anyway,
I decided to finally start documenting it properly now.
While not everything is documented yet, and I'm about to leave on holiday so I won't be able to complete it either, I think the new documentation really covers a lot of ground already.
So, I've decided to commit the changes for the new build configuration anyway now and publish the current docs (written as xdoc for the maven sub project) temporarily online here:
http://people.apache.org/~ate/jetspeed-2.2-maven-plugins/index.html
I also documented the rationale for these new changes to the build system here:
http://people.apache.org/~ate/jetspeed-2.2-maven-plugins/the-need-for-a-custom-lifecycle.html
As soon as I'm back from holiday (in 3 weeks time), we should start discussing how/where to bring new documentation for Jetspeed-2.2 online.