The following is not a blocker, but describes a more general problem, which we might want to fix at some point.
The current structure is "double-purposing" the top level project: 1) for both the "modules" and building the top-level artifacts, and 2) for being the parent-pom of the sub-modules. Because of this, all of the "build" steps in the top level POM (under <build>... <plugins>...) that are there for building at the top level, such as preparing the Jira issues resolved, could be inherited by the sub-modules, who are pointing to the top level project in order to inherit common things, as their parent-pom. There are two approaches for this: One is to split the parent-pom function from the top level build, by having an additional project (which might be called textmarker-parent, for example). All of the projects in textmarker which need some factored common setup would specify this as the parent pom (including the top level project), and it would be included as a <module> in the top level pom. This is how uimaj, uima-as, and uima-addons are set up. The other approach for this is to arrange for all of the build steps that the top level pom specifies only get done at the top level - where this pom is. This can "mostly" be done. For example, the source-assembly set includes the configuration <runOnlyAtExecutionRoot>true which prevents this from being inherited below. There is also a maven model xml element for plugin, <inherited>false, which can be set, and works to prevent some (but not all) plugins from running at other than the level containing the POM. It seems to work for the ant-run plugin, but doesn't work for the maven changes plugin (at least it didn't work when I tried it). The result is that with this build design, the maven changes plugin extracts from Jira and puts in the issues fixed information into all the subprojects, not just the top level project. Splitting the two functions (top level assembly, etc., from parent-pom) into two projects solves this issue, and potentially also other similar kinds issues that may arise in the future. But I don't think it's a blocker for this release. And, if Maven improves (I'm running Maven version 3.0.3), maybe the approach taken here is better in that it eliminates the need for a separate parent-pom project. -Marshall
