Re: having the textmarker top POM also serve as the parent-pom for sub-modules

[Marshall Schor <ms...@schor.com>]

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

Re: having the textmarker top POM also serve as the parent-pom for sub-modules

[Peter Klügl <pk...@uni-wuerzburg.de>]

I have no opinion concerning this. There will be another RC, so I will 
separate parent and top-level.

Peter

Am 04.02.2013 21:25, schrieb Marshall Schor:
> 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