The one thing I want to have a discussion on before just converting head to maven2 is how the module structures are likely to evolve. We have discussed the current scripting hacks that exist to get wround the one-to-many src/artifact mismatch, but not how to address this. One option is a custom plugin, another is refactoring to better algin with maven2 conventions. Agreement on what the direction is short and long term is needed.
A related issue is that I also want a howto use maven2 for jboss projects doc as qa should not be doing all the conversion work. Each project needs to understand the build sufficiently do use it correctly.
In order to address the one to many artifact issue the following action plan can be used:
1) Introduce the maven build using a short term scripting solution to create the required artifacts
2) Document the preferred project layout regarding artifact handling (1 artifact per project) in the dev guide
3) Publish to project leads
4) Initiate refactoring with the common project (record steps as guide for other projects)
5) Audit other modules, open JIRA's for those which require refactoring.
6) Completion of project refactoring. All modules produce single artifacts. (Long term solution)
I suggest introducing the build first as the refactoring process will be quite time consuming.
The other caveat to this is that it might make sense to perform the refactoring after both head and 4.0 have been cut over to the new build system for backporting ease.
Taking that thought one step further, will we include 3.2 in this mix or consider it legacy?
We need a basic agreement on direction and usage before converting head along with a guide. I expect the refactoring will be done by the project teams over time so I want the direction to be clear.
One thing we definitely should do before switching jboss-head to mave is to refactor the common module. I'll start another topic for this.
I think a correct structuring of the projects will remove some of these artificat problems.
I don't think we should change 3.2.x
It is now pretty much in maintenace mode, it doesn't make sense to potentially
break this build when only a small number of fixes will be backported to future SPx
1. refactor common
2. create guide for leads to restructure
3. deploy existing maven build files
4. leads restructure projects using guide over time
Yes, that is my view of how we need to tackle this.
Agree that we will not migrate this build to the 3.2 branch.