I'm thinking it would be best to remove the two projects which are *not* being
released from the tag, as a matter of good housekeeping and to reduce confusion.

Other opinions?

-Marshall

On 6/24/2013 12:35 PM, Marshall Schor wrote:
> On 6/24/2013 4:56 AM, Richard Eckart de Castilho wrote:
>> Looking at the parent-pom-5-rc1 tag in svn:
>>
>> - The tag contains stuff that's not part of the RC (uima-docbook-olink, 
>> uima-eclipse-composite-update-site)
>>
>> - The reason for this is, that the parent folder of the aggregated modules 
>> (uima-build-resources, uima-build-helper-maven-plugin) contains additional 
>> modules which are not part of the aggregator (uima-docbook-olink, 
>> uima-eclipse-composite-update-site).
> Yes, I agree with this analysis.   The more frequent way we update these 
> things
> is by doing them individually.  I think maven has a bit of logic which looks 
> at
> the things in the reactor (projects being built together) and searches upwards
> in the directory structure to find a common directory, and then tags that in 
> SVN
> (since tags don't actually copy) as a way of getting an "instantaneous" level
> across all of the things being built.
>> - It confuses me when an aggregator POM is not in the parent folder of the 
>> aggregated modules.
> Right, this is the normal build convention for Maven.   We typically do not
> release the build tooling as parts of aggregated modules.  This was only done,
> for this release, as a way to get all 3 things released together, in one go.  
> I
> think an alternative would have been to release each one separately, but that
> would have maybe required doing first the parent-pom release (and getting 
> votes
> done), and then updating the other two projects to have as their parent pom 
> the
> parent-pom at version 5, in a subsequent vote.  I was trying to avoid extra
> votes :-)
>
>
>> - The parent-pom contains settings marked with "ADDONS ONLY". These appear 
>> to be redundant with settings in the addons-parent. Either one or the other 
>> should be removed?
> Right - in general, things in any xxx-parent which are duplicated with the
> parent-wide pom, should be removed in the xxx-parent.  They're in the 
> xxx-parent
> only because of the time involved in getting a next parent-pom released - the
> xxx-parent provides a way (for the xxx project) to fix mistakes in the
> parent-pom before its next release.
>
> Thanks for your careful review!
>
> -Marshall
>> Cheers,
>>
>> -- Richard
>>
>> Am 20.06.2013 um 20:18 schrieb Marshall Schor <[email protected]>:
>>
>>> This is a release of the uima-wide top parent pom.
>>> Highlights of changes: m2e support, Eclipse plugin, features, update site,
>>> licensing changes.
>>>
>>> See
>>> https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20parent-pom-5%20AND%20project%20%3D%20UIMA
>>> for list of issues.  Highlights: m2e support, Eclipse plugin, features, 
>>> update
>>> site, licensing changes.
>>>
>>> This includes changes to the uima-build-resources - mainly supporting 
>>> updated
>>> Eclipse licensing.
>>>
>>> The artifacts are staged to
>>> https://repository.apache.org/content/repositories/orgapacheuima-037/
>>>
>>> To test, please read Setup for testing - adding the Staging repository for 
>>> Maven
>>> builds in http://uima.apache.org/testing-builds.html
>>>
>>> The SVN tag is 
>>> https://svn.apache.org/repos/asf/uima/build/tags/parent-pom-5-rc1
>>>
>>> There are no artifacts other than these for Maven.
>>> Please vote:
>>>
>>> [ ] +1 OK to release
>>> [ ] 0   Don't care
>>> [ ] -1 Not ok to release, because ...
>>>
>>> -Marshall
>

Reply via email to