Re: startup issue with maven for uimaj-ee
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-SNAPSHOTnote 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-SNAPSHOTnote 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 [EMAIL PROTECTED] 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 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
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
Here's what differential analysis found:
The working uimaj POM had
. . .
version2.3.0-incubating-SNAPSHOT/version
properties
uimaj-version2.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-version0.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 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
