Right now it is difficult for us to support m1 multi-module setups because of file system references in child POMs. We can not checkout a leaf in a project like Geronimo because of reliance file system references to the parent POM.
We need to be able to check out a whole m1 project, like Geronimo, and determine where all the modules are so that we can create Continuum projects from the m1 projects. Some options we've been thinking about include:
- Make m1 projects use m2 POMs which list the modules so that we can deterministically create the right set of Continuum project
- Use m1 code to read m1 POMs after all the project.xml files have been discovered
Elements we need from the m1 POM:
- groupId
- artifactId
- version
- name
- repository
- dependencies (groupId/artifactId)
We probably need to use the m1 POM reader to account for the varied use of properties files and entities.
Trygve and I are currently thinking that creating an m1 plugin for submitting project information to Continuum might be the best approach. Our reasoning is that we would prefer not to pull in the entire set of m1 dependencies in order to read the m1 POMs. We can't simply use xpp3 to parse the m1 POMs due to the use of properties and entities. So an m1 plugin could work with the multi-project to submit the desired projects to Continuum. Once submitted the projects could also be updated using this m1 plugin.

2 Comments
Hide/Show CommentsJul 15, 2005
John Casey
for building a single project within something like geronimo, what about checking out all of geronmio, but only marking (in a database or something) which subprojects to actually build. Then, you have those subprojects' context, and the build should be able to proceed according to the rules of the build system (following filesystem references, for example).
Jul 15, 2005
John Casey
Also, with respect to m2, checkout my comment toward the bottom of MNG-521 (http://jira.codehaus.org/browse/MNG-521#action_42889). The upshot is that I don't think it's really necessary to traverse the hierarchy in a strict ../pom.xml sort of way for product projects in m2, though you would have to scan the entire project hierarchy for that product in order to find all of the parent- and ancestor-poms...