2010/11/18 Marshall Schor <[email protected]> > 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. >
+1 also it's easy to understand for common Maven users > > 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. > > Yes Marshall it sounds good. +1 Tommaso > -Marshall Schor >
