On 11/17/2010 6:05 AM, Marshall Schor wrote: > > On 11/17/2010 5:05 AM, Thilo Götz wrote: >> On 11/17/2010 04:35, Marshall Schor wrote: >>> On 11/16/2010 3:06 AM, Thilo Götz wrote: >>>> On 11/15/2010 23:31, Marshall Schor wrote: >>>>> On 11/15/2010 8:26 AM, Thilo Götz wrote: >>>>>> On 11/15/2010 13:43, Marshall Schor wrote: >>>>>>> ... >>>>>> So how do I know these two go together? How can I know a >>>>>> couple of years from now that when I extract the 2.3.1 >>>>>> tag, I need to get the parent-pom-1 build tools to go with >>>>>> it? >>>>>> >>>>> Here's how: >>>>> >>>>> First of all, a few years from now, I think you won't have to do anything >>>>> special. >>>>> When you extract the 2.3.1 tag, it should just build. Here's the details. >>>>> >>>>> The 2.3.1 tag has poms which, in turn, specify the version 1 of the >>>>> parent-pom. >>>>> >>>>> That parent pom, assuming we pass the release, will be forever in Maven >>>>> central. >>>>> In particular the version 1 of that will be forever there. >>>>> >>>>> So, the indication of what the parent pom is needed, is indicated >>>>> directly in >>>>> the 2.3.1 poms. >>>>> >>>>> Is that sufficient, or have I overlooked something? >>>> Maybe I want to look at the source of the build tools because I suspect >>>> there's >>>> a problem. Or a later version of maven creates a problem where none has >>>> been. >>>> >>>> I assume I can go and look in some pom somewhere and find the version of >>>> the build tools I'm depending on, and extract the corresponding tag if I >>>> like? >>> Yes, following the convention where when a release happens, we re-tag the >>> release candidate to be the same name, but without the -RC3 or whatever. >>> Or, if we don't do that, I guess you could look at the latest release >>> candidate. >>> >>> In our previous releases, I noticed that some release managers retagged >>> things >>> and others didn't. But I think it's a good idea to do this. >>> >>> The "-1" part of parent-pom-1 is the "version" number. >>> >>> The other place you can get the source for the build artifact is from Maven >>> Central. When an artifact is released, it includes "attached" additional >>> things, one of which is the xxx-source-release.zip file. This is an >>> Apache/Maven standard which is supposed to be downloadable, and when >>> unzipped, >>> include everything you need to rebuild the artifact from source. It's not >>> SVN, >>> though. >> Which defeats the purpose. > We can change our "process" to make another SVN tag which contains > "everything" > being released. For instance, > we could make a new tag, say, under uima (not under uima/build, or uima/uimaj > - > because the tag would contain artifacts from both?), and then copy in (in this > case: uima/build/tags/parent-pom-1-RC3, > uima/build/tags/uima-build-resources-RC3, and > uima/uimaj/tags/uimaj-distr-2.3.1-rc4. > > Would that meet the purpose?
Here's a bit history / context. The "convention" in maven projects is to have a top level POM which is used as a parent, and contains factored-out common things, such as the <groupId>, the <license>, the <mailingList> info, etc. When aligning our builds to be more conventional, I created a set of top level POMs to capture this factoring, thinking that they would not change very often. So, I had a top-most POM for mailingLists, etc., a POM for all the docbook stuff (which I expected to change only when our docbook processing pipeline needed a change), etc. This grew rather cumbersome to "release", in part because I was learning the details of how the conventional Maven "release" process works (learn - by - doing). So, at some point, it was suggested that all of these factored-out POM parts be recombined; this was done (as much as possible - Maven still requires that any "resources" bundled into a Jar for the remote-resources plugin (and others) to use can't be combined with a parent-pom project - so we have 2 projects for this, plus one more which is already "released" and in Maven Central - a build-helper plugin (http://repo2.maven.org/maven2/org/apache/uima/uima-build-helper-maven-plugin/2/) ). Then, it seemed I was doing releases for the build tooling, ahead of trying the release for the uimaj SDK, only to discover some issue (involving the release of the uimaj SDK) which needed the build tooling to change. So we changed to an approach where we would do a vote on both the build tooling and the uimaj SDK, together. So that's why there are multiple SVN things being voted on, for this release. I think the convention to go from a release artifact back to the svn tag is to take the release artifact name e.g. parent-pom-1, or uimaj-distr-2.3.1 which contains a suffix indicating the version being released, and go to the tag (under "build/tags" or "uimaj/tags") and find the tag named the same. If we didn't have release candidates (because our release processes were all debugged, and releases went out correctly the first time), then the Maven defaults for the release plugin would create these tags. As it is, once the release candidate gets voted out, a manual svn copy is needed to create the release candidate tag with the proper name. -Marshall >>>> I admit I stopped paying attention to the build issues. Why can't the >>>> build >>>> tools have the same version number as the release? Just out of curiosity, >>>> since >>>> "parent-pom-1" does not seem a very expressive version number to me. >>> The main reason for this is that the build tools are supposed to be reused >>> for >>> multiple releases of things. For instance, the common Apache Parent POM is >>> at >>> release "7" and is supposed to be used by Apache projects built with Maven >>> that >>> are trying to follow the Apache conventions. >>> >>> I was thinking ahead and imagining some release cycle where the components >>> might >>> be released separately, that might look like: >>> >>> (time ---> >>>) >>> 2.3.1 uimaj >>> 2.3.1 uima-as >>> 2.3.1 DictionaryAnnotator >>> 2.3.1 Regex Annotator >>> ... etc >>> >>> 2.3.2 DictionaryAnnotator (releasing an update to just one >>> annotator would be possible) >>> ... >>> 2.3.2 uima-as (releasing an update to uima-as without >>> changing the base would be possible) >>> 2.3.3 uima-as >>> >>> parent-pom-2 (releasing the parent-pom would only >>> need to be done when it changed) >>> 2.3.2 uimaj >>> 2.3.4 uima-as >>> >>> etc. >>> >>> Of course, whether or not to keep our versions all locked together is a >>> debatable decision. But I was planning for a future where we might want the >>> flexibility of releasing things separately. >> ... >
