startup issue with maven for uimaj-ee

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

For those of you who may try and build uimaj-ee in the sandbox, there is 
a 1-time maven startup problem.

We currently use a POM structure which has a common parent (in this 
case, it is uimaj-ee's POM).  The common parent factors out some common 
settings, like release numbers and formats. 

Therefore, the child POMs require the common parent in order to be 
processed.

The common parent also specifies in its <modules> element the child 
POMs.  When you do a mvn install on the parent - it builds the children.

So - the very first time you try this, the child POMs are read *before* 
the uimaj-ee's POM has been "installed" to your local repo (currently as 
a snapshot).  The effect is that the mvn install of uimaj-ee fails 
because the child POMs can't be processed because their parent is 
"missing" (in the repository).

The work-around for now is to (1 time only) comment out the <module> 
elements in the <modules> section of uimaj-ee, then mvn install it (to 
your local repo).  Then you can uncomment out the <module> elements. and 
build normally.

I'm not sure how to fix this in a better way.  One idea would be to put 
in the settings / configuration needed to upload SNAPSHOTs to the 
/www/people.apache.org/repo/m2-snapshot-repository/ 
<http://people.apache.org/repo/m2-snapshot-repository/> on p.a.o (see 
http://www.apache.org/dev/repository-faq.html - it says, in part:

    The /incubating/ repositories are for releases from projects within
    the Apache Incubator - incubating snapshots still goto the
    /snapshot/ repositories.

Is this something we should do?  My worry is that this would be an 
excessive load on p.a.o for every build anyone does.  Perhaps the better 
idea would be to just "manually" upload it once?  Anyone know the maven 
magic to do this (if so , please post)?

Of course, we would then need to configure the POMs or the local maven 
user settings to know about using the p.a.o's snapshot repo
--------------
Another idea would be to change our POM hierarchy to split these two 
functions.  This seems like extra work/complexity, though.  Is there a 
maven parameter to temporarily ignore the <module> part when doing mvn 
install?
--------------
Other ideas?

-Marshall

Re: startup issue with maven for uimaj-ee

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

Marshall Schor wrote:
> For those of you who may try and build uimaj-ee in the sandbox, there 
> is a 1-time maven startup problem.
>
> We currently use a POM structure which has a common parent (in this 
> case, it is uimaj-ee's POM).  The common parent factors out some 
> common settings, like release numbers and formats.
> Therefore, the child POMs require the common parent in order to be 
> processed.
>
> The common parent also specifies in its <modules> element the child 
> POMs.  When you do a mvn install on the parent - it builds the children.
>
> So - the very first time you try this, the child POMs are read 
> *before* the uimaj-ee's POM has been "installed" to your local repo 
> (currently as a snapshot).  The effect is that the mvn install of 
> uimaj-ee fails because the child POMs can't be processed because their 
> parent is "missing" (in the repository).
>
> The work-around for now is to (1 time only) comment out the <module> 
> elements in the <modules> section of uimaj-ee, then mvn install it (to 
> your local repo).  Then you can uncomment out the <module> elements. 
> and build normally.
An easier work-around:  do mvn -N install. 

Maven command line arguments are documented nowhere (that I can find), 
but if you type mvn -? it tells you about this.

-Marshall

Re: startup issue with maven for uimaj-ee

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

Here's what differential analysis found:

The working uimaj POM had

    . . .
      <version>2.3.0-incubating-SNAPSHOT</version>
      <properties>
          <uimaj-version>2.3.0</uimaj-version>
         
    <uimaj-release-version>${uimaj-version}-incubating-SNAPSHOT</uimaj-release-version>
    . . .

I noticed that 2.3.0-incubating-SNAPSHOT was available as a property, so 
in the "improved" (but non-working :-) ) uimaj-ee POM it read:

    . . .
    <properties>
          . . .
          <uimaj-ee-version>0.7.0</uimaj-version>
         
    <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT</uimaj-release-version>
    . . .
    <version>${uimaj-ee-release-version}</version>

Fix was to not use a property substitution in the <version> element, and 
instead copy the uimaj-ee-release-version tag.  This is probably a Maven 
defect - I'll see (on the maven list).

-Marshall


Marshall Schor wrote:
> Thilo Goetz wrote:
>>
>>
>> Marshall Schor wrote:
>>> For those of you who may try and build uimaj-ee in the sandbox, 
>>> there is a 1-time maven startup problem.
>> ...
>>
>> How do we do this in the core?  Aren't we using the same
>> mechanisms there?
> Good question.  I did this experiment:
>    delete uimaj-ee from local maven repo, try building - get error.
>    delete uimaj from local maven repo, try building - works!
>
> So, I guess I'll do some "differential analysis" to see what's going 
> on...  My guess is that I "factored" something that shouldn't be 
> factored into the parent.
>
> -Marshall
>>
>> --Thilo
>>
>>
>
>
>

Re: startup issue with maven for uimaj-ee

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

Thilo Goetz wrote:
>
>
> Marshall Schor wrote:
>> For those of you who may try and build uimaj-ee in the sandbox, there 
>> is a 1-time maven startup problem.
> ...
>
> How do we do this in the core?  Aren't we using the same
> mechanisms there?
Good question.  I did this experiment: 

    delete uimaj-ee from local maven repo, try building - get error.
    delete uimaj from local maven repo, try building - works!

So, I guess I'll do some "differential analysis" to see what's going 
on...  My guess is that I "factored" something that shouldn't be 
factored into the parent.

-Marshall
>
> --Thilo
>
>

Re: startup issue with maven for uimaj-ee

[Thilo Goetz <tw...@gmx.de>]

Marshall Schor wrote:
> For those of you who may try and build uimaj-ee in the sandbox, there is 
> a 1-time maven startup problem.
...

How do we do this in the core?  Aren't we using the same
mechanisms there?

--Thilo

Re: startup issue with maven for uimaj-ee

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

How about this:

When it's time to generate a test build candidate, we do the basic 
release prepare process:

    change the 2.3.0-incubating-SNAPSHOT to 2.3.0-incubating
    save this as a tag in SVN using the candidate release name:
    2.3.0-rc1-incubating
    increment the base SVN to 2.4.0-incubating-SNAPSHOT   << note

We then run tests, etc.
If we find a problem, we fix in the base, and do another release prepare 
for the next candidate:

    change the 2.4.0-incubating-SNAPSHOT to 2.3.0-incubating
    save this as a tag in SVN 2.3.0-rc2-incubating
    increment the base SVN to 2.4.0-incubating-SNAPSHOT   << note

At some point we find we're satisfied; our last release candidate tag is 
then "released";
SVN is already setup for the next level.

The only drawback I see with this is that it would conflate fixing 
release candidates with working on the next version.  We could fix that 
by incrementing the base to a version number that specifically included 
the release candidate info, such as 2.3.0-rc[n]-incubating-SNAPSHOT. 
Then, at the end, we'd need one more release:prepare step to

    update the poms to 2.3.0-incubating, tag to 2.3.0-incubating-release
    (or something like that), and then increment the poms to
    2.4.0-incubating-SNAPSHOT

Would this be a reasonable process?

-Marshall

Adam Lally wrote:
> On Jan 11, 2008 8:56 AM, Marshall Schor <ms...@schor.com> wrote:
>   
>> It was also suggested that we use the maven "release" plugin to update
>> the version stuff. I think we should investigate that for our next release.
>>
>>     
>
> The thing that's always bugged me about the release plugin is that I
> don't think it supports our usual mode of operation where we build a
> release candidate, then people go off and do lots of manual testing on
> it, it gets approved by the IPMC, etc., and then we want to release
> exactly that release candidate.
>
> AIUI, the release plugin builds the release from SVN, tags it, and
> increments the versions for the next release, all at the same time.
> So it doesn't seem to fit the above process.  If we rebuild the
> release in this way, then we wouldn't be releasing _exactly_ the same
> thing that had been tested and approved.  (I suppose we could diff it,
> but even then I think timestamps end up in generated artifacts so it
> isn't exactly the same.)
>
> Maybe there's some way to run only the version-number-update part of
> the release plugin, and not the other stuff.
>
> -Adam
>
>
>   

Re: startup issue with maven for uimaj-ee

[Adam Lally <al...@alum.rpi.edu>]

On Jan 11, 2008 8:56 AM, Marshall Schor <ms...@schor.com> wrote:
> It was also suggested that we use the maven "release" plugin to update
> the version stuff. I think we should investigate that for our next release.
>

The thing that's always bugged me about the release plugin is that I
don't think it supports our usual mode of operation where we build a
release candidate, then people go off and do lots of manual testing on
it, it gets approved by the IPMC, etc., and then we want to release
exactly that release candidate.

AIUI, the release plugin builds the release from SVN, tags it, and
increments the versions for the next release, all at the same time.
So it doesn't seem to fit the above process.  If we rebuild the
release in this way, then we wouldn't be releasing _exactly_ the same
thing that had been tested and approved.  (I suppose we could diff it,
but even then I think timestamps end up in generated artifacts so it
isn't exactly the same.)

Maybe there's some way to run only the version-number-update part of
the release plugin, and not the other stuff.

-Adam

Re: startup issue with maven for uimaj-ee

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

I posted a question about this on the Maven user list.  Two people 
answered, both saying that the version should be hard-coded, and not use 
${...} variables.  One was a bit surprised that this worked at all. 

It was also suggested that we use the maven "release" plugin to update 
the version stuff. I think we should investigate that for our next release.

Meanwhile, I'll change the version info in the uima-ee parent POM to be 
hard-coded, to avoid users who check out this stuff for the first time 
from having to do the other discovered work-around of first installing 
the uima-ee POM to the local repository without running the sub-goals 
(using the mvn -N install command).

-Marshall

Marshall Schor wrote:
> For those of you who may try and build uimaj-ee in the sandbox, there 
> is a 1-time maven startup problem.
>
> We currently use a POM structure which has a common parent (in this 
> case, it is uimaj-ee's POM).  The common parent factors out some 
> common settings, like release numbers and formats.
> Therefore, the child POMs require the common parent in order to be 
> processed.
>
> The common parent also specifies in its <modules> element the child 
> POMs.  When you do a mvn install on the parent - it builds the children.
>
> So - the very first time you try this, the child POMs are read 
> *before* the uimaj-ee's POM has been "installed" to your local repo 
> (currently as a snapshot).  The effect is that the mvn install of 
> uimaj-ee fails because the child POMs can't be processed because their 
> parent is "missing" (in the repository).
>
> The work-around for now is to (1 time only) comment out the <module> 
> elements in the <modules> section of uimaj-ee, then mvn install it (to 
> your local repo).  Then you can uncomment out the <module> elements. 
> and build normally.
>
> I'm not sure how to fix this in a better way.  One idea would be to 
> put in the settings / configuration needed to upload SNAPSHOTs to the 
> /www/people.apache.org/repo/m2-snapshot-repository/ 
> <http://people.apache.org/repo/m2-snapshot-repository/> on p.a.o (see 
> http://www.apache.org/dev/repository-faq.html - it says, in part:
>
>    The /incubating/ repositories are for releases from projects within
>    the Apache Incubator - incubating snapshots still goto the
>    /snapshot/ repositories.
>
> Is this something we should do?  My worry is that this would be an 
> excessive load on p.a.o for every build anyone does.  Perhaps the 
> better idea would be to just "manually" upload it once?  Anyone know 
> the maven magic to do this (if so , please post)?
>
> Of course, we would then need to configure the POMs or the local maven 
> user settings to know about using the p.a.o's snapshot repo
> --------------
> Another idea would be to change our POM hierarchy to split these two 
> functions.  This seems like extra work/complexity, though.  Is there a 
> maven parameter to temporarily ignore the <module> part when doing mvn 
> install?
> --------------
> Other ideas?
>
> -Marshall
>
>
>
>