You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2008/07/18 21:14:31 UTC
[jira] Created: (JS2-895) Provide a solution to seperate the
Jetspeed build integration tasks (configuration,database,deploy) from the
standard Maven-2 build lifecycle
Provide a solution to seperate the Jetspeed build integration tasks (configuration,database,deploy) from the standard Maven-2 build lifecycle
---------------------------------------------------------------------------------------------------------------------------------------------
Key: JS2-895
URL: https://issues.apache.org/jira/browse/JS2-895
Project: Jetspeed 2
Issue Type: Sub-task
Components: Project Build
Affects Versions: 2.2
Environment: Maven 2.0.x
Reporter: Ate Douma
Assignee: Ate Douma
Fix For: 2.2
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Resolved: (JS2-895) Provide a solution to seperate the
Jetspeed build integration tasks (configuration,database,deploy) from the
standard Maven-2 build lifecycle
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma resolved JS2-895.
---------------------------
Resolution: Fixed
Implemented
> Provide a solution to seperate the Jetspeed build integration tasks (configuration,database,deploy) from the standard Maven-2 build lifecycle
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JS2-895
> URL: https://issues.apache.org/jira/browse/JS2-895
> Project: Jetspeed 2
> Issue Type: Sub-task
> Components: Project Build
> Affects Versions: 2.2
> Environment: Maven 2.0.x
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.2
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org