You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2010/10/21 17:17:26 UTC
[jira] Created: (UIMA-1905) update trunk poms to depend on
-SNAPSHOT versions of build tooling
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (UIMA-1905) update trunk poms to depend on -SNAPSHOT
versions of build tooling
Posted by Marshall Schor <ms...@schor.com>.
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.
>>
>>
>
Re: [jira] Created: (UIMA-1905) update trunk poms to depend on -SNAPSHOT
versions of build tooling
Posted by Thilo Götz <tw...@gmx.de>.
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?
--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.
>
>
[jira] Closed: (UIMA-1905) update trunk poms to depend on -SNAPSHOT
versions of build tooling
Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor closed UIMA-1905.
--------------------------------
Resolution: Fixed
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.