Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
2.2.2
-
None
Description
The maven system allows refactoring things using an inheritance tree. We use this capability via a hierarchy starting with uimaj project's POM. We also have a "flat" layout for subprojects, following Eclipse conventions.
When running maven on a component, say, uimaj-ep-configurator, its POM has a parent POM. This parent is "looked up" using the maven system of identifying artifacts, in the maven repository chain, starting with the local repository. This means that if you change any of the super POMs in the chain, those changes are ignored until you do a "mvn install" on those POMs.
The work-around was to do a "mvn -N install" in the directory where the changed POM was. The -N flag says just do the install on the POM, and skip any sub-processing of the aggregated "modules" (if any) that the POM specified using the <modules> element.
Recently, while trying to improve the maven builds, I (again) forgot this fact, and wondered why my changes to the superPom were not having any effect.
To overcome this (for future maintainers so they won't suffer from this), add an optional <relativePath> element to the <parent> element of all the POMs in the uimaj and uimaj-as projects. (Perhaps this should also be done, at some point, for the other projects too, but that can be another Jira).
The <relativePath> is a relative path to the directory containing the parent POM, and will be tried first before looking up the POM in the repositories.