uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Date Wed, 30 Jan 2013 19:20:39 GMT

On 1/29/2013 4:44 PM, Peter Kl├╝gl wrote:
> Am 29.01.2013 20:25, schrieb Marshall Schor:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin/
>> directory,
>> there are multiple files where the version is missing, and instead is the
>> literal string ${parseVersion.osgiVersion}.
> I already observed this in RC1, but I have not investigated this problem,
> because it also happens for the other uima plugins, e.g., uimaj-ep-cas-editor

This property is typically set by running the build-helper-maven-plugin, which
is normally run early in the build (it's in the uima-wide parent pom).

I tried doing mvn package on the ...addons package, and it built with the right
value substituted into the jar name.

It also worked for me when I did this with -Dapache-release

So I can't reproduce the "failure".

The build-helper-maven-plugin parse-version goal is the first one run - the
first console display lines after the mvn command are:

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Apache UIMA TextMarker Eclipse: uimaj-ep-textmarker-addons 2.0.0
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for org.eclipse.equinox:app:jar:1.0.0 is missing, no
dependency information available
[WARNING] The POM for org.eclipse.emf:ecore:jar:2.4.0 is missing, no dependency
information available
[WARNING] The POM for org.eclipse.emf.ecore:xmi:jar:2.4.0 is missing, no
dependency information available
[WARNING] The POM for org.eclipse.dltk:core:jar:3.0.0 is missing, no dependency
information available
[INFO] --- build-helper-maven-plugin:1.5:parse-version (parse-project-version) @
uimaj-ep-textmarker-addons ---

Does your build show something different (about the build-helper-maven-plugin)? 
If so , what command did you run (and in what environment) to produce the jar
with the ${parseVersion.OsgiVersion} string in the name?

>> I think these need to be fixed - so the version is included in the released file
>> name.
>> Also, what is the purpose of this whole directory?  I think perhaps all of the
>> "jars" having compiled classed and their associated signatures/checksum files
>> can be deleted?  My Reasoning:
> Yes. My reason for providing all those files was the fact that those files are
> uploaded to the staging repository. I read something that these files should
> also be provided in the webspace in order to facilitate the reviewing.

OK, I didn't expect that, I thought that everything here was planned to be put
on the Apache mirror system.

I think it's best to publish artifacts for testing that will be the actual
things being released.  There are 2 release paths in Apache:  Release via the
Apache Mirroring System, and Release to Maven Central.  The artifacts in your
src-bin directory won't be released (as I understand it) via the Apache
Mirroring System. They are (hopefully) copies of the artifacts on the staging
repository.  People testing should be getting the things to test from that
staging repository, rather than depending on the copy here, I think. 

Are there files here which are not also on the staging repository?

> If those poms are not needed, then there is maybe no problem so solve.
>> these Jars are for the convenience of users.  But users won't be using them via
>> this path.  They'll either be using them via Eclipse update site, or (less
>> likely?) via pulling them as dependencies from Maven Central.
> I must admit that I already wondered how and in which form TextMarker will be
> released. There is the update site for the workbench, of course. However,
> there are maybe some people (maybe in Richards group) that are using
> TextMarker rules directly in some maven-built projects, without the Workbench,
> only adding some maven dependency. 

For these, users will want to get the jars / poms from Maven central, I think.

> Even users of the workbench will eventually integrate the developed analysis
> engines in some applications that are maybe built with maven. 
Yes, this is the good reason to upload these to Maven Central (when released, of
course :-) ).
> Then, there should maybe also be the option to download all binaries
> (uima-textmarker.jar and the plugins), similar to the uimaj release. 

I'm not sure what you mean.  If you mean, to provide a binary "assembly" in .zip
and .tar form of all of the compiled code in Jar files (like what UIMA Java SDK
does), then this would be only for those people not using Maven or Eclipse.  But
so far, your user use-cases were Maven or Eclipse - so (so far) I guess there's
no need for a binary assembly distribution of this kind. 

Of course, if there's a use case for this, then, you should have this additional
form, together with some documentation for new users on what to do with it (for
example, download the zip/tar, unzip/tar it into a directory of your choosing,
and then run x, y, z, etc. to finish the setup (I'm guessing here, of course)...

> If not, then non-maven developers have to get/download somehow the update site
> and add the engine plugin as an library.
Yes.  So it all depends on the users and what they'll be doing.  If you think
your initial users will be Maven / Eclipse users, you might start with packaging
supporting just that, and then, if users show up wanting additional packaging
kinds, you'll be in a better position (knowing exactly what these users need) to
provide it (later).
>> So, there's no need to include them here, I think.
> Should I remove them for the next RC? I just added as much as possible in
> order to not forget anything.

I'm guessing that every one of the files in the src-bin directory is on the
staging repository.  If so, that's where users should download them from.  I
would put here, only  files that won't be released but aren't anywhere else,
which need some kind of review (I hope there aren't any :-) ).  And, I would
label the directory something like "not-being-released-but-for-review"  or
something like that so reviewers won't think these are going to be part of the

(Apologies for the long note)


View raw message