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: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Date Thu, 31 Jan 2013 18:55:43 GMT
Hi,

On 30.01.2013 20:20, Marshall Schor wrote:
> 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] ------------------------------------------------------------------------
> [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]
> [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?
>
> =============================

My console of "mvn install -Papache-release"

[INFO] Scanning for projects...
[INFO]
[INFO] 
------------------------------------------------------------------------
[INFO] Building Apache UIMA TextMarker Eclipse: 
uimaj-ep-textmarker-addons 2.0.0-SNAPSHOT
[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]
[INFO] --- build-helper-maven-plugin:1.5:parse-version 
(parse-project-version) @ uimaj-ep-textmarker-addons ---
[INFO]
[INFO] --- uima-build-helper-maven-plugin:2:parse-date-time (set 
buildYear and buildMonth) @ uimaj-ep-textmarker-addons ---
[INFO]
[INFO] --- maven-remote-resources-plugin:1.2.1:process (default) @ 
uimaj-ep-textmarker-addons ---
...

environment:
win7 64bit
apache-maven-3.0.4
jdk.1.5.0_22

I have no idea what I did wrong. Anyways, the files in the staging 
repoistory are correct and thus I would ignore this problem for now.


>   
>>> 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?

I don't think so.

For the next RC, I will omit the scr_bin folder.

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

I thought about it and agree.

> 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)...

I can think of a use case, but maybe we can postpone that until someone 
complains :-)


>> 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
> release.
>
> (Apologies for the long note)

Thanks Marshall :-)

Best,

Peter

> -Marshall


Mime
View raw message