On 10/21/2010 11:22 AM, Thilo Götz wrote:
> This is probably a stupid question, but here goes
> anyway: does this mean that I can build the sandbox
> components from trunk again without having to
> manipulate any poms or other xml files?

Yes. -Marshall


> --Thilo
>
> On 10/21/2010 17:17, Marshall Schor (JIRA) wrote:
>> update trunk poms to depend on -SNAPSHOT versions of build tooling
>> ------------------------------------------------------------------
>>
>>                  Key: UIMA-1905
>>                  URL: https://issues.apache.org/jira/browse/UIMA-1905
>>              Project: UIMA
>>           Issue Type: Task
>>           Components: Build, Packaging and Test
>>             Reporter: Marshall Schor
>>             Assignee: Marshall Schor
>>
>>
>> Implement "3b)" below:
>>
>> Each "release" of the build tooling takes time and effort, from several 
>> people,
>> for doing the release, preparing test versions of our code referring to the 
>> new
>> release, and testing the build tooling, and then doing an svn "merge" of the
>> updated parent-pom references to pick up the new versions, back into the 
>> trunk.
>>
>> I would like to reduce this :-).  Here's a proposal:
>>
>> Update the current projects in UIMA that use these build tools, to depend on
>> that previous SNAPSHOT, instead of depending on "released" versions. 
>>
>> This will create a "problem" when releasing the projects that use these: 
>> projects, when released, cannot depend on snapshots.  To overcome this, at 
>> the
>> time we release, say uimaj-sdk project, do one of the following:
>>
>> 3a) Change the build tooling for parent-pom-dist to include a 
>> <modules><module>
>> that specifies the uimaj-distr project, and then do the release from the
>> parent-pom-top.  This will release the build tooling, plus all the items in
>> uimaj-distr, together. 
>>
>> Downside of this: it introduces a cross SVN-checkout directory dependency,
>> because the <module> must have some kind of relative reference from a "build"
>> checkout (working directory A, say), and the uimaj SDK checkout (working
>> directory B, for instance).  It also requires that, after releasing, we 
>> update
>> parent-pom-distr to remove the <modules> section.
>>
>> 3b) When it's time to release, release the build tooling, like we do now, and
>> before closing the Nexus staging repo, also release the uimaj-distr 
>> projects. 
>> Release will complain that there are "still" snapshot poms, but according to
>> http://jira.codehaus.org/browse/MRELEASE-583 (which is included in the set of
>> things included in the 2.1 version, which we're now using) the release plugin
>> will let you change these to release levels, as part of the release:prepare
>> process.
>>
>> With this approach, we can fiddle the build tooling as much as we need to 
>> while
>> getting a release to "go", and then release things.
>>
>>
>

Reply via email to