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
