7 Replies Latest reply on Mar 2, 2006 4:04 PM by Scott Stark

    Maven - migration plan

    Ruel Loehr Novice

      I've put together a roadmap, which is viewable here:

      http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&pid=12310081&fixfor=12310674

      The initial plan of action is the following:

      Maven Build 1.1

      1) Setup a cruisecontrol instance to monitor a maven build in head
      2) Move the poms into each module of head, updating them as necessary
      3) Update dependencies, their poms, ensuring transitive dependencies, license info, descriptions and such are defined
      4) Create a distribution project which can build the AS distribution from module artifacts
      5) Setup a mavenized testsuite (wrap existing testsuite)

      After completion of these steps, head will be able to be built and the testsuite will be executable. License information will compiled, and poms will also be validated. I can begin work on this immediately.

      After this revision is implemented and stabilized, we can begin adding additional functionality.


      Maven Build 1.2

      1) Modularize testsuite creating plugin which can execute each series of tests
      2) Additional plugin creation - any ant custom ant tasks can be wrapped into a plugin (e.g docbooks, retroweaver, aopc)

        • 1. Re: Maven - migration plan
          Scott Stark Master

          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.

          • 2. Re: Maven - migration plan
            Ruel Loehr Novice

            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?

            • 3. Re: Maven - migration plan
              Scott Stark Master

              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.

              • 4. Re: Maven - migration plan
                Scott Stark Master

                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.

                • 5. Re: Maven - migration plan
                  Adrian Brock Master

                  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
                  releases.

                  • 6. Re: Maven - migration plan
                    ryan.campbell Expert

                    So:

                    1. refactor common
                    2. create guide for leads to restructure
                    3. deploy existing maven build files
                    4. leads restructure projects using guide over time

                    • 7. Re: Maven - migration plan
                      Scott Stark Master

                      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.