[jira] Closed: (UIMA-1905) update trunk poms to depend on -SNAPSHOT versions of build tooling

["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.