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
