The current build approach has some issues. A major one is that the trunk is not currently buildable (because uimaj projects have a parent pom dependency at version 1 which is only in the staging area, and not really released yet).
After some iterations and discussions with colleagues, here's the next "improvement" which I think will fix these problems. The main idea is to make the "main" aggregator project for each multi-module build (e.g., the "uimaj" project for the uimaj SDK) also be a parent-pom for all those modules in the multi-module build, as is conventional Maven practice. We would still keep the build tooling overall parent-pom, but would decouple releases of that from releases of things that use it. So, for instance, we would release parent-pom, version 1, and then when we found "issues" in it while trying to release the uimaj project, we would address those issues by making changes in the uimaj's pom (overriding if needed the parent-pom-1). At some arbitrary time in the future, we could "promote" any changes that were done that ought to be shared with other projects to the common build parent-pom. A key point here is that this promotion and subsequent release of the project-wide parent pom would be completely decoupled from the release of the uimaj project. Some scenarios, assuming we've voted and released the parent-pom tooling. 1) scenario: checkout uimaj trunk or tag, and build it: svn co https://svn.apache.org/repos/asf/uima/uimaj/trunk (or some tag) cd uimaj mvn install The uimaj/trunk/uimaj pom would have a dependency on the released version of the common project-wide parent-pom, at version 1, and it would be found, just like any other released maven artifact, in maven central; the other poms in the trunk/uimaj would, in turn, have as a parent, the trunk/uimaj pom. 1a) scenario: check out, patch, and build just one jar: svn co https://svn.apache.org/repos/asf/uima/uimaj/trunk/uimaj-core (for instance) (apply patch) cd uimaj-core mvn install 2) scenario: Build from the source tarball (from a release, or from a uimaj-distr/target build, or from a release candidate) unzip the tarball cd uimaj mvn install This would work just the same as svn checkout. 3) scenario: needing to fix a problem in the build of uimaj: Here the fix would be made to the uimaj project, which is serving as the parent pom to all the submodules. Sometime after the release is made, a separate decision could be made to move the build change to the overall project parent-pom. On a separate schedule, that could be released; once it was released, the uimaj project's pom could be updated to depend on the new release level, and the part moved up to the common parent for sharing with other projects could be removed. 4) Scenario: working with eclipse: this would work as before (described here: http://uima.apache.org/building-uima.html#building-from-eclipse ) This seems to me to combine the best attributes of keeping this local and contained, and over time, factoring out common things that should be shared for consistency and reliability among all the uima projects. I'd like to do this change. It would involve: 1) voting out the already existing parent-pom-1 and uima-build-resources-1 artifacts so they could be put in Maven central, and referred to. 2) creating the uimaj project as the overall aggregator and parent-pom of the uimaj projects, and having it depend on the released version one of the projet-wide pom Then we could continue with our efforts to release uimaj, and iterating as needed, locally within the uimaj project, to get it out, without disturbing the parent-pom-1. Please let me know if you feel it's OK for me to try this approach. -Marshall Schor
