You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Peter Klügl <pk...@uni-wuerzburg.de> on 2013/01/28 14:58:04 UTC
[VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Hi,
the second release candidate of the sandbox project Apache UIMA
TextMarker is ready for voting. This vote also includes our new
composite repository.
Staging repository:
https://repository.apache.org/content/repositories/orgapacheuima-183/
SVN tag:
https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
Archive with all sources:
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
Composite repository with three update sites: uimaj, uima-as and
uima-textmarker-2.0.0:
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
Binaries and sources:
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
They can also be found here:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
Documentation (pdf file):
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
Please vote on release:
[ ] +1 OK to release
[ ] 0 Don't care
[ ] -1 Not OK to release, because ...
Thanks.
Peter
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 30.01.2013 20:45, Marshall Schor wrote:
> On 1/30/2013 5:16 AM, Peter Klügl wrote:
>> On 29.01.2013 23:53, Marshall Schor wrote:
>>> Hi,
>>>
>>> I would suggest that you consider making the top level name of your project
>>> "textmarker" (without uimaj- in front). The uimaj prefix is strongly associated
>>> with the Java SDK for UIMA.
>>>
>>> (We have releases named uima-as (no "j") and uima-cpp, and many sandbox/addon
>>> projects with simple names that denote what they are.)
>> No problem. The artifact id and projects should stay the same?
> I think the artifact-id in the POM used when importing to generate the Eclipse
> Project name.
>
> So, the group name stays the same (org.apache.uima) of course, but the artifact
> name probably should follow some simple convention suggesting
> belonging-to-textmarker.
>
> SVN already has
> sandbox/TextMarker/trunk... in other words, there's no "uima-" in front of
> TextMarker.
>
> (I slightly prefer all lower case, but don't change this unless you want to:
> sandbox/textmarker/trunk.... )
>
> Under that, I would go for something which had "textmarker-" in front
>
> trunk (id: textmarker)
> textmarker-docbook
> textmarker-ep-addons
> textmarker-ep .... other eclipse plugins
> textmarker-core
> textmarker-parent (if necessary)
>
> This gives a uniform easy way to keep all these things associated :-) and it's
> shorter than uimaj-textmarker.
>
> However, please consider this just a suggestion... I think it's basically your call.
I agree. The shorter, the better.
Peter
> -Marshall
>
>
>>
>> Here's a proposal to discuss:
>>
>> sandbox
>> - uima-textmarker
>> -- trunk (artifact id: uima-textmarker)
>> --- uima-docbook-textmarker
>> --- uimaj-ep-textmarker-addons
>> --- ...
>> --- uimaj-textmarker-core (was uimaj-textmarker with binary
>> "uima-textmarker.jar")
>> --- ...
>> --- uimaj-textmarker-parent (if necessary)
>>
>>
>> Best,
>>
>> Peter
>>
>>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
On 1/30/2013 5:16 AM, Peter Klügl wrote:
> On 29.01.2013 23:53, Marshall Schor wrote:
>> Hi,
>>
>> I would suggest that you consider making the top level name of your project
>> "textmarker" (without uimaj- in front). The uimaj prefix is strongly associated
>> with the Java SDK for UIMA.
>>
>> (We have releases named uima-as (no "j") and uima-cpp, and many sandbox/addon
>> projects with simple names that denote what they are.)
>
> No problem. The artifact id and projects should stay the same?
I think the artifact-id in the POM used when importing to generate the Eclipse
Project name.
So, the group name stays the same (org.apache.uima) of course, but the artifact
name probably should follow some simple convention suggesting
belonging-to-textmarker.
SVN already has
sandbox/TextMarker/trunk... in other words, there's no "uima-" in front of
TextMarker.
(I slightly prefer all lower case, but don't change this unless you want to:
sandbox/textmarker/trunk.... )
Under that, I would go for something which had "textmarker-" in front
trunk (id: textmarker)
textmarker-docbook
textmarker-ep-addons
textmarker-ep .... other eclipse plugins
textmarker-core
textmarker-parent (if necessary)
This gives a uniform easy way to keep all these things associated :-) and it's
shorter than uimaj-textmarker.
However, please consider this just a suggestion... I think it's basically your call.
-Marshall
>
>
> Here's a proposal to discuss:
>
> sandbox
> - uima-textmarker
> -- trunk (artifact id: uima-textmarker)
> --- uima-docbook-textmarker
> --- uimaj-ep-textmarker-addons
> --- ...
> --- uimaj-textmarker-core (was uimaj-textmarker with binary
> "uima-textmarker.jar")
> --- ...
> --- uimaj-textmarker-parent (if necessary)
>
>
> Best,
>
> Peter
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 29.01.2013 23:53, Marshall Schor wrote:
> Hi,
>
> I would suggest that you consider making the top level name of your project
> "textmarker" (without uimaj- in front). The uimaj prefix is strongly associated
> with the Java SDK for UIMA.
>
> (We have releases named uima-as (no "j") and uima-cpp, and many sandbox/addon
> projects with simple names that denote what they are.)
No problem. The artifact id and projects should stay the same?
Here's a proposal to discuss:
sandbox
- uima-textmarker
-- trunk (artifact id: uima-textmarker)
--- uima-docbook-textmarker
--- uimaj-ep-textmarker-addons
--- ...
--- uimaj-textmarker-core (was uimaj-textmarker with binary
"uima-textmarker.jar")
--- ...
--- uimaj-textmarker-parent (if necessary)
Best,
Peter
> Cheers. -Marshall
>
>
> On 1/28/2013 8:58 AM, Peter Klügl wrote:
>> Hi,
>>
>> the second release candidate of the sandbox project Apache UIMA TextMarker is
>> ready for voting. This vote also includes our new composite repository.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-183/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Composite repository with three update sites: uimaj, uima-as and
>> uima-textmarker-2.0.0:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>>
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>>
>> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
>> They can also be found here:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>>
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0 Don't care
>> [ ] -1 Not OK to release, because ...
>>
>> Thanks.
>>
>> Peter
>>
>>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
Hi,
I would suggest that you consider making the top level name of your project
"textmarker" (without uimaj- in front). The uimaj prefix is strongly associated
with the Java SDK for UIMA.
(We have releases named uima-as (no "j") and uima-cpp, and many sandbox/addon
projects with simple names that denote what they are.)
Cheers. -Marshall
On 1/28/2013 8:58 AM, Peter Klügl wrote:
> Hi,
>
> the second release candidate of the sandbox project Apache UIMA TextMarker is
> ready for voting. This vote also includes our new composite repository.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-183/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Composite repository with three update sites: uimaj, uima-as and
> uima-textmarker-2.0.0:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>
> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
> They can also be found here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
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
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
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?
=============================
>
>> 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
release.
(Apologies for the long note)
-Marshall
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
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
> 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.
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. Even users of the
workbench will eventually integrate the developed analysis engines in
some applications that are maybe built with maven. Then, there should
maybe also be the option to download all binaries (uima-textmarker.jar
and the plugins), similar to the uimaj release. If not, then non-maven
developers have to get/download somehow the update site and add the
engine plugin as an library.
> 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.
Best,
Peter
> -Marshall
>
> On 1/28/2013 8:58 AM, Peter Klügl wrote:
>> Hi,
>>
>> the second release candidate of the sandbox project Apache UIMA TextMarker is
>> ready for voting. This vote also includes our new composite repository.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-183/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Composite repository with three update sites: uimaj, uima-as and
>> uima-textmarker-2.0.0:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>>
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>>
>> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
>> They can also be found here:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>>
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0 Don't care
>> [ ] -1 Not OK to release, because ...
>>
>> Thanks.
>>
>> Peter
>>
>>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
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 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:
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.
So, there's no need to include them here, I think.
-Marshall
On 1/28/2013 8:58 AM, Peter Klügl wrote:
> Hi,
>
> the second release candidate of the sandbox project Apache UIMA TextMarker is
> ready for voting. This vote also includes our new composite repository.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-183/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Composite repository with three update sites: uimaj, uima-as and
> uima-textmarker-2.0.0:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>
> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
> They can also be found here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Hi,
I never thought much about it since I observed similar warnings for the
uimaj-ep-runtime plugin:
[INFO] --- maven-bundle-plugin:2.3.4:manifest (uima-bundle) @
uimaj-ep-runtime ---
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Manifest-Version
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Created-By
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Built-By
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Build-Jdk
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Implementation-Title
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Implementation-Version
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Implementation-Vendor-Id
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Implementation-Vendor
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Build-Date
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Project-Title
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Implementation-Url
28.01.2013 19:30:04 java.util.jar.Attributes read
WARNUNG: Duplicate name in Manifest: Implementation-License
Best,
Peter
Am 28.01.2013 18:32, schrieb Marshall Schor:
> If you build twice from the "top level" using mvn clean install or mvn install -
> it works OK. but if you build the subcomponent uimaj-ep-textmarker-engine after
> it has been built once, it gives a lot of warnings about Duplicate Name in
> Manifest. This is just a "warning", and the overall indicator from maven at the
> end is "success".
>
> An example:
>
> [INFO] --- maven-bundle-plugin:2.3.4:manifest (uima-bundle) @
> uimaj-ep-textmarker-engine ---
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Manifest-Version.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Created-By.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Built-By.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Build-Jdk.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Implementation-Version.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Implementation-Vendor-Id.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Implementation-Vendor.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Project-Title.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Implementation-Url.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Implementation-License.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
> WARNING: Duplicate name in Manifest: Build-Date.
> Ensure that the manifest does not have duplicate entries, and
> that blank lines separate individual sections in both your
> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
>
>
> If I look at the built manifest (inside the Jar), I don't see any duplicates.
> So I don't know if this is a real issue or not.
>
> -M
>
>
> On 1/28/2013 8:58 AM, Peter Klügl wrote:
>> Hi,
>>
>> the second release candidate of the sandbox project Apache UIMA TextMarker is
>> ready for voting. This vote also includes our new composite repository.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-183/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Composite repository with three update sites: uimaj, uima-as and
>> uima-textmarker-2.0.0:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>>
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>>
>> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
>> They can also be found here:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>>
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0 Don't care
>> [ ] -1 Not OK to release, because ...
>>
>> Thanks.
>>
>> Peter
>>
>>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
If you build twice from the "top level" using mvn clean install or mvn install -
it works OK. but if you build the subcomponent uimaj-ep-textmarker-engine after
it has been built once, it gives a lot of warnings about Duplicate Name in
Manifest. This is just a "warning", and the overall indicator from maven at the
end is "success".
An example:
[INFO] --- maven-bundle-plugin:2.3.4:manifest (uima-bundle) @
uimaj-ep-textmarker-engine ---
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Created-By.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Built-By.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Build-Jdk.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Implementation-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Implementation-Vendor-Id.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Implementation-Vendor.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Project-Title.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Implementation-Url.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Implementation-License.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Jan 28, 2013 10:51:49 AM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Build-Date.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
If I look at the built manifest (inside the Jar), I don't see any duplicates.
So I don't know if this is a real issue or not.
-M
On 1/28/2013 8:58 AM, Peter Klügl wrote:
> Hi,
>
> the second release candidate of the sandbox project Apache UIMA TextMarker is
> ready for voting. This vote also includes our new composite repository.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-183/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Composite repository with three update sites: uimaj, uima-as and
> uima-textmarker-2.0.0:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>
> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
> They can also be found here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
On 1/29/2013 5:03 PM, Peter Klügl wrote:
> Am 29.01.2013 21:49, schrieb Marshall Schor:
>> I notice that the top level project (the one you run mvn install on to build
>> everything) is uimaj-textmarker-parent.
>>
>> This is different from the conventions of other projects - where the top level
>> would have been something like:
>>
>> uimaj-textmarker.
>>
>
> I agree. I chose this layout after the discussion of Richard and you about
> this topic, but I do not really have a strong opinion about it.
>
> I would have named the reactor/top level project "uimaj-textmarker", but there
> was already a project with this name, the implementation of the analysis
> engine and rule inference, which can be renamed to "uimaj-textmarker-core".
The prefix uimaj I think is by convention used for the Java UIMA SDK. I would
suggest to make it easier on your user community to make a smaller name - such
as "textmarker" for your top level project :-) It will be under the Maven group
name "org.apache.uima", so adding uimaj is probably redundant for the textmarker
project.
-M
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 29.01.2013 21:49, schrieb Marshall Schor:
> I notice that the top level project (the one you run mvn install on to build
> everything) is uimaj-textmarker-parent.
>
> This is different from the conventions of other projects - where the top level
> would have been something like:
>
> uimaj-textmarker.
>
I agree. I chose this layout after the discussion of Richard and you
about this topic, but I do not really have a strong opinion about it.
I would have named the reactor/top level project "uimaj-textmarker", but
there was already a project with this name, the implementation of the
analysis engine and rule inference, which can be renamed to
"uimaj-textmarker-core".
> I don't think this is a blocker, but if things are worked on before another
> release, it might be good to change this.
I agree :-)
Best,
Peter
> The convention other multi-module projects take is to have a top level project,
>
> XXX
>
> have a <modules> statement that specifies the included projects. Among those is
> a project conventionally named
> XXX-parent
>
> This project is a "pom" project which just has the shared Parent Pom for the
> project. In some cases, it's not needed, if the project has no pom "factoring"
> that isn't already provided by the higher level poms - the common UIMA parent
> pom and the common Apache parent pom.
>
> Most projects have this so they can override the common UIMA parent pom (often,
> just until the common UIMA parent pom is updated and released).
>
> -Marshall
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
I notice that the top level project (the one you run mvn install on to build
everything) is uimaj-textmarker-parent.
This is different from the conventions of other projects - where the top level
would have been something like:
uimaj-textmarker.
I don't think this is a blocker, but if things are worked on before another
release, it might be good to change this.
The convention other multi-module projects take is to have a top level project,
XXX
have a <modules> statement that specifies the included projects. Among those is
a project conventionally named
XXX-parent
This project is a "pom" project which just has the shared Parent Pom for the
project. In some cases, it's not needed, if the project has no pom "factoring"
that isn't already provided by the higher level poms - the common UIMA parent
pom and the common Apache parent pom.
Most projects have this so they can override the common UIMA parent pom (often,
just until the common UIMA parent pom is updated and released).
-Marshall
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 30.01.2013 09:15, Richard Eckart de Castilho wrote:
> Am 30.01.2013 um 00:13 schrieb Marshall Schor <ms...@schor.com>:
>
>> On 1/29/2013 4:31 PM, Richard Eckart de Castilho wrote:
>>
>>> Any ideas where those artifacts can best be hosted?
>> Maven central sounds like a great place :-). If you know how to do this, why
>> not take a run at doing it?
> I'll have a look.
>
> @Peter: are there any source or javadoc artifacts for these OSGi jars that could be deployed to Maven Central as well?
I don't know of any right now. We could maybe build these files
manually, but I don't think we should do that.
Peter
>> I do note that the builds I'm doing are complaining
>> about missing POMs for some of these, so if you do it, I hope the POMs come with it:
>>
>> [WARNING] Missing POM for org.eclipse.equinox:app:jar:1.0.0
>> [WARNING] Missing POM for org.eclipse.emf:ecore:jar:2.4.0
>> [WARNING] Missing POM for org.eclipse.emf.ecore:xmi:jar:2.4.0
>> [WARNING] Missing POM for org.eclipse.dltk:core:jar:3.0.0
>> [WARNING] Missing POM for org.eclipse.dltk:ui:jar:3.0.0
>> [WARNING] Missing POM for org.eclipse.dltk:debug:jar:3.0.0
>
> Well, that's a feature, not a bug. The Eclipse artifacts, Peters as well as the official artifacts, use version ranges in the dependencies. Apparently Maven often if not always tries to fetch the POM for the artifact at the lowest listed version. Most of the time, that is bound to fail, because such an artifact simply does not exist. For example, the lowest version of org.eclipse.equinox:app:jar is 1.0.0-v20070606, there is no 1.0.0 version.
>
> I do not know where these warnings are created, if in the Maven core or by plugins that do not know how to deal with version ranges.
>
> See also: https://issues.apache.org/jira/browse/UIMA-2530
>
> -- Richard
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
Am 11.02.2013 um 22:20 schrieb Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>:
> Am 11.02.2013 um 22:01 schrieb Marshall Schor <ms...@schor.com>:
>
>> Thanks for taking this on :-)
>>
>> I thought these artifacts were Eclipse packages - Don't these (usually) have source?
>
> Well, they must have sources unless somebody out there is writing byte-code by hand ;) … I don't know if source bundles are available for all of these bundles, though.
The reason why I think that some bundles may come without companion source bundles is, that they may be just "warping" regular JARs with additional OSGi meta-data - the icu bundle could be such a thing. Another doubt I have is whether one Eclipse source bundle always corresponds to one binary bundle, like in Maven. I believe to remember having seen one source bundle covering multiple binary bundles. Finally, I do not know how to force Eclipse to download source bundles if they are not part of a feature. Eclipse update sites usually don't seem to be easily accessible with a browser, which would allow to manually download locate and download source bundles.
-- Richard
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
On 2/13/2013 7:10 AM, Peter Klügl wrote:
> On 11.02.2013 22:20, Richard Eckart de Castilho wrote:
>> Am 11.02.2013 um 22:01 schrieb Marshall Schor <ms...@schor.com>:
>>
>>> Thanks for taking this on :-)
>>>
>>> I thought these artifacts were Eclipse packages - Don't these (usually) have
>>> source?
>> Well, they must have sources unless somebody out there is writing byte-code
>> by hand ;) The problem is that the "eclipse:to-maven" goal doesn't convert
>> the sources. There appears to be an interesting project called
>> "maven-osgi-repo" [1] which can claims to support the conversion of Eclipse
>> source bundles as well. It doesn't say anything about JavaDoc, but that
>> should be doable once the source is there.
>>
>> Looking into my Eclipse "plugins" folder, there are some bundles that have a
>> companion "source" bundle, and others that do not. It may be possible to set
>> up an Eclipse target definition that includes all the bundles required by
>> TextMarker including their source bundles. I don't know if source bundles are
>> available for all of these bundles, though.
>>
>> The next sensible steps would be to get a target platform set up, try the
>> maven-osgi-repo, and hope all the sources are available and all the bundles
>> are convertible. If that works out, something would need to be done to build
>> the JavaDoc artifacts. Ant may come in handy.
>>
>> Anybody is welcome to step in and try things. Otherwise, I'll keep this on
>> the back burner, getting back to it as time permits and of course posting any
>> news.
>>
>> Cheers,
>
> Thanks Richard for digging into this.
>
> maven-osgi-repo sounds great, but is it an applicable solution for us? Would
> ASF servers host it?
>
> I always get back to the idea of using tycho, which would solve all related
> problems. However, it will create new ones since it requires some changes that
> are not in line with how the other projects are structured, e.g., the artifact
> id needs to correspond to the bundle id/name.
>
> If I understood the answer to Marshalls question correctly, then the artifacts
> hosted by Richard are not a critical blocker, right?
I think it's not a blocker, but it's unstable, a bit - because it's more likely
that Richard's hosting will (at some point in time) go away, and then we can't
build...
It would be great to get these into Maven Central...
-Marshall
>
> Peter
>
>
>> -- Richard
>>
>> [1] http://code.google.com/p/maven-osgi-repo/
>>
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
Am 13.02.2013 um 13:10 schrieb Peter Klügl <pk...@uni-wuerzburg.de>:
> Thanks Richard for digging into this.
>
> maven-osgi-repo sounds great, but is it an applicable solution for us? Would ASF servers host it?
My idea was to use it to prepare the Maven artifacts and then do a bulk-upload of them to Maven Central via Sonatype. It's not necessary to host it as an active service, just to use it as a conversion tool.
-- Richard
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 11.02.2013 22:20, Richard Eckart de Castilho wrote:
> Am 11.02.2013 um 22:01 schrieb Marshall Schor <ms...@schor.com>:
>
>> Thanks for taking this on :-)
>>
>> I thought these artifacts were Eclipse packages - Don't these (usually) have source?
> Well, they must have sources unless somebody out there is writing byte-code by hand ;) The problem is that the "eclipse:to-maven" goal doesn't convert the sources. There appears to be an interesting project called "maven-osgi-repo" [1] which can claims to support the conversion of Eclipse source bundles as well. It doesn't say anything about JavaDoc, but that should be doable once the source is there.
>
> Looking into my Eclipse "plugins" folder, there are some bundles that have a companion "source" bundle, and others that do not. It may be possible to set up an Eclipse target definition that includes all the bundles required by TextMarker including their source bundles. I don't know if source bundles are available for all of these bundles, though.
>
> The next sensible steps would be to get a target platform set up, try the maven-osgi-repo, and hope all the sources are available and all the bundles are convertible. If that works out, something would need to be done to build the JavaDoc artifacts. Ant may come in handy.
>
> Anybody is welcome to step in and try things. Otherwise, I'll keep this on the back burner, getting back to it as time permits and of course posting any news.
>
> Cheers,
Thanks Richard for digging into this.
maven-osgi-repo sounds great, but is it an applicable solution for us?
Would ASF servers host it?
I always get back to the idea of using tycho, which would solve all
related problems. However, it will create new ones since it requires
some changes that are not in line with how the other projects are
structured, e.g., the artifact id needs to correspond to the bundle id/name.
If I understood the answer to Marshalls question correctly, then the
artifacts hosted by Richard are not a critical blocker, right?
Peter
> -- Richard
>
> [1] http://code.google.com/p/maven-osgi-repo/
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
Am 11.02.2013 um 22:01 schrieb Marshall Schor <ms...@schor.com>:
> Thanks for taking this on :-)
>
> I thought these artifacts were Eclipse packages - Don't these (usually) have source?
Well, they must have sources unless somebody out there is writing byte-code by hand ;) The problem is that the "eclipse:to-maven" goal doesn't convert the sources. There appears to be an interesting project called "maven-osgi-repo" [1] which can claims to support the conversion of Eclipse source bundles as well. It doesn't say anything about JavaDoc, but that should be doable once the source is there.
Looking into my Eclipse "plugins" folder, there are some bundles that have a companion "source" bundle, and others that do not. It may be possible to set up an Eclipse target definition that includes all the bundles required by TextMarker including their source bundles. I don't know if source bundles are available for all of these bundles, though.
The next sensible steps would be to get a target platform set up, try the maven-osgi-repo, and hope all the sources are available and all the bundles are convertible. If that works out, something would need to be done to build the JavaDoc artifacts. Ant may come in handy.
Anybody is welcome to step in and try things. Otherwise, I'll keep this on the back burner, getting back to it as time permits and of course posting any news.
Cheers,
-- Richard
[1] http://code.google.com/p/maven-osgi-repo/
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
Thanks for taking this on :-)
I thought these artifacts were Eclipse packages - Don't these (usually) have source?
-Marshall
On 2/11/2013 12:40 PM, Richard Eckart de Castilho wrote:
> Getting the artifacts deployed via the "normal" route [1] is problematic because it is a really large number that would all need to be bundled up individually one bundle per artifact. Additionally there are no sources and no JavaDoc.
>
> I posted an inquiry with Sonatype to see if they have any suggestion or stance on hosting such artifacts on Maven Central
>
> https://issues.sonatype.org/browse/OSSRH-5383
>
> -- Richard
>
> [1] https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
>
> Am 30.01.2013 um 09:15 schrieb Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>:
>
>> Am 30.01.2013 um 00:13 schrieb Marshall Schor <ms...@schor.com>:
>>
>>> On 1/29/2013 4:31 PM, Richard Eckart de Castilho wrote:
>>>
>>>> Any ideas where those artifacts can best be hosted?
>>> Maven central sounds like a great place :-). If you know how to do this, why
>>> not take a run at doing it?
>> I'll have a look.
>>
>> @Peter: are there any source or javadoc artifacts for these OSGi jars that could be deployed to Maven Central as well?
>>
>>> I do note that the builds I'm doing are complaining
>>> about missing POMs for some of these, so if you do it, I hope the POMs come with it:
>>>
>>> [WARNING] Missing POM for org.eclipse.equinox:app:jar:1.0.0
>>> [WARNING] Missing POM for org.eclipse.emf:ecore:jar:2.4.0
>>> [WARNING] Missing POM for org.eclipse.emf.ecore:xmi:jar:2.4.0
>>> [WARNING] Missing POM for org.eclipse.dltk:core:jar:3.0.0
>>> [WARNING] Missing POM for org.eclipse.dltk:ui:jar:3.0.0
>>> [WARNING] Missing POM for org.eclipse.dltk:debug:jar:3.0.0
>>
>> Well, that's a feature, not a bug. The Eclipse artifacts, Peters as well as the official artifacts, use version ranges in the dependencies. Apparently Maven often if not always tries to fetch the POM for the artifact at the lowest listed version. Most of the time, that is bound to fail, because such an artifact simply does not exist. For example, the lowest version of org.eclipse.equinox:app:jar is 1.0.0-v20070606, there is no 1.0.0 version.
>>
>> I do not know where these warnings are created, if in the Maven core or by plugins that do not know how to deal with version ranges.
>>
>> See also: https://issues.apache.org/jira/browse/UIMA-2530
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
Getting the artifacts deployed via the "normal" route [1] is problematic because it is a really large number that would all need to be bundled up individually one bundle per artifact. Additionally there are no sources and no JavaDoc.
I posted an inquiry with Sonatype to see if they have any suggestion or stance on hosting such artifacts on Maven Central
https://issues.sonatype.org/browse/OSSRH-5383
-- Richard
[1] https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
Am 30.01.2013 um 09:15 schrieb Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>:
> Am 30.01.2013 um 00:13 schrieb Marshall Schor <ms...@schor.com>:
>
>> On 1/29/2013 4:31 PM, Richard Eckart de Castilho wrote:
>>
>>> Any ideas where those artifacts can best be hosted?
>>
>> Maven central sounds like a great place :-). If you know how to do this, why
>> not take a run at doing it?
>
> I'll have a look.
>
> @Peter: are there any source or javadoc artifacts for these OSGi jars that could be deployed to Maven Central as well?
>
>> I do note that the builds I'm doing are complaining
>> about missing POMs for some of these, so if you do it, I hope the POMs come with it:
>>
>> [WARNING] Missing POM for org.eclipse.equinox:app:jar:1.0.0
>> [WARNING] Missing POM for org.eclipse.emf:ecore:jar:2.4.0
>> [WARNING] Missing POM for org.eclipse.emf.ecore:xmi:jar:2.4.0
>> [WARNING] Missing POM for org.eclipse.dltk:core:jar:3.0.0
>> [WARNING] Missing POM for org.eclipse.dltk:ui:jar:3.0.0
>> [WARNING] Missing POM for org.eclipse.dltk:debug:jar:3.0.0
>
>
> Well, that's a feature, not a bug. The Eclipse artifacts, Peters as well as the official artifacts, use version ranges in the dependencies. Apparently Maven often if not always tries to fetch the POM for the artifact at the lowest listed version. Most of the time, that is bound to fail, because such an artifact simply does not exist. For example, the lowest version of org.eclipse.equinox:app:jar is 1.0.0-v20070606, there is no 1.0.0 version.
>
> I do not know where these warnings are created, if in the Maven core or by plugins that do not know how to deal with version ranges.
>
> See also: https://issues.apache.org/jira/browse/UIMA-2530
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
Am 30.01.2013 um 00:13 schrieb Marshall Schor <ms...@schor.com>:
> On 1/29/2013 4:31 PM, Richard Eckart de Castilho wrote:
>
>> Any ideas where those artifacts can best be hosted?
>
> Maven central sounds like a great place :-). If you know how to do this, why
> not take a run at doing it?
I'll have a look.
@Peter: are there any source or javadoc artifacts for these OSGi jars that could be deployed to Maven Central as well?
> I do note that the builds I'm doing are complaining
> about missing POMs for some of these, so if you do it, I hope the POMs come with it:
>
> [WARNING] Missing POM for org.eclipse.equinox:app:jar:1.0.0
> [WARNING] Missing POM for org.eclipse.emf:ecore:jar:2.4.0
> [WARNING] Missing POM for org.eclipse.emf.ecore:xmi:jar:2.4.0
> [WARNING] Missing POM for org.eclipse.dltk:core:jar:3.0.0
> [WARNING] Missing POM for org.eclipse.dltk:ui:jar:3.0.0
> [WARNING] Missing POM for org.eclipse.dltk:debug:jar:3.0.0
Well, that's a feature, not a bug. The Eclipse artifacts, Peters as well as the official artifacts, use version ranges in the dependencies. Apparently Maven often if not always tries to fetch the POM for the artifact at the lowest listed version. Most of the time, that is bound to fail, because such an artifact simply does not exist. For example, the lowest version of org.eclipse.equinox:app:jar is 1.0.0-v20070606, there is no 1.0.0 version.
I do not know where these warnings are created, if in the Maven core or by plugins that do not know how to deal with version ranges.
See also: https://issues.apache.org/jira/browse/UIMA-2530
-- Richard
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
On 1/29/2013 4:31 PM, Richard Eckart de Castilho wrote:
> Am 28.01.2013 um 16:47 schrieb Marshall Schor <ms...@schor.com>:
>
>> I've asked for an opinion on the Legal discuss list regarding if it is OK to
>> have convenience builds pull artifacts from a univeristy (non-Maven controlled)
>> repository, since I see that textmarker is referencing
>> zoidberg.ukp.informatik.tu-darmstadt.de
>
> These are only Eclipse artifacts that I uploaded on our repository explicitly for enabling a Jenkins / Maven build without any extra setup. Now we know this works, it could be considered to do a third-party upload of these artifacts to Maven Central or host them anywhere else convenient. I'm not sure if Maven Central has a special policy regarding OSGi bundles… some artifacts appear to be in the "official" Maven Central, others are in that "special Eclipse" folder on central.
>
> Any ideas where those artifacts can best be hosted?
Maven central sounds like a great place :-). If you know how to do this, why
not take a run at doing it? I do note that the builds I'm doing are complaining
about missing POMs for some of these, so if you do it, I hope the POMs come with it:
[WARNING] Missing POM for org.eclipse.equinox:app:jar:1.0.0
[WARNING] Missing POM for org.eclipse.emf:ecore:jar:2.4.0
[WARNING] Missing POM for org.eclipse.emf.ecore:xmi:jar:2.4.0
[WARNING] Missing POM for org.eclipse.dltk:core:jar:3.0.0
[WARNING] Missing POM for org.eclipse.dltk:ui:jar:3.0.0
[WARNING] Missing POM for org.eclipse.dltk:debug:jar:3.0.0
-Marshall
-Marshall
>
> -- Richard
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
Am 28.01.2013 um 16:47 schrieb Marshall Schor <ms...@schor.com>:
> I've asked for an opinion on the Legal discuss list regarding if it is OK to
> have convenience builds pull artifacts from a univeristy (non-Maven controlled)
> repository, since I see that textmarker is referencing
> zoidberg.ukp.informatik.tu-darmstadt.de
These are only Eclipse artifacts that I uploaded on our repository explicitly for enabling a Jenkins / Maven build without any extra setup. Now we know this works, it could be considered to do a third-party upload of these artifacts to Maven Central or host them anywhere else convenient. I'm not sure if Maven Central has a special policy regarding OSGi bundles… some artifacts appear to be in the "official" Maven Central, others are in that "special Eclipse" folder on central.
Any ideas where those artifacts can best be hosted?
-- Richard
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
I've asked for an opinion on the Legal discuss list regarding if it is OK to
have convenience builds pull artifacts from a univeristy (non-Maven controlled)
repository, since I see that textmarker is referencing
zoidberg.ukp.informatik.tu-darmstadt.de
-Marshall
On 1/28/2013 8:58 AM, Peter Klügl wrote:
> Hi,
>
> the second release candidate of the sandbox project Apache UIMA TextMarker is
> ready for voting. This vote also includes our new composite repository.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-183/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Composite repository with three update sites: uimaj, uima-as and
> uima-textmarker-2.0.0:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>
> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
> They can also be found here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 30.01.2013 15:35, Marshall Schor wrote:
> On 1/29/2013 4:28 PM, Peter Klügl wrote:
>> Am 29.01.2013 20:19, schrieb Marshall Schor:
>>> Eclipse-update-site:
>>>
>>> I think that the name of the sub-site directory in the composite site should not
>>> have a version number. It won't be changing from version to version; within
>>> that directory, multiple versions will occur (over time) in the features/ and
>>> plugins/ directories.
>> My intension was to provide a subsite for each release. For
>> uima-textmarker-2.0.1 for example, we would just simply change the version
>> property (and some versions in category.xml), build the update site and then
>> add it as an additional folder to the composite repository. This would be a
>> bit less work than adding new artifacts to the update site. There would not be
>> any difference for the user and we do not have to touch already released
>> update sites.
> OK, I had not thought of that. It sounds like an interesting use of the
> composite update site approach.
> I wonder if there are any reasons to prefer one approach over the other.
>
> The only thing I can think of is that having one site with multiple feature
> versions and plugin versions allows potentially more "sharing", for instance in
> the case where a new version of some feature upgrades some (but not all) plugins.
>
> I don't have a strong feeling either way about this at the moment...
I keep the version number for now and we will see if the approach is
reasonable in practice.
Peter
> -Marshall
>> The next release in mind, I already added the version to the name of the folder.
>>
>> Anyways, this is nothing to argue about. If you prefer a single update site
>> for all version of a category, then I will remove the version in the next RC.
>>
>> Best,
>>
>> Peter
> <snip>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
On 1/29/2013 4:28 PM, Peter Klügl wrote:
> Am 29.01.2013 20:19, schrieb Marshall Schor:
>> Eclipse-update-site:
>>
>> I think that the name of the sub-site directory in the composite site should not
>> have a version number. It won't be changing from version to version; within
>> that directory, multiple versions will occur (over time) in the features/ and
>> plugins/ directories.
>
> My intension was to provide a subsite for each release. For
> uima-textmarker-2.0.1 for example, we would just simply change the version
> property (and some versions in category.xml), build the update site and then
> add it as an additional folder to the composite repository. This would be a
> bit less work than adding new artifacts to the update site. There would not be
> any difference for the user and we do not have to touch already released
> update sites.
OK, I had not thought of that. It sounds like an interesting use of the
composite update site approach.
I wonder if there are any reasons to prefer one approach over the other.
The only thing I can think of is that having one site with multiple feature
versions and plugin versions allows potentially more "sharing", for instance in
the case where a new version of some feature upgrades some (but not all) plugins.
I don't have a strong feeling either way about this at the moment...
-Marshall
>
> The next release in mind, I already added the version to the name of the folder.
>
> Anyways, this is nothing to argue about. If you prefer a single update site
> for all version of a category, then I will remove the version in the next RC.
>
> Best,
>
> Peter
<snip>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 29.01.2013 20:19, schrieb Marshall Schor:
> Eclipse-update-site:
>
> I think that the name of the sub-site directory in the composite site should not
> have a version number. It won't be changing from version to version; within
> that directory, multiple versions will occur (over time) in the features/ and
> plugins/ directories.
My intension was to provide a subsite for each release. For
uima-textmarker-2.0.1 for example, we would just simply change the
version property (and some versions in category.xml), build the update
site and then add it as an additional folder to the composite
repository. This would be a bit less work than adding new artifacts to
the update site. There would not be any difference for the user and we
do not have to touch already released update sites.
The next release in mind, I already added the version to the name of the
folder.
Anyways, this is nothing to argue about. If you prefer a single update
site for all version of a category, then I will remove the version in
the next RC.
Best,
Peter
> -Marshall
> On 1/28/2013 8:58 AM, Peter Klügl wrote:
>> Hi,
>>
>> the second release candidate of the sandbox project Apache UIMA TextMarker is
>> ready for voting. This vote also includes our new composite repository.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-183/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Composite repository with three update sites: uimaj, uima-as and
>> uima-textmarker-2.0.0:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>>
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>>
>> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
>> They can also be found here:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>>
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0 Don't care
>> [ ] -1 Not OK to release, because ...
>>
>> Thanks.
>>
>> Peter
>>
>>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
Eclipse-update-site:
I think that the name of the sub-site directory in the composite site should not
have a version number. It won't be changing from version to version; within
that directory, multiple versions will occur (over time) in the features/ and
plugins/ directories.
-Marshall
On 1/28/2013 8:58 AM, Peter Klügl wrote:
> Hi,
>
> the second release candidate of the sandbox project Apache UIMA TextMarker is
> ready for voting. This vote also includes our new composite repository.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-183/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Composite repository with three update sites: uimaj, uima-as and
> uima-textmarker-2.0.0:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>
> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
> They can also be found here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>
>
Re: Eclipse Update Site licenses for TextMarker
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 31.01.2013 20:58, schrieb Peter Klügl:
> Am 31.01.2013 20:48, schrieb Marshall Schor:
>> Re: Eclipse update site for textmarker:
>>
>> It shows 3 license files, but maybe is still missing something.
>> It shows 2 for the Eclipse license (2 version dates), and
>> the Apache v2.0 license.
>>
>> But I thought the TextMarker binary build had other things needing
>> additional
>> licenses embedded in it? Those licenses need to be included and
>> shown to the
>> user in the Eclipse accept-license dialog, somehow.
>
> Whoops, I forgot that.
>
>> The Eclipse installer has the ability to resolve dependencies at
>> install time,
>> fetching OSGi components from other repositories that Eclipse knows
>> about. If
>> it's possible, that would be a good packaging for the dependent
>> components with
>> other licenses. (I'm guessing that you looked into that and found it
>> was not
>> possible, and therefore bundled things into your Plugin Jars.)
>
> I haven't found anything and other options were less confortable. I
> will do some research again, but I am not optimistic.
>
>> When the license is shown, there may be 2 ways to have Eclipse
>> install show it.
>>
>> 1) as a separate license - meaning, in the window where Eclipse shows
>> licenses,
>> on the left panel there would be multiple lines.
>> 2) as a chain of licenses shown together in one window on the right
>> panel where
>> Eclipse is showing licenses.
>>
>> I have a very slight preference for style 1) if it is do-able... (I
>> haven't
>> investigated this).
>
> I will try 1)
I haven't found a way to implement 1) yet and fixed it with 2) for now.
Two related links:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=216911
https://bugs.eclipse.org/bugs/show_bug.cgi?id=328620
Peter
>
> Best,
>
> Peter
>> -Marshall
Re: Eclipse Update Site licenses for TextMarker
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 31.01.2013 20:48, schrieb Marshall Schor:
> Re: Eclipse update site for textmarker:
>
> It shows 3 license files, but maybe is still missing something.
> It shows 2 for the Eclipse license (2 version dates), and
> the Apache v2.0 license.
>
> But I thought the TextMarker binary build had other things needing additional
> licenses embedded in it? Those licenses need to be included and shown to the
> user in the Eclipse accept-license dialog, somehow.
Whoops, I forgot that.
> The Eclipse installer has the ability to resolve dependencies at install time,
> fetching OSGi components from other repositories that Eclipse knows about. If
> it's possible, that would be a good packaging for the dependent components with
> other licenses. (I'm guessing that you looked into that and found it was not
> possible, and therefore bundled things into your Plugin Jars.)
I haven't found anything and other options were less confortable. I will
do some research again, but I am not optimistic.
> When the license is shown, there may be 2 ways to have Eclipse install show it.
>
> 1) as a separate license - meaning, in the window where Eclipse shows licenses,
> on the left panel there would be multiple lines.
> 2) as a chain of licenses shown together in one window on the right panel where
> Eclipse is showing licenses.
>
> I have a very slight preference for style 1) if it is do-able... (I haven't
> investigated this).
I will try 1)
Best,
Peter
> -Marshall
Re: Eclipse Update Site licenses for TextMarker
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 31.01.2013 20:58, schrieb Marshall Schor:
> One more thing - the other licenses show a one-line "title" in the left window
> (of the Eclipse license acceptance screen), and the license in the right window.
>
> For the text marker license, the "title" seems to be the first few words of the
> license.
> (Not a blocker, but would be nice to fix).
There is no title. Instead, the first line of the license text is used.
We can change this also for the other uima features (I have copied their
license string for the TextMarker feature).
Best,
Peter
> -Marshall
> On 1/31/2013 2:48 PM, Marshall Schor wrote:
>> Re: Eclipse update site for textmarker:
>>
>> It shows 3 license files, but maybe is still missing something.
>> It shows 2 for the Eclipse license (2 version dates), and
>> the Apache v2.0 license.
>>
>> But I thought the TextMarker binary build had other things needing additional
>> licenses embedded in it? Those licenses need to be included and shown to the
>> user in the Eclipse accept-license dialog, somehow.
>>
>> The Eclipse installer has the ability to resolve dependencies at install time,
>> fetching OSGi components from other repositories that Eclipse knows about. If
>> it's possible, that would be a good packaging for the dependent components with
>> other licenses. (I'm guessing that you looked into that and found it was not
>> possible, and therefore bundled things into your Plugin Jars.)
>>
>> When the license is shown, there may be 2 ways to have Eclipse install show it.
>>
>> 1) as a separate license - meaning, in the window where Eclipse shows licenses,
>> on the left panel there would be multiple lines.
>> 2) as a chain of licenses shown together in one window on the right panel where
>> Eclipse is showing licenses.
>>
>> I have a very slight preference for style 1) if it is do-able... (I haven't
>> investigated this).
>>
>> -Marshall
>>
>>
>>
>>
Re: Eclipse Update Site licenses for TextMarker
Posted by Marshall Schor <ms...@schor.com>.
One more thing - the other licenses show a one-line "title" in the left window
(of the Eclipse license acceptance screen), and the license in the right window.
For the text marker license, the "title" seems to be the first few words of the
license.
(Not a blocker, but would be nice to fix).
-Marshall
On 1/31/2013 2:48 PM, Marshall Schor wrote:
> Re: Eclipse update site for textmarker:
>
> It shows 3 license files, but maybe is still missing something.
> It shows 2 for the Eclipse license (2 version dates), and
> the Apache v2.0 license.
>
> But I thought the TextMarker binary build had other things needing additional
> licenses embedded in it? Those licenses need to be included and shown to the
> user in the Eclipse accept-license dialog, somehow.
>
> The Eclipse installer has the ability to resolve dependencies at install time,
> fetching OSGi components from other repositories that Eclipse knows about. If
> it's possible, that would be a good packaging for the dependent components with
> other licenses. (I'm guessing that you looked into that and found it was not
> possible, and therefore bundled things into your Plugin Jars.)
>
> When the license is shown, there may be 2 ways to have Eclipse install show it.
>
> 1) as a separate license - meaning, in the window where Eclipse shows licenses,
> on the left panel there would be multiple lines.
> 2) as a chain of licenses shown together in one window on the right panel where
> Eclipse is showing licenses.
>
> I have a very slight preference for style 1) if it is do-able... (I haven't
> investigated this).
>
> -Marshall
>
>
>
>
Re: Eclipse Update Site licenses for TextMarker
Posted by Marshall Schor <ms...@schor.com>.
Re: Eclipse update site for textmarker:
It shows 3 license files, but maybe is still missing something.
It shows 2 for the Eclipse license (2 version dates), and
the Apache v2.0 license.
But I thought the TextMarker binary build had other things needing additional
licenses embedded in it? Those licenses need to be included and shown to the
user in the Eclipse accept-license dialog, somehow.
The Eclipse installer has the ability to resolve dependencies at install time,
fetching OSGi components from other repositories that Eclipse knows about. If
it's possible, that would be a good packaging for the dependent components with
other licenses. (I'm guessing that you looked into that and found it was not
possible, and therefore bundled things into your Plugin Jars.)
When the license is shown, there may be 2 ways to have Eclipse install show it.
1) as a separate license - meaning, in the window where Eclipse shows licenses,
on the left panel there would be multiple lines.
2) as a chain of licenses shown together in one window on the right panel where
Eclipse is showing licenses.
I have a very slight preference for style 1) if it is do-able... (I haven't
investigated this).
-Marshall
Re: [VOTE][CANCELLED]] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Cancelling this vote and preparing TextMarker RC3
Peter
On 28.01.2013 14:58, Peter Klügl wrote:
> Hi,
>
> the second release candidate of the sandbox project Apache UIMA
> TextMarker is ready for voting. This vote also includes our new
> composite repository.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-183/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Composite repository with three update sites: uimaj, uima-as and
> uima-textmarker-2.0.0:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>
>
> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
> They can also be found here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 29.01.2013 22:16, Marshall Schor wrote:
> The top level README file in the source-release.zip file has ref to uimaFIT
> JCasGenPomFriendly - is this still current? It makes reference to setting
> configuration for maven-compiler-plugin - in addition to <excludes> it says to
> set the source/target level to 1.6.
>
> We normally pre-req 1.5. Does this need updating, or can the compiler-level
> spec be omitted (and maybe inherited from a parent pom)?
I think we can remove the level, but I have not used JCasGenPomFriendly
myself. Maybe Richard can comment this?
>
> =====================
>
> The same README says:
>
> do the build by going into the TextMarker directory, and issuing the command
> mvn clean install
>
> There is no TextMarker directory, but there is a uimaj-textmarker directory. if
> you cd to that, you get to build just the one module, not everything...
I will update this information when I change the SVN structure.
Peter
> -Marshall
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
The top level README file in the source-release.zip file has ref to uimaFIT
JCasGenPomFriendly - is this still current? It makes reference to setting
configuration for maven-compiler-plugin - in addition to <excludes> it says to
set the source/target level to 1.6.
We normally pre-req 1.5. Does this need updating, or can the compiler-level
spec be omitted (and maybe inherited from a parent pom)?
=====================
The same README says:
do the build by going into the TextMarker directory, and issuing the command
mvn clean install
There is no TextMarker directory, but there is a uimaj-textmarker directory. if
you cd to that, you get to build just the one module, not everything...
-Marshall
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
On 1/30/2013 5:27 AM, Peter Klügl wrote:
> Hi,
>
> On 30.01.2013 00:03, Marshall Schor wrote:
>> Hi,
>>
>> I compared the source-release zip (unzipped) with the svn export of the tag -
>> looks good.
>>
>> There's one difference: The svn has a .project file included in the
>> ExampleProject. It has some special build setup that might be "required" to
>> make the ExampleProject work with TextMarker:
>>
>> <buildSpec>
>> <buildCommand>
>> <name>org.eclipse.dltk.core.scriptbuilder</name>
>> <arguments>
>> </arguments>
>> </buildCommand>
>> </buildSpec>
>> <natures>
>> <nature>org.apache.uima.textmarker.ide.nature</nature>
>> </natures>
>>
>> If this is required, then it should have been in the source zip package, but
>> wasn't...
>
> No, it is not required for TextMarker. This project is an exemplary TextMarker
> project and therefore bound to Eclipse.
That's fine. I used the wrong word, "required". I meant, did you mean to
include this example as part of the release? It sounds like, "yes".
So it needs to be in the source-release.zip package. I'm guessing it's being
excluded by the normal (default) apache-wide assembly script for source-release
packages, which you can see inside this jar:
http://repo1.maven.org/maven2/org/apache/apache/resources/apache-source-release-assembly-descriptor/1.0.3/apache-source-release-assembly-descriptor-1.0.3.jar
The relevant parts are:
<!-- NOTE: Most of the following excludes should not be required
if the standard release process is followed. This is because the
release plugin checks out project sources into a location like
target/checkout, then runs the build from there. The result is
a source-release archive that comes from a pretty clean directory
structure.
HOWEVER, if the release plugin is configured to run extra goals
or generate a project website, it's definitely possible that some
of these files will be present. So, it's safer to exclude them.
-->
<!-- IDEs -->
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?maven-eclipse\.xml]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?\.project]</exclude>
The last line drops files with name .project.
To get these into your source-release, I think you have to either:
1) figure out an override for the standard set of excludes, or
2) figure out how to add this omitted file to the zip (a little ant script would
do the trick, I think)
3) rename the file to something that won't be excluded, and then have a
post-install fixup for the examples project,
... etc.
> I created this project for users to have an example on how TextMarker projects
> are sturctured and I am also using it in the documentation, e.g., because it
> also contains files for test-driven developement/backtesting.
>
>> If not required, then perhaps it should be deleted from svn. (I also see a
>> .buildpath checked into SVN - is that required for this project?).
>
> I really like to keep this project in SVN. Users should be able to "download"
> (checkout) this project in the TextMarker Workbench. I am also in favor of
> providing it somewhere for download.
>
> The .buildpath is part of a TextMarker project.
>
> Maybe we can place it somewhere different in SVN?
No, this is a fine place. THe only issue is that the .project is getting
excluded by default from the source-release. Just need to figure out a way to
get it added back :-).
-Marshall
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Hi,
On 30.01.2013 00:03, Marshall Schor wrote:
> Hi,
>
> I compared the source-release zip (unzipped) with the svn export of the tag -
> looks good.
>
> There's one difference: The svn has a .project file included in the
> ExampleProject. It has some special build setup that might be "required" to
> make the ExampleProject work with TextMarker:
>
> <buildSpec>
> <buildCommand>
> <name>org.eclipse.dltk.core.scriptbuilder</name>
> <arguments>
> </arguments>
> </buildCommand>
> </buildSpec>
> <natures>
> <nature>org.apache.uima.textmarker.ide.nature</nature>
> </natures>
>
> If this is required, then it should have been in the source zip package, but
> wasn't...
No, it is not required for TextMarker. This project is an exemplary
TextMarker project and therefore bound to Eclipse. I created this
project for users to have an example on how TextMarker projects are
sturctured and I am also using it in the documentation, e.g., because it
also contains files for test-driven developement/backtesting.
> If not required, then perhaps it should be deleted from svn. (I also see a
> .buildpath checked into SVN - is that required for this project?).
I really like to keep this project in SVN. Users should be able to
"download" (checkout) this project in the TextMarker Workbench. I am
also in favor of providing it somewhere for download.
The .buildpath is part of a TextMarker project.
Maybe we can place it somewhere different in SVN?
Best,
Peter
> -Marshall
>
> On 1/28/2013 8:58 AM, Peter Klügl wrote:
>> Hi,
>>
>> the second release candidate of the sandbox project Apache UIMA TextMarker is
>> ready for voting. This vote also includes our new composite repository.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-183/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Composite repository with three update sites: uimaj, uima-as and
>> uima-textmarker-2.0.0:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>>
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>>
>> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
>> They can also be found here:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>>
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0 Don't care
>> [ ] -1 Not OK to release, because ...
>>
>> Thanks.
>>
>> Peter
>>
>>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
Hi,
I compared the source-release zip (unzipped) with the svn export of the tag -
looks good.
There's one difference: The svn has a .project file included in the
ExampleProject. It has some special build setup that might be "required" to
make the ExampleProject work with TextMarker:
<buildSpec>
<buildCommand>
<name>org.eclipse.dltk.core.scriptbuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.apache.uima.textmarker.ide.nature</nature>
</natures>
If this is required, then it should have been in the source zip package, but
wasn't...
If not required, then perhaps it should be deleted from svn. (I also see a
.buildpath checked into SVN - is that required for this project?).
-Marshall
On 1/28/2013 8:58 AM, Peter Klügl wrote:
> Hi,
>
> the second release candidate of the sandbox project Apache UIMA TextMarker is
> ready for voting. This vote also includes our new composite repository.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-183/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Composite repository with three update sites: uimaj, uima-as and
> uima-textmarker-2.0.0:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>
> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
> They can also be found here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 29.01.2013 23:01, schrieb Marshall Schor:
> I tried building from the source-release unzip, at the top level (the
> uimaj-textmarker-parent project), using the -Dapache-release to see if it would
> build the source-release.zip - I don't think it did - or at least, I couldn't
> find it.
>
> Am I doing something incorrectly?
>
> -Marshall
I will check it tomorrow (on the machine I did the RC with).
Best,
Peter
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
I tried building from the source-release unzip, at the top level (the
uimaj-textmarker-parent project), using the -Dapache-release to see if it would
build the source-release.zip - I don't think it did - or at least, I couldn't
find it.
Am I doing something incorrectly?
-Marshall
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
On 1/29/2013 4:50 PM, Peter Klügl wrote:
> Am 29.01.2013 20:30, schrieb Marshall Schor:
>> Re: ...-sources.jar (and friends) files in
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin/
>>
>> I wonder if these are needed.
>
> This has the same reason that I mentioned in my last mail. It's just about
> facilitating the reviewing. In my opinion, we maybe have also a LICENSE
> problem in the ...-sources.jar files because of the icons. I think it is just
> easier to check it there instead of the staging repository.
OK, I misunderstood - I thought everything in the p.a.o/ ... spot was proposed
for inclusion in the Apache Mirror part of the release.
-M
>
>
>> When we do an Apache release, we typically make an official release of the all
>> the source as a ...-source-release.zip file.
>>
>> You have this file, as uimaj-textmarker-parent-2.0.0-source-release.zip (and
>> signing/checksum friends).
>>
>> I think this is enough, because it holds all of the sources. I don't see any
>> purpose in included for each separate plugin-Jar an individual sources-jar, in
>> this spot.
>>
>> I do see a purpose in including these in the set of files that go up to Maven
>> Central - as the m2e plugin knows about the conventions for these, and can
>> automagically fetch the source in Eclipse when needed :-).
>
> I completely agree.
>
> Best,
>
> Peter
>
>> -Marshall
>>
>> On 1/28/2013 8:58 AM, Peter Klügl wrote:
>>> Hi,
>>>
>>> the second release candidate of the sandbox project Apache UIMA TextMarker is
>>> ready for voting. This vote also includes our new composite repository.
>>>
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapacheuima-183/
>>>
>>> SVN tag:
>>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>>>
>>>
>>>
>>> Archive with all sources:
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>>>
>>>
>>>
>>> Composite repository with three update sites: uimaj, uima-as and
>>> uima-textmarker-2.0.0:
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>>>
>>>
>>>
>>> Binaries and sources:
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>>>
>>> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
>>> They can also be found here:
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>>
>>>
>>>
>>> Documentation (pdf file):
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>>>
>>>
>>>
>>> Please vote on release:
>>>
>>> [ ] +1 OK to release
>>> [ ] 0 Don't care
>>> [ ] -1 Not OK to release, because ...
>>>
>>> Thanks.
>>>
>>> Peter
>>>
>>>
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 29.01.2013 20:30, schrieb Marshall Schor:
> Re: ...-sources.jar (and friends) files in
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin/
>
> I wonder if these are needed.
This has the same reason that I mentioned in my last mail. It's just
about facilitating the reviewing. In my opinion, we maybe have also a
LICENSE problem in the ...-sources.jar files because of the icons. I
think it is just easier to check it there instead of the staging repository.
> When we do an Apache release, we typically make an official release of the all
> the source as a ...-source-release.zip file.
>
> You have this file, as uimaj-textmarker-parent-2.0.0-source-release.zip (and
> signing/checksum friends).
>
> I think this is enough, because it holds all of the sources. I don't see any
> purpose in included for each separate plugin-Jar an individual sources-jar, in
> this spot.
>
> I do see a purpose in including these in the set of files that go up to Maven
> Central - as the m2e plugin knows about the conventions for these, and can
> automagically fetch the source in Eclipse when needed :-).
I completely agree.
Best,
Peter
> -Marshall
>
> On 1/28/2013 8:58 AM, Peter Klügl wrote:
>> Hi,
>>
>> the second release candidate of the sandbox project Apache UIMA TextMarker is
>> ready for voting. This vote also includes our new composite repository.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-183/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Composite repository with three update sites: uimaj, uima-as and
>> uima-textmarker-2.0.0:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>>
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>>
>> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
>> They can also be found here:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>>
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0 Don't care
>> [ ] -1 Not OK to release, because ...
>>
>> Thanks.
>>
>> Peter
>>
>>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
Re: ...-sources.jar (and friends) files in
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin/
I wonder if these are needed.
When we do an Apache release, we typically make an official release of the all
the source as a ...-source-release.zip file.
You have this file, as uimaj-textmarker-parent-2.0.0-source-release.zip (and
signing/checksum friends).
I think this is enough, because it holds all of the sources. I don't see any
purpose in included for each separate plugin-Jar an individual sources-jar, in
this spot.
I do see a purpose in including these in the set of files that go up to Maven
Central - as the m2e plugin knows about the conventions for these, and can
automagically fetch the source in Eclipse when needed :-).
-Marshall
On 1/28/2013 8:58 AM, Peter Klügl wrote:
> Hi,
>
> the second release candidate of the sandbox project Apache UIMA TextMarker is
> ready for voting. This vote also includes our new composite repository.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-183/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Composite repository with three update sites: uimaj, uima-as and
> uima-textmarker-2.0.0:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>
> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
> They can also be found here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
On 1/28/2013 10:58 AM, Peter Klügl wrote:
> On 28.01.2013 16:06, Marshall Schor wrote:
>> Wow, this is a lot to review, and it just started snowing, with a forecast later
>> of ice/ freezing rain, so it looks like I'll be going home early...
>>
>> I printed out the 80 page (!) documentation, and will review that too. I did
>> notice the pub date is written in German :-) ...
>
> Interesting. Do you have an idea how to avoid the localization of
> project.properties.buildMonth?
Try setting the Java default Locale to English:
http://stackoverflow.com/questions/8809098/how-do-i-set-the-default-locale-for-my-jvm
-Marshall
>
> Peter
>
> PS: Thanks for your reviewing :-)
>
>> -Marshall
>> On 1/28/2013 8:58 AM, Peter Klügl wrote:
>>> Hi,
>>>
>>> the second release candidate of the sandbox project Apache UIMA TextMarker is
>>> ready for voting. This vote also includes our new composite repository.
>>>
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapacheuima-183/
>>>
>>> SVN tag:
>>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>>>
>>>
>>>
>>> Archive with all sources:
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>>>
>>>
>>>
>>> Composite repository with three update sites: uimaj, uima-as and
>>> uima-textmarker-2.0.0:
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>>>
>>>
>>>
>>> Binaries and sources:
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>>>
>>> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
>>> They can also be found here:
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>>
>>>
>>>
>>> Documentation (pdf file):
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>>>
>>>
>>>
>>> Please vote on release:
>>>
>>> [ ] +1 OK to release
>>> [ ] 0 Don't care
>>> [ ] -1 Not OK to release, because ...
>>>
>>> Thanks.
>>>
>>> Peter
>>>
>>>
>
>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 28.01.2013 16:06, Marshall Schor wrote:
> Wow, this is a lot to review, and it just started snowing, with a forecast later
> of ice/ freezing rain, so it looks like I'll be going home early...
>
> I printed out the 80 page (!) documentation, and will review that too. I did
> notice the pub date is written in German :-) ...
Interesting. Do you have an idea how to avoid the localization of
project.properties.buildMonth?
Peter
PS: Thanks for your reviewing :-)
> -Marshall
> On 1/28/2013 8:58 AM, Peter Klügl wrote:
>> Hi,
>>
>> the second release candidate of the sandbox project Apache UIMA TextMarker is
>> ready for voting. This vote also includes our new composite repository.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-183/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Composite repository with three update sites: uimaj, uima-as and
>> uima-textmarker-2.0.0:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>>
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>>
>> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
>> They can also be found here:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>>
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0 Don't care
>> [ ] -1 Not OK to release, because ...
>>
>> Thanks.
>>
>> Peter
>>
>>
Re: [VOTE] Apache UIMA TextMarker RC2 AND Composite Repository
Posted by Marshall Schor <ms...@schor.com>.
Wow, this is a lot to review, and it just started snowing, with a forecast later
of ice/ freezing rain, so it looks like I'll be going home early...
I printed out the 80 page (!) documentation, and will review that too. I did
notice the pub date is written in German :-) ...
-Marshall
On 1/28/2013 8:58 AM, Peter Klügl wrote:
> Hi,
>
> the second release candidate of the sandbox project Apache UIMA TextMarker is
> ready for voting. This vote also includes our new composite repository.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-183/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc2
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Composite repository with three update sites: uimaj, uima-as and
> uima-textmarker-2.0.0:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/eclipse-update-site
>
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/src_bin
>
> The issues fixed are in the RELEASE_NOTES.html in the src/bin packages.
> They can also be found here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0TextMarker%22%20AND%20component%20%3D%20TextMarker%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc2/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>
>