uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kl├╝gl <pklu...@uni-wuerzburg.de>
Subject Re: versioning and naming, and a checkout issue
Date Wed, 19 Dec 2012 13:23:32 GMT
Yes, that is a flaw for which I haven't found a good solution. Because 
if this, and because it is not always to the best way to add a child 
repository by the child-repo pom, the build procedure is not really 
smooth right now.

Again, I agree with your arguments and with your solution :-)

Peter

On 19.12.2012 13:54, Marshall Schor wrote:
> The maven build procedure for this has a requirement on the checkout of the svn
> folder .../uima/eclipse-packagings, namely, this folder must share a common
> local parent folder with the project uimaj-eclipse-update-site.
>
> I stumbled over this, because I had checked out the eclipse-packgings into a
> folder one above that spot, and the build failed.
>
> I'm not sure what to do about this, but I think it needs to be documented in the
> procedures.  It would be good if this was not an issue.  I'm thinking if we got
> rid of a separate top-level eclipse-packagings, and instead had that as a
> subdirectory under the existing uimaj-eclipse-update-site, that would insure
> these were always checked out together in the proper folder hierarchy.  (This
> would also get rid of the need to add trunk/tags/ etc. to eclipse-packagings, as
> I commented on in my previous post).
>
> If we did go in this direction, because the uimaj-eclipse-update-site and
> uimaj-eclipse-feature-xxxx projects are not specific to the uima SDK, it would
> seem to me to be better to move these 3 projects into the top level SVN node
> "builds", since these are concerned with building packagings.
>
> -Marshall
>
> -----------
>
> The build process creates a new directory in the eclipse-packagings folder, with
> the name uima-2.4.0.  Under that, there's the jars for the uima 2.4.0 versions
> of the SDK and UIMA-AS plugins and features.
>
> I'm trying to understand how versioning should work.  It seems we'll have 2 (or
> more) kinds of versions, for a particular update of the eclipse update site:
>
> 1) the version of the update site build, itself.  This is probably a simple
> incrementing number: 1, 2, 3, ..., like our shared build poms.
> 2) the version(s) of the tooling being added in this particular update.
>
> For (2), in the past, we've built only the "current" versions being updated of
> various plugins/features.  The release manager for the eclipse packagings was
> responsible to copy these new versions into the shared site distribution spot,
> leaving older versions there as well.
>
> Here's a use case I want to be able to handle:  Suppose TextMarker at version
> 2.0.0 is released, and we want to update the update-site to include it.  What
> would the eclipse-packagings/eclipse-update-site/<????> directory be for this,
> and is that supported?  From looking at the POM for uimaj-eclipse-update-site,
> it seems that this line:
>
>                  <copy
> todir="${eclipseUpdateSiteComposite}/uima-${item-eclipse-release-version}"
> preservelastmodified="true">
>                    <fileset dir="${eclipseUpdateSite}" />
>
> would create a subdirectory, called uima-2.0.0 for this, which doesn't seem
> quite right - I would think it would need to include TextMarker somewhere in
> this name.
>
> -Marshall


Mime
View raw message