My overall findings were based on the answers to these questions.
1) Would it work at all?
Yes, however it will not work ?out of the box?.
2) What customization would be necessary?
Customization in the form of plugins would be required at minimum for the handling of our modules with multiple source trees (src/main, src/jdk15).
According to one of the developers, Maven 2.0 supports the notion of profiles (e.g. a profile for compilation with JDK 1.4 and one for compilation with JDK 1.5, one for windows, ...) although neither documentation or user experiences regarding this feature are available as of yet. Depending on how it works, I would expect customization to be required here as well.
As I mentioned before, the documentation for the 2.0 release is quite sparse so I am making some best guesses based off of what I see in their 1.0 world, but it looks like there would be quite a bit of custom stuff required for the deployment end as well. In the 1.0 world they essentially write some custom targets to do things of this nature, which all look fairly ANT-ish.
From what I have seen in other projects which use Maven as a build (http://svn.cargo.codehaus.org/cargo/trunk/) , it looks like it is pretty easy to use and very clean IF your source tree is set up in a fashion which Maven expects. Our source tree does not fall into this category.
3) How much time would it take?
Again, difficult to say as the user base for 2.0 isn?t huge yet. A few weeks if no architecture bugs were found and the best case scenario path of development transpired. Worst case ? 5 weeks (ish), again, this is a best guess.
4) What are the drawbacks?
There are a few problem areas which I find scary. Namely, it?s still a beta product. It?s a first release of a complete rewrite of their original product. Documentation is slim to non-existant and users are only now beginning to exercise the product. Quick perusals of their user mailing list yields a lot of scary questions about basic build functionality regarding the beta release.
5) What are the benefits?
The benefits I feel are much stronger in the long term vs. the short term. Once their release is stable, you gain the benefit of having a community to support the product rather than a few people. Users of the system would simply write custom plugins to extend the functionality. Theoretically, our time would be spent adding bits and pieces in the forms of plugins rather than supporting the system as a whole.
What support does Maven have for the following usecase?
(which is one of the reasons the new build was being written)
* Checkout seam top level build
* Synchronize (also checks out JBossAS top level build)
The two projects should now be treated as one project with seam acting as the top level build.
* Do the same for Portal + JBossAS
* -""- Portal + Seam + JBossAS
Repeat the above, but decide that part(s) of the build should be a binary checkout.
What support does Maven have for resolving thirdparty library conflicts?
Where in Maven do I describe my build input and outputs and rules to map
between them (like make) rather than
* an arbitrary list of properties that override a predefined notion of what makes up a build (like buildmagic)
* an arbitrary list of scripts with little or no declarative approach (like ant)?
I'll start with the last question first. The declaration of inputs and outputs takes place in a file called pom.xml. It's similiar our top level build notion.
In the following snippet example they are describing a project which has one output (the default style maven works with). The output name comes from the artifactID-packaging-version combination. Building of this project is dependent upon 1 artifact being present, junit.jar. In order to produce more outputs a plugin would need to be used (for Maven 2.0).
<project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <packaging>jar</packaging> <version>1.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>
Thirdparty library resolution:
This is one of the more exciting features IMO. The current release does support the idea of conflict resolution and secondary dependencies. Their conflict resolution strategy is that the version nearest to your project that matches all given ranges (you can specify a range of versions in you pom.xml) wins.
This is a good doc on the subject:
I'm still digging in on this one, but have not yet found any evidence that this would easily work. The dependency notion for maven is based upon binaries rather than source.
Instead, a source dependency translates to a multi-project build. For us, this would be a top level build that built the entire JEMS stack. Conceivably, you could come up with a plugin that extended their dependency notion to include a binary/source switch.
Is there middle ground?
Can maven be used just for the module level builds? IE, we still use jbossbuild for synchronization, third party resolution, and release definitions. Basically, we use the component-info.xml + the toplevel build from jbossbuild.
Then we use maven for the compiling, jarring, etc. on a module level.
We wouldn't use maven for what their known for -> jar downloading, but we would still have a POM for each module.
Some links regarding previously discussed questions.
The developers have been working on an example M2 project with multiple modules. The documentation has not officially been posted yet, but can be accessed here.
The next link is related to Adrian's issue of checking out src vs. binary. A jira issue has been opened regarding the src checkout of a dependent project.
I have created a maven component in the jbossbuild project which we can use for tracking the stopper issues.