uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] Commented: (UIMA-1823) Incrementally release build artifacts to eliminate dependencies on -SNAPSHOTs
Date Fri, 02 Jul 2010 14:13:49 GMT

    [ https://issues.apache.org/jira/browse/UIMA-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884680#action_12884680
] 

Marshall Schor commented on UIMA-1823:
--------------------------------------

One can "install" (i.e. "mvn install") artifacts tot he local repo.  But that's not what the
release process as implemented by the release plugin does.

That process includes renaming versions poms from -SNAPSHOT, fixing up pom scm tags, tagging
things in SVN, pulling a fresh extract from SVN and building that in an "isolated" spot, installing
that, and then deploying it to the NEXUS staging repository.

We could choose to not use the release plugin, but I'm attempting at this point to move our
processes toward being as "vanilla" maven as seems feasible.  

I hope that the awkwardness of this initial build tool release is a one-time (or at least,
very occasional) issue.  And maybe along the way we'll learn some other idea which makes all
this unnecessary (that is, maybe this is just due to our not quite knowing how to "operate"
maven).

> Incrementally release build artifacts to eliminate dependencies on -SNAPSHOTs
> -----------------------------------------------------------------------------
>
>                 Key: UIMA-1823
>                 URL: https://issues.apache.org/jira/browse/UIMA-1823
>             Project: UIMA
>          Issue Type: Task
>          Components: Build, Packaging and Test
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>
> The Maven release plugin updates versions in poms, parent -pom references, and dependencies,
for things being released together at one go.  However this doesn't work for dependencies
that are within the <build> element.
> To get around this, release things in the build in the following order, updating components
as needed before each release, to depend on things officially released  preceeding them.
> Suggested order 
> *uima-jar-resource-bundle
> *parent-pom-top (depends in build section on above)
> Next batch (no intra-project dependencies)
> *uima-build-helper-maven-plugin
> *uima-assembly-single-project
> *uima-docbook-resource-bundle
> *parent-pom-distr
> *parent-pom-docbook
> Next batch
> *parent-pom-ibm-notice
> *parent-pom-eclispe-plugins
> *parent-pom-annotator
> *parent-pom-distr
> Next
> *parent-pom-eclipse-plugins-ibm-notice
> The parent-pom-annotator has a dependency on PearPackagingMavenPlugin.
> Set this to 2.3.0-incubating for now; after uimaj has its first 2.3.1 non-incubating
release,
> update this to 2.3.1.
> The aggregate-parent-poms project won't be released in this cycle; it has served its
purpose
> (letting us climb the learning curve on using the release plugin), and will be released
only 
> if it is convenient in the future to re-release a bunch of these without concern for

> simultaneously updating the dependency versions in the <build> sections of the
sub-modules.
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message