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/23 18:02:40 UTC
[VOTE] Apache UIMA TextMarker Release Candidate 1
Hi,
the first release candidate of the sandbox project Apache UIMA
TextMarker is ready for voting.
Staging repository:
https://repository.apache.org/content/repositories/orgapacheuima-163/
SVN tag:
https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
Archive with all sources:
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
Eclipse update site:
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
The update site only contains the UIMA TextMarker plugins and is not yet
integrated in the composite repository because the composite repository
is not yet officially released.
Binaries and sources:
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
As it is the first release, the report contains all fixed issues.
Documentation (pdf file):
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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 Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 24.01.2013 10:45, Peter Klügl wrote:
> There are two things I noticed so far:
>
> - When I try to install the feature in Eclipse, then it is not
> categorized and thus not visible with the default settings. Somehow,
> the update site is not correctly built with the categories. However,
> the installed feature works just fine (Win7 64bit).
>
> - the poms of the plugins have some naming problems. This is probably
> caused by using a property, which is not resolved by some maven plugin.
>
OK, this happens also when I try to "release" the CAS Editor
(org.apache.uima.caseditor_${parsedVersion.osgiVersion}.pom).
Can I ignore this?
> Example:
> org.apache.uima.textmarker.addons_${parsedVersion.osgiVersion}.pom
> in:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/src_bin/
>
> Peter
>
>
> On 23.01.2013 18:02, Peter Klügl wrote:
>> Hi,
>>
>> the first release candidate of the sandbox project Apache UIMA
>> TextMarker is ready for voting.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-163/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Eclipse update site:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
>>
>>
>> The update site only contains the UIMA TextMarker plugins and is not
>> yet integrated in the composite repository because the composite
>> repository is not yet officially released.
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
>>
>>
>> As it is the first release, the report contains all fixed issues.
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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 Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
There are two things I noticed so far:
- When I try to install the feature in Eclipse, then it is not
categorized and thus not visible with the default settings. Somehow, the
update site is not correctly built with the categories. However, the
installed feature works just fine (Win7 64bit).
- the poms of the plugins have some naming problems. This is probably
caused by using a property, which is not resolved by some maven plugin.
Example: org.apache.uima.textmarker.addons_${parsedVersion.osgiVersion}.pom
in:
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/src_bin/
Peter
On 23.01.2013 18:02, Peter Klügl wrote:
> Hi,
>
> the first release candidate of the sandbox project Apache UIMA
> TextMarker is ready for voting.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-163/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Eclipse update site:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
>
>
> The update site only contains the UIMA TextMarker plugins and is not
> yet integrated in the composite repository because the composite
> repository is not yet officially released.
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
>
>
> As it is the first release, the report contains all fixed issues.
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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][CANCELLED] Apache UIMA TextMarker Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
I'm cancelling this vote, there's another vote for release candidate 2 now starting.
-Marshall
On 1/23/2013 12:02 PM, Peter Klügl wrote:
> Hi,
>
> the first release candidate of the sandbox project Apache UIMA TextMarker is
> ready for voting.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-163/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Eclipse update site:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
>
>
> The update site only contains the UIMA TextMarker plugins and is not yet
> integrated in the composite repository because the composite repository is not
> yet officially released.
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
>
>
> As it is the first release, the report contains all fixed issues.
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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 Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
On 1/25/2013 5:20 PM, Richard Eckart de Castilho wrote:
> Am 25.01.2013 um 16:37 schrieb Marshall Schor <ms...@schor.com>:
>> On 1/25/2013 9:27 AM, Peter Klügl wrote:
>>> On 25.01.2013 14:40, Peter Klügl wrote:
>>>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>>>>> from the NOTICE/LICENSE in the top level project since they are both not
>>>>>> part of the source release. Then, I have to add NOTICE/LICENSE files (with
>>>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>>>>> the uimaj-ep-textmarker-engine project since those two binaries will
>>>>>> contain the third party libraries. The other plugins also need their own
>>>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>>>>> that correct? Is there a shortcut, something that influences maven what to
>>>>>> put in those files, or which file to copy?
>>>>> +1, sounds good.
>>>> Unfortunately, this did not work. I added individual LICENSE/NOTICE files to
>>>> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains
>>>> the default files and additionally files with ".txt" extension and the same
>>>> content. The -sources jar contains also only the default files.
>>>>
>>>> Any ideas?
>>>>
>>> Can someone verify that the information in [1] is correct? I am searching for
>>> an example with similar preconditions and correct LICENSE/NOTICE files. If I
>>> take a look at the latest official release of the SDK, then I can see the
>>> LICENSE/NOTICE files of the top project, e.g., with the mention of the icons.
>>> However, the plugin org.apache.uima.caseditor_2.4.0 has only the default
>>> LICENSE/NOTICE files in its META-INF folder (no mention of the icons). The
>>> LICENSE/NOTICE files in src/main/readme (top level) contain the information
>>> about the icons.
>> Right. When you get your packaging fixed, I think we'll need to change this
>> project too. You're the first one pioneering this :-)
>
> This whole fuzz about NOTICE/README files of third-party dependencies included in OSGi bundles is necessary only because many third-party JARs do actually *not* contain NOTICE/README files inside them, right? I mean, if every third-party JAR carried these files, there wouldn't be any necessity to repeat that information in our files, would there?
I think many people find this fuzzy. There have been recent discussions on
Jira's in legal-discuss about this (referenced below), and a new page has been
added - a licensing-howto [1]. According to [1] you need to "bubble up" notices
(that apply in your particular case) from dependent things you include.
[1] http://www.apache.org/dev/licensing-howto.html (Scroll to bottom)
This includes the step: Perform a recursive traversal of the product's
dependency chain, starting with direct dependencies and continuing through all
child dependencies. For any dependency whose bits are bundled, consider whether
LICENSE and NOTICE need to be modified. (DO NOT modify LICENSE or NOTICE for
dependencies whose bits are not bundled.)
Here are the two Jiras about this, for more background and discussion:
https://issues.apache.org/jira/browse/INCUBATOR-125
and
https://issues.apache.org/jira/browse/LEGAL-155
-Marshall
>
> Cheers,
>
> -- Richard
>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
Am 25.01.2013 um 16:37 schrieb Marshall Schor <ms...@schor.com>:
> On 1/25/2013 9:27 AM, Peter Klügl wrote:
>> On 25.01.2013 14:40, Peter Klügl wrote:
>>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>>>> from the NOTICE/LICENSE in the top level project since they are both not
>>>>> part of the source release. Then, I have to add NOTICE/LICENSE files (with
>>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>>>> the uimaj-ep-textmarker-engine project since those two binaries will
>>>>> contain the third party libraries. The other plugins also need their own
>>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>>>> that correct? Is there a shortcut, something that influences maven what to
>>>>> put in those files, or which file to copy?
>>>>
>>>> +1, sounds good.
>>>
>>> Unfortunately, this did not work. I added individual LICENSE/NOTICE files to
>>> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains
>>> the default files and additionally files with ".txt" extension and the same
>>> content. The -sources jar contains also only the default files.
>>>
>>> Any ideas?
>>>
>>
>> Can someone verify that the information in [1] is correct? I am searching for
>> an example with similar preconditions and correct LICENSE/NOTICE files. If I
>> take a look at the latest official release of the SDK, then I can see the
>> LICENSE/NOTICE files of the top project, e.g., with the mention of the icons.
>> However, the plugin org.apache.uima.caseditor_2.4.0 has only the default
>> LICENSE/NOTICE files in its META-INF folder (no mention of the icons). The
>> LICENSE/NOTICE files in src/main/readme (top level) contain the information
>> about the icons.
>
> Right. When you get your packaging fixed, I think we'll need to change this
> project too. You're the first one pioneering this :-)
This whole fuzz about NOTICE/README files of third-party dependencies included in OSGi bundles is necessary only because many third-party JARs do actually *not* contain NOTICE/README files inside them, right? I mean, if every third-party JAR carried these files, there wouldn't be any necessity to repeat that information in our files, would there?
Cheers,
-- 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 Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
On 1/25/2013 9:27 AM, Peter Klügl wrote:
> On 25.01.2013 14:40, Peter Klügl wrote:
>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>>> from the NOTICE/LICENSE in the top level project since they are both not
>>>> part of the source release. Then, I have to add NOTICE/LICENSE files (with
>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>>> the uimaj-ep-textmarker-engine project since those two binaries will
>>>> contain the third party libraries. The other plugins also need their own
>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>>> that correct? Is there a shortcut, something that influences maven what to
>>>> put in those files, or which file to copy?
>>>
>>> +1, sounds good.
>>
>> Unfortunately, this did not work. I added individual LICENSE/NOTICE files to
>> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains
>> the default files and additionally files with ".txt" extension and the same
>> content. The -sources jar contains also only the default files.
>>
>> Any ideas?
>>
>
> Can someone verify that the information in [1] is correct? I am searching for
> an example with similar preconditions and correct LICENSE/NOTICE files. If I
> take a look at the latest official release of the SDK, then I can see the
> LICENSE/NOTICE files of the top project, e.g., with the mention of the icons.
> However, the plugin org.apache.uima.caseditor_2.4.0 has only the default
> LICENSE/NOTICE files in its META-INF folder (no mention of the icons). The
> LICENSE/NOTICE files in src/main/readme (top level) contain the information
> about the icons.
Right. When you get your packaging fixed, I think we'll need to change this
project too. You're the first one pioneering this :-)
-Marshall
>
> Peter
>
> [1] http://uima.apache.org/maven-design.html#LICENSE%20and%20NOTICE%20files
>
>> Peter
>>
>>
>>
>>>
>>> Jörn
>
>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 25.01.2013 14:40, Peter Klügl wrote:
> On 25.01.2013 14:02, Jörn Kottmann wrote:
>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>> If I undestand that correctly, then I have to remove ANTLR and
>>> htmlparser from the NOTICE/LICENSE in the top level project since
>>> they are both not part of the source release. Then, I have to add
>>> NOTICE/LICENSE files (with ANTLR and htmlparser) to src/main/readme/
>>> in the top level project and to the uimaj-ep-textmarker-engine
>>> project since those two binaries will contain the third party
>>> libraries. The other plugins also need their own NOTICE/LICENSE
>>> files in src/main/readme/ since they contain the icons. Is that
>>> correct? Is there a shortcut, something that influences maven what
>>> to put in those files, or which file to copy?
>>
>> +1, sounds good.
>
> Unfortunately, this did not work. I added individual LICENSE/NOTICE
> files to src/main/readme in uimaj-ep-textmarker-engine but the binary
> just contains the default files and additionally files with ".txt"
> extension and the same content. The -sources jar contains also only
> the default files.
>
> Any ideas?
>
Can someone verify that the information in [1] is correct? I am
searching for an example with similar preconditions and correct
LICENSE/NOTICE files. If I take a look at the latest official release of
the SDK, then I can see the LICENSE/NOTICE files of the top project,
e.g., with the mention of the icons. However, the plugin
org.apache.uima.caseditor_2.4.0 has only the default LICENSE/NOTICE
files in its META-INF folder (no mention of the icons). The
LICENSE/NOTICE files in src/main/readme (top level) contain the
information about the icons.
Peter
[1] http://uima.apache.org/maven-design.html#LICENSE%20and%20NOTICE%20files
> Peter
>
>
>
>>
>> Jörn
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
On 1/25/2013 1:28 PM, Marshall Schor wrote:
> Source-release - we use the configuration from the apache-wide pom for this.
>
> It has this bit in the assembly:
>
> <!-- license, readme, etc. calculated at build time -->
> <fileSet>
>
> <directory>${project.build.directory}/maven-shared-archive-resources/META-INF</directory>
> <outputDirectory>/</outputDirectory>
> </fileSet>
>
> So, if your build at the top level creates the right LICENSE NOTICE files and
> puts them into the .../target/maven-shared-archive-resources/META-INF spot, they
> should be copied to the top level in the source assembly zip.
But as I noted in another part of this thread, the source release is unlikely to
need any customized files, so the standard ones ought to work (because the
source-release is unlikely to have anything in it other than the sources, of
course).
-Marshall
>
> -M
>
>
> On 1/25/2013 12:59 PM, Peter Klügl wrote:
>> The binaries and the top level (release) sources look fine now, but I have a
>> problem with the individual sources.
>>
>> Can someone give me a hint how to get a customized LICENSE file into the
>> sources in our build?
>> Or, a pointer how the LICENSE file is included by the maven-source-plugin.
>> Anything I did was either ignored or overridden.
>>
>> Peter
>>
>> On 25.01.2013 16:35, Marshall Schor wrote:
>>> hi - I'm digging into this.
>>>
>>> Here's what I've found so far (taking the uimaj-ep-configurator project as a
>>> sample).
>>>
>>> The build process chain includes early on the maven-remote-resources plugin.
>>> This fetches "standard" things from a standard place for the license and notice
>>> files, puts them into
>>> .../target/maven-shared-archive-resources.
>>>
>>> The maven-remote-resources plugin runs "velocity" macro expansion; this allows
>>> inserting at build time extra stuff. Our Notice template (in
>>> build/trunk/uima-build-resources/src/main/resources/META-INF/NOTICE.vm) is a
>>> slight modification from the Apache-wide Notice template, in that it has an
>>> extra bit at the bottom that says, if the maven property
>>> "project.properties.postNoticeText" is set, then insert it. We use this to
>>> modify the Notice file for things which originally had IBM copyrights which were
>>> moved to the notice file.
>>>
>>> The documentation for the maven-remote-resources plugin says the goal we're
>>> using ("process") after running the velocity macro expansion on the resources,
>>> they "are injected into the current (in-memory) Maven project, making them
>>> available to the process-resources phase."
>>>
>>> What you have to know to have this make sense, is that if you have
>>> (subsequently) an invocation of the maven-resources-plugin with the "resources"
>>> goal, running in the "process-resources" phase, then that will copy the files in
>>> .../target/maven-shared-archive-resources into the .../target/classes spot - so
>>> the eventual JAR plugin will package these (it Jars up everything it finds in
>>> the .../target/classes directory).
>>>
>>> So, that's how the files get to the right spot in the Jar.
>>>
>>> I think our current build process is lacking the ability to do customization of
>>> the LICENSE file prototype. We could modify that, to work just like the Notice
>>> file works, to allow extending the standard LICENSE with arbitrary text. We
>>> might want to do something different, though, in the case of large modifications
>>> to the standard LICENSE / NOTICE files. One thing that would probably work is
>>> to use a copy-resources kind of step to replace/override the "standard"
>>> LICENSE/NOTICE files in ...target/classes/MEAT-INF with the custom ones from
>>> some standard spot (I would suggest using the same spot as you already used).
>>>
>>> =====================
>>>
>>> I think the reason this hasn't come up before, is that the JARs we built did not
>>> (normally) contain other Jars that needed special LICENSE/NOTICE files. The
>>> things that did have that need were normally zip and tar assemblies of JARs,
>>> where we used the assembly plugin to do this packaging.
>>>
>>> I haven't looked to see what the case is with your packaging - if you're using
>>> Assembly, then there are other conventions involving the instructions you were
>>> following. My guess is that you're not using assembly, so those instructions
>>> don't help.
>>>
>>> =====================
>>>
>>> Let me know if you need help in doing something like this...
>>>
>>> -Marshall
>>>
>>> On 1/25/2013 8:40 AM, Peter Klügl wrote:
>>>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>>>>> from the NOTICE/LICENSE in the top level project since they are both not
>>>>>> part of the source release. Then, I have to add NOTICE/LICENSE files (with
>>>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>>>>> the uimaj-ep-textmarker-engine project since those two binaries will contain
>>>>>> the third party libraries. The other plugins also need their own
>>>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>>>>> that correct? Is there a shortcut, something that influences maven what to
>>>>>> put in those files, or which file to copy?
>>>>> +1, sounds good.
>>>> Unfortunately, this did not work. I added individual LICENSE/NOTICE files to
>>>> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains the
>>>> default files and additionally files with ".txt" extension and the same
>>>> content. The -sources jar contains also only the default files.
>>>>
>>>> Any ideas?
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>>> Jörn
>>
>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
Source-release - we use the configuration from the apache-wide pom for this.
It has this bit in the assembly:
<!-- license, readme, etc. calculated at build time -->
<fileSet>
<directory>${project.build.directory}/maven-shared-archive-resources/META-INF</directory>
<outputDirectory>/</outputDirectory>
</fileSet>
So, if your build at the top level creates the right LICENSE NOTICE files and
puts them into the .../target/maven-shared-archive-resources/META-INF spot, they
should be copied to the top level in the source assembly zip.
-M
On 1/25/2013 12:59 PM, Peter Klügl wrote:
> The binaries and the top level (release) sources look fine now, but I have a
> problem with the individual sources.
>
> Can someone give me a hint how to get a customized LICENSE file into the
> sources in our build?
> Or, a pointer how the LICENSE file is included by the maven-source-plugin.
> Anything I did was either ignored or overridden.
>
> Peter
>
> On 25.01.2013 16:35, Marshall Schor wrote:
>> hi - I'm digging into this.
>>
>> Here's what I've found so far (taking the uimaj-ep-configurator project as a
>> sample).
>>
>> The build process chain includes early on the maven-remote-resources plugin.
>> This fetches "standard" things from a standard place for the license and notice
>> files, puts them into
>> .../target/maven-shared-archive-resources.
>>
>> The maven-remote-resources plugin runs "velocity" macro expansion; this allows
>> inserting at build time extra stuff. Our Notice template (in
>> build/trunk/uima-build-resources/src/main/resources/META-INF/NOTICE.vm) is a
>> slight modification from the Apache-wide Notice template, in that it has an
>> extra bit at the bottom that says, if the maven property
>> "project.properties.postNoticeText" is set, then insert it. We use this to
>> modify the Notice file for things which originally had IBM copyrights which were
>> moved to the notice file.
>>
>> The documentation for the maven-remote-resources plugin says the goal we're
>> using ("process") after running the velocity macro expansion on the resources,
>> they "are injected into the current (in-memory) Maven project, making them
>> available to the process-resources phase."
>>
>> What you have to know to have this make sense, is that if you have
>> (subsequently) an invocation of the maven-resources-plugin with the "resources"
>> goal, running in the "process-resources" phase, then that will copy the files in
>> .../target/maven-shared-archive-resources into the .../target/classes spot - so
>> the eventual JAR plugin will package these (it Jars up everything it finds in
>> the .../target/classes directory).
>>
>> So, that's how the files get to the right spot in the Jar.
>>
>> I think our current build process is lacking the ability to do customization of
>> the LICENSE file prototype. We could modify that, to work just like the Notice
>> file works, to allow extending the standard LICENSE with arbitrary text. We
>> might want to do something different, though, in the case of large modifications
>> to the standard LICENSE / NOTICE files. One thing that would probably work is
>> to use a copy-resources kind of step to replace/override the "standard"
>> LICENSE/NOTICE files in ...target/classes/MEAT-INF with the custom ones from
>> some standard spot (I would suggest using the same spot as you already used).
>>
>> =====================
>>
>> I think the reason this hasn't come up before, is that the JARs we built did not
>> (normally) contain other Jars that needed special LICENSE/NOTICE files. The
>> things that did have that need were normally zip and tar assemblies of JARs,
>> where we used the assembly plugin to do this packaging.
>>
>> I haven't looked to see what the case is with your packaging - if you're using
>> Assembly, then there are other conventions involving the instructions you were
>> following. My guess is that you're not using assembly, so those instructions
>> don't help.
>>
>> =====================
>>
>> Let me know if you need help in doing something like this...
>>
>> -Marshall
>>
>> On 1/25/2013 8:40 AM, Peter Klügl wrote:
>>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>>>> from the NOTICE/LICENSE in the top level project since they are both not
>>>>> part of the source release. Then, I have to add NOTICE/LICENSE files (with
>>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>>>> the uimaj-ep-textmarker-engine project since those two binaries will contain
>>>>> the third party libraries. The other plugins also need their own
>>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>>>> that correct? Is there a shortcut, something that influences maven what to
>>>>> put in those files, or which file to copy?
>>>> +1, sounds good.
>>> Unfortunately, this did not work. I added individual LICENSE/NOTICE files to
>>> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains the
>>> default files and additionally files with ".txt" extension and the same
>>> content. The -sources jar contains also only the default files.
>>>
>>> Any ideas?
>>>
>>> Peter
>>>
>>>
>>>
>>>> Jörn
>>>
>
>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
The files should be fine now except for the engine plugin. Here, the
sources.jar has an unneccessary mention of the libs and the binaries
have additional files LICENSE.txt and NOTICE.txt. I think that good
enough for the next RC.
The changes are not very nice, but I have not found a better way to do
it right now.
Peter
On 27.01.2013 14:35, Peter Klügl wrote:
> Am 26.01.2013 01:31, schrieb Marshall Schor:
>> On 1/25/2013 12:59 PM, Peter Klügl wrote:
>>> The binaries and the top level (release) sources look fine now, but
>>> I have a
>>> problem with the individual sources.
>>>
>>> Can someone give me a hint how to get a customized LICENSE file into
>>> the
>>> sources in our build?
>>> Or, a pointer how the LICENSE file is included by the
>>> maven-source-plugin.
>>> Anything I did was either ignored or overridden.
>> Whoops!
>>
>> I'm thinking more now... This is the "source-release", right? That
>> distribution is unlikely to have any content other than Apache
>> Licensed content,
>> since it only includes the sources, right? So it would be incorrect
>> to put in
>> the LICENSE/NOTICE that goes with the binary builds (which incorporate
>> dependencies from other places with other LICENSE/NOTICEs perhaps).
>>
>> So the "standard" LICENSE/NOTICE should be fine here?
>>
>> Or did I misunderstand something?
>
> I think we have three kinds of files:
> 1. binary jars of each java project
> 2. source-release of the top level project
> 3. sources jars for each java project
>
> I found a not-so-nice workaround for the first one. The second one
> works already since it has NOTICE/LICENSE files in its root. The
> archive then only contains these files in its root, but no other
> NOTICE/LICENSE files in its subfolders, which is OK if all licenses
> are covered I think. As I understand it, the archive has to contain
> the icons since its content should be able to be compile to the
> binaries. The last one is currently the problem. It only contains the
> default NOTICE/LICENSE files, which seems to be enough. However, the
> source jars for Eclipse plugins contain also the icons, which use a
> different license.
>
> Either the icons do not need to be shipped in the sources jars or we
> have to extend the NOTICE/LICENSE files in these jars. However, I have
> not found a way to implement the second option.
>
> Is the "source-release" you mentioned also responsible for the the
> default NOTICE/LICENSE files in the plugin-sources.jar files?
>
> Peter
>
>
>
>
>> -Marshall
>>
>>> Peter
>>>
>>> On 25.01.2013 16:35, Marshall Schor wrote:
>>>> hi - I'm digging into this.
>>>>
>>>> Here's what I've found so far (taking the uimaj-ep-configurator
>>>> project as a
>>>> sample).
>>>>
>>>> The build process chain includes early on the
>>>> maven-remote-resources plugin.
>>>> This fetches "standard" things from a standard place for the
>>>> license and notice
>>>> files, puts them into
>>>> .../target/maven-shared-archive-resources.
>>>>
>>>> The maven-remote-resources plugin runs "velocity" macro expansion;
>>>> this allows
>>>> inserting at build time extra stuff. Our Notice template (in
>>>> build/trunk/uima-build-resources/src/main/resources/META-INF/NOTICE.vm)
>>>> is a
>>>> slight modification from the Apache-wide Notice template, in that
>>>> it has an
>>>> extra bit at the bottom that says, if the maven property
>>>> "project.properties.postNoticeText" is set, then insert it. We use
>>>> this to
>>>> modify the Notice file for things which originally had IBM
>>>> copyrights which were
>>>> moved to the notice file.
>>>>
>>>> The documentation for the maven-remote-resources plugin says the
>>>> goal we're
>>>> using ("process") after running the velocity macro expansion on the
>>>> resources,
>>>> they "are injected into the current (in-memory) Maven project,
>>>> making them
>>>> available to the process-resources phase."
>>>>
>>>> What you have to know to have this make sense, is that if you have
>>>> (subsequently) an invocation of the maven-resources-plugin with the
>>>> "resources"
>>>> goal, running in the "process-resources" phase, then that will copy
>>>> the files in
>>>> .../target/maven-shared-archive-resources into the
>>>> .../target/classes spot - so
>>>> the eventual JAR plugin will package these (it Jars up everything
>>>> it finds in
>>>> the .../target/classes directory).
>>>>
>>>> So, that's how the files get to the right spot in the Jar.
>>>>
>>>> I think our current build process is lacking the ability to do
>>>> customization of
>>>> the LICENSE file prototype. We could modify that, to work just
>>>> like the Notice
>>>> file works, to allow extending the standard LICENSE with arbitrary
>>>> text. We
>>>> might want to do something different, though, in the case of large
>>>> modifications
>>>> to the standard LICENSE / NOTICE files. One thing that would
>>>> probably work is
>>>> to use a copy-resources kind of step to replace/override the
>>>> "standard"
>>>> LICENSE/NOTICE files in ...target/classes/MEAT-INF with the custom
>>>> ones from
>>>> some standard spot (I would suggest using the same spot as you
>>>> already used).
>>>>
>>>> =====================
>>>>
>>>> I think the reason this hasn't come up before, is that the JARs we
>>>> built did not
>>>> (normally) contain other Jars that needed special LICENSE/NOTICE
>>>> files. The
>>>> things that did have that need were normally zip and tar assemblies
>>>> of JARs,
>>>> where we used the assembly plugin to do this packaging.
>>>>
>>>> I haven't looked to see what the case is with your packaging - if
>>>> you're using
>>>> Assembly, then there are other conventions involving the
>>>> instructions you were
>>>> following. My guess is that you're not using assembly, so those
>>>> instructions
>>>> don't help.
>>>>
>>>> =====================
>>>>
>>>> Let me know if you need help in doing something like this...
>>>>
>>>> -Marshall
>>>>
>>>> On 1/25/2013 8:40 AM, Peter Klügl wrote:
>>>>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>>>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>>>>> If I undestand that correctly, then I have to remove ANTLR and
>>>>>>> htmlparser
>>>>>>> from the NOTICE/LICENSE in the top level project since they are
>>>>>>> both not
>>>>>>> part of the source release. Then, I have to add NOTICE/LICENSE
>>>>>>> files (with
>>>>>>> ANTLR and htmlparser) to src/main/readme/ in the top level
>>>>>>> project and to
>>>>>>> the uimaj-ep-textmarker-engine project since those two binaries
>>>>>>> will contain
>>>>>>> the third party libraries. The other plugins also need their own
>>>>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the
>>>>>>> icons. Is
>>>>>>> that correct? Is there a shortcut, something that influences
>>>>>>> maven what to
>>>>>>> put in those files, or which file to copy?
>>>>>> +1, sounds good.
>>>>> Unfortunately, this did not work. I added individual
>>>>> LICENSE/NOTICE files to
>>>>> src/main/readme in uimaj-ep-textmarker-engine but the binary just
>>>>> contains the
>>>>> default files and additionally files with ".txt" extension and the
>>>>> same
>>>>> content. The -sources jar contains also only the default files.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>> Jörn
>>>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 26.01.2013 01:31, schrieb Marshall Schor:
> On 1/25/2013 12:59 PM, Peter Klügl wrote:
>> The binaries and the top level (release) sources look fine now, but I have a
>> problem with the individual sources.
>>
>> Can someone give me a hint how to get a customized LICENSE file into the
>> sources in our build?
>> Or, a pointer how the LICENSE file is included by the maven-source-plugin.
>> Anything I did was either ignored or overridden.
> Whoops!
>
> I'm thinking more now... This is the "source-release", right? That
> distribution is unlikely to have any content other than Apache Licensed content,
> since it only includes the sources, right? So it would be incorrect to put in
> the LICENSE/NOTICE that goes with the binary builds (which incorporate
> dependencies from other places with other LICENSE/NOTICEs perhaps).
>
> So the "standard" LICENSE/NOTICE should be fine here?
>
> Or did I misunderstand something?
I think we have three kinds of files:
1. binary jars of each java project
2. source-release of the top level project
3. sources jars for each java project
I found a not-so-nice workaround for the first one. The second one works
already since it has NOTICE/LICENSE files in its root. The archive then
only contains these files in its root, but no other NOTICE/LICENSE files
in its subfolders, which is OK if all licenses are covered I think. As I
understand it, the archive has to contain the icons since its content
should be able to be compile to the binaries. The last one is currently
the problem. It only contains the default NOTICE/LICENSE files, which
seems to be enough. However, the source jars for Eclipse plugins contain
also the icons, which use a different license.
Either the icons do not need to be shipped in the sources jars or we
have to extend the NOTICE/LICENSE files in these jars. However, I have
not found a way to implement the second option.
Is the "source-release" you mentioned also responsible for the the
default NOTICE/LICENSE files in the plugin-sources.jar files?
Peter
> -Marshall
>
>> Peter
>>
>> On 25.01.2013 16:35, Marshall Schor wrote:
>>> hi - I'm digging into this.
>>>
>>> Here's what I've found so far (taking the uimaj-ep-configurator project as a
>>> sample).
>>>
>>> The build process chain includes early on the maven-remote-resources plugin.
>>> This fetches "standard" things from a standard place for the license and notice
>>> files, puts them into
>>> .../target/maven-shared-archive-resources.
>>>
>>> The maven-remote-resources plugin runs "velocity" macro expansion; this allows
>>> inserting at build time extra stuff. Our Notice template (in
>>> build/trunk/uima-build-resources/src/main/resources/META-INF/NOTICE.vm) is a
>>> slight modification from the Apache-wide Notice template, in that it has an
>>> extra bit at the bottom that says, if the maven property
>>> "project.properties.postNoticeText" is set, then insert it. We use this to
>>> modify the Notice file for things which originally had IBM copyrights which were
>>> moved to the notice file.
>>>
>>> The documentation for the maven-remote-resources plugin says the goal we're
>>> using ("process") after running the velocity macro expansion on the resources,
>>> they "are injected into the current (in-memory) Maven project, making them
>>> available to the process-resources phase."
>>>
>>> What you have to know to have this make sense, is that if you have
>>> (subsequently) an invocation of the maven-resources-plugin with the "resources"
>>> goal, running in the "process-resources" phase, then that will copy the files in
>>> .../target/maven-shared-archive-resources into the .../target/classes spot - so
>>> the eventual JAR plugin will package these (it Jars up everything it finds in
>>> the .../target/classes directory).
>>>
>>> So, that's how the files get to the right spot in the Jar.
>>>
>>> I think our current build process is lacking the ability to do customization of
>>> the LICENSE file prototype. We could modify that, to work just like the Notice
>>> file works, to allow extending the standard LICENSE with arbitrary text. We
>>> might want to do something different, though, in the case of large modifications
>>> to the standard LICENSE / NOTICE files. One thing that would probably work is
>>> to use a copy-resources kind of step to replace/override the "standard"
>>> LICENSE/NOTICE files in ...target/classes/MEAT-INF with the custom ones from
>>> some standard spot (I would suggest using the same spot as you already used).
>>>
>>> =====================
>>>
>>> I think the reason this hasn't come up before, is that the JARs we built did not
>>> (normally) contain other Jars that needed special LICENSE/NOTICE files. The
>>> things that did have that need were normally zip and tar assemblies of JARs,
>>> where we used the assembly plugin to do this packaging.
>>>
>>> I haven't looked to see what the case is with your packaging - if you're using
>>> Assembly, then there are other conventions involving the instructions you were
>>> following. My guess is that you're not using assembly, so those instructions
>>> don't help.
>>>
>>> =====================
>>>
>>> Let me know if you need help in doing something like this...
>>>
>>> -Marshall
>>>
>>> On 1/25/2013 8:40 AM, Peter Klügl wrote:
>>>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>>>>> from the NOTICE/LICENSE in the top level project since they are both not
>>>>>> part of the source release. Then, I have to add NOTICE/LICENSE files (with
>>>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>>>>> the uimaj-ep-textmarker-engine project since those two binaries will contain
>>>>>> the third party libraries. The other plugins also need their own
>>>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>>>>> that correct? Is there a shortcut, something that influences maven what to
>>>>>> put in those files, or which file to copy?
>>>>> +1, sounds good.
>>>> Unfortunately, this did not work. I added individual LICENSE/NOTICE files to
>>>> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains the
>>>> default files and additionally files with ".txt" extension and the same
>>>> content. The -sources jar contains also only the default files.
>>>>
>>>> Any ideas?
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>>> Jörn
>>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
On 1/25/2013 12:59 PM, Peter Klügl wrote:
> The binaries and the top level (release) sources look fine now, but I have a
> problem with the individual sources.
>
> Can someone give me a hint how to get a customized LICENSE file into the
> sources in our build?
> Or, a pointer how the LICENSE file is included by the maven-source-plugin.
> Anything I did was either ignored or overridden.
Whoops!
I'm thinking more now... This is the "source-release", right? That
distribution is unlikely to have any content other than Apache Licensed content,
since it only includes the sources, right? So it would be incorrect to put in
the LICENSE/NOTICE that goes with the binary builds (which incorporate
dependencies from other places with other LICENSE/NOTICEs perhaps).
So the "standard" LICENSE/NOTICE should be fine here?
Or did I misunderstand something?
-Marshall
>
> Peter
>
> On 25.01.2013 16:35, Marshall Schor wrote:
>> hi - I'm digging into this.
>>
>> Here's what I've found so far (taking the uimaj-ep-configurator project as a
>> sample).
>>
>> The build process chain includes early on the maven-remote-resources plugin.
>> This fetches "standard" things from a standard place for the license and notice
>> files, puts them into
>> .../target/maven-shared-archive-resources.
>>
>> The maven-remote-resources plugin runs "velocity" macro expansion; this allows
>> inserting at build time extra stuff. Our Notice template (in
>> build/trunk/uima-build-resources/src/main/resources/META-INF/NOTICE.vm) is a
>> slight modification from the Apache-wide Notice template, in that it has an
>> extra bit at the bottom that says, if the maven property
>> "project.properties.postNoticeText" is set, then insert it. We use this to
>> modify the Notice file for things which originally had IBM copyrights which were
>> moved to the notice file.
>>
>> The documentation for the maven-remote-resources plugin says the goal we're
>> using ("process") after running the velocity macro expansion on the resources,
>> they "are injected into the current (in-memory) Maven project, making them
>> available to the process-resources phase."
>>
>> What you have to know to have this make sense, is that if you have
>> (subsequently) an invocation of the maven-resources-plugin with the "resources"
>> goal, running in the "process-resources" phase, then that will copy the files in
>> .../target/maven-shared-archive-resources into the .../target/classes spot - so
>> the eventual JAR plugin will package these (it Jars up everything it finds in
>> the .../target/classes directory).
>>
>> So, that's how the files get to the right spot in the Jar.
>>
>> I think our current build process is lacking the ability to do customization of
>> the LICENSE file prototype. We could modify that, to work just like the Notice
>> file works, to allow extending the standard LICENSE with arbitrary text. We
>> might want to do something different, though, in the case of large modifications
>> to the standard LICENSE / NOTICE files. One thing that would probably work is
>> to use a copy-resources kind of step to replace/override the "standard"
>> LICENSE/NOTICE files in ...target/classes/MEAT-INF with the custom ones from
>> some standard spot (I would suggest using the same spot as you already used).
>>
>> =====================
>>
>> I think the reason this hasn't come up before, is that the JARs we built did not
>> (normally) contain other Jars that needed special LICENSE/NOTICE files. The
>> things that did have that need were normally zip and tar assemblies of JARs,
>> where we used the assembly plugin to do this packaging.
>>
>> I haven't looked to see what the case is with your packaging - if you're using
>> Assembly, then there are other conventions involving the instructions you were
>> following. My guess is that you're not using assembly, so those instructions
>> don't help.
>>
>> =====================
>>
>> Let me know if you need help in doing something like this...
>>
>> -Marshall
>>
>> On 1/25/2013 8:40 AM, Peter Klügl wrote:
>>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>>>> from the NOTICE/LICENSE in the top level project since they are both not
>>>>> part of the source release. Then, I have to add NOTICE/LICENSE files (with
>>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>>>> the uimaj-ep-textmarker-engine project since those two binaries will contain
>>>>> the third party libraries. The other plugins also need their own
>>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>>>> that correct? Is there a shortcut, something that influences maven what to
>>>>> put in those files, or which file to copy?
>>>> +1, sounds good.
>>> Unfortunately, this did not work. I added individual LICENSE/NOTICE files to
>>> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains the
>>> default files and additionally files with ".txt" extension and the same
>>> content. The -sources jar contains also only the default files.
>>>
>>> Any ideas?
>>>
>>> Peter
>>>
>>>
>>>
>>>> Jörn
>>>
>
>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
I think we should add the additional licenses to the LICENSE file like
we do it for the NOTICE file. Maybe we can externalize the license
strings with properties:read-project-properties.
Best,
Peter
On 25.01.2013 18:59, Peter Klügl wrote:
> The binaries and the top level (release) sources look fine now, but I
> have a problem with the individual sources.
>
> Can someone give me a hint how to get a customized LICENSE file into
> the sources in our build?
> Or, a pointer how the LICENSE file is included by the
> maven-source-plugin. Anything I did was either ignored or overridden.
>
> Peter
>
> On 25.01.2013 16:35, Marshall Schor wrote:
>> hi - I'm digging into this.
>>
>> Here's what I've found so far (taking the uimaj-ep-configurator
>> project as a
>> sample).
>>
>> The build process chain includes early on the maven-remote-resources
>> plugin.
>> This fetches "standard" things from a standard place for the license
>> and notice
>> files, puts them into
>> .../target/maven-shared-archive-resources.
>>
>> The maven-remote-resources plugin runs "velocity" macro expansion;
>> this allows
>> inserting at build time extra stuff. Our Notice template (in
>> build/trunk/uima-build-resources/src/main/resources/META-INF/NOTICE.vm)
>> is a
>> slight modification from the Apache-wide Notice template, in that it
>> has an
>> extra bit at the bottom that says, if the maven property
>> "project.properties.postNoticeText" is set, then insert it. We use
>> this to
>> modify the Notice file for things which originally had IBM copyrights
>> which were
>> moved to the notice file.
>>
>> The documentation for the maven-remote-resources plugin says the goal
>> we're
>> using ("process") after running the velocity macro expansion on the
>> resources,
>> they "are injected into the current (in-memory) Maven project, making
>> them
>> available to the process-resources phase."
>>
>> What you have to know to have this make sense, is that if you have
>> (subsequently) an invocation of the maven-resources-plugin with the
>> "resources"
>> goal, running in the "process-resources" phase, then that will copy
>> the files in
>> .../target/maven-shared-archive-resources into the .../target/classes
>> spot - so
>> the eventual JAR plugin will package these (it Jars up everything it
>> finds in
>> the .../target/classes directory).
>>
>> So, that's how the files get to the right spot in the Jar.
>>
>> I think our current build process is lacking the ability to do
>> customization of
>> the LICENSE file prototype. We could modify that, to work just like
>> the Notice
>> file works, to allow extending the standard LICENSE with arbitrary
>> text. We
>> might want to do something different, though, in the case of large
>> modifications
>> to the standard LICENSE / NOTICE files. One thing that would
>> probably work is
>> to use a copy-resources kind of step to replace/override the "standard"
>> LICENSE/NOTICE files in ...target/classes/MEAT-INF with the custom
>> ones from
>> some standard spot (I would suggest using the same spot as you
>> already used).
>>
>> =====================
>>
>> I think the reason this hasn't come up before, is that the JARs we
>> built did not
>> (normally) contain other Jars that needed special LICENSE/NOTICE
>> files. The
>> things that did have that need were normally zip and tar assemblies
>> of JARs,
>> where we used the assembly plugin to do this packaging.
>>
>> I haven't looked to see what the case is with your packaging - if
>> you're using
>> Assembly, then there are other conventions involving the instructions
>> you were
>> following. My guess is that you're not using assembly, so those
>> instructions
>> don't help.
>>
>> =====================
>>
>> Let me know if you need help in doing something like this...
>>
>> -Marshall
>>
>> On 1/25/2013 8:40 AM, Peter Klügl wrote:
>>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>>> If I undestand that correctly, then I have to remove ANTLR and
>>>>> htmlparser
>>>>> from the NOTICE/LICENSE in the top level project since they are
>>>>> both not
>>>>> part of the source release. Then, I have to add NOTICE/LICENSE
>>>>> files (with
>>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project
>>>>> and to
>>>>> the uimaj-ep-textmarker-engine project since those two binaries
>>>>> will contain
>>>>> the third party libraries. The other plugins also need their own
>>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the
>>>>> icons. Is
>>>>> that correct? Is there a shortcut, something that influences maven
>>>>> what to
>>>>> put in those files, or which file to copy?
>>>> +1, sounds good.
>>> Unfortunately, this did not work. I added individual LICENSE/NOTICE
>>> files to
>>> src/main/readme in uimaj-ep-textmarker-engine but the binary just
>>> contains the
>>> default files and additionally files with ".txt" extension and the same
>>> content. The -sources jar contains also only the default files.
>>>
>>> Any ideas?
>>>
>>> Peter
>>>
>>>
>>>
>>>> Jörn
>>>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
The binaries and the top level (release) sources look fine now, but I
have a problem with the individual sources.
Can someone give me a hint how to get a customized LICENSE file into the
sources in our build?
Or, a pointer how the LICENSE file is included by the
maven-source-plugin. Anything I did was either ignored or overridden.
Peter
On 25.01.2013 16:35, Marshall Schor wrote:
> hi - I'm digging into this.
>
> Here's what I've found so far (taking the uimaj-ep-configurator project as a
> sample).
>
> The build process chain includes early on the maven-remote-resources plugin.
> This fetches "standard" things from a standard place for the license and notice
> files, puts them into
> .../target/maven-shared-archive-resources.
>
> The maven-remote-resources plugin runs "velocity" macro expansion; this allows
> inserting at build time extra stuff. Our Notice template (in
> build/trunk/uima-build-resources/src/main/resources/META-INF/NOTICE.vm) is a
> slight modification from the Apache-wide Notice template, in that it has an
> extra bit at the bottom that says, if the maven property
> "project.properties.postNoticeText" is set, then insert it. We use this to
> modify the Notice file for things which originally had IBM copyrights which were
> moved to the notice file.
>
> The documentation for the maven-remote-resources plugin says the goal we're
> using ("process") after running the velocity macro expansion on the resources,
> they "are injected into the current (in-memory) Maven project, making them
> available to the process-resources phase."
>
> What you have to know to have this make sense, is that if you have
> (subsequently) an invocation of the maven-resources-plugin with the "resources"
> goal, running in the "process-resources" phase, then that will copy the files in
> .../target/maven-shared-archive-resources into the .../target/classes spot - so
> the eventual JAR plugin will package these (it Jars up everything it finds in
> the .../target/classes directory).
>
> So, that's how the files get to the right spot in the Jar.
>
> I think our current build process is lacking the ability to do customization of
> the LICENSE file prototype. We could modify that, to work just like the Notice
> file works, to allow extending the standard LICENSE with arbitrary text. We
> might want to do something different, though, in the case of large modifications
> to the standard LICENSE / NOTICE files. One thing that would probably work is
> to use a copy-resources kind of step to replace/override the "standard"
> LICENSE/NOTICE files in ...target/classes/MEAT-INF with the custom ones from
> some standard spot (I would suggest using the same spot as you already used).
>
> =====================
>
> I think the reason this hasn't come up before, is that the JARs we built did not
> (normally) contain other Jars that needed special LICENSE/NOTICE files. The
> things that did have that need were normally zip and tar assemblies of JARs,
> where we used the assembly plugin to do this packaging.
>
> I haven't looked to see what the case is with your packaging - if you're using
> Assembly, then there are other conventions involving the instructions you were
> following. My guess is that you're not using assembly, so those instructions
> don't help.
>
> =====================
>
> Let me know if you need help in doing something like this...
>
> -Marshall
>
> On 1/25/2013 8:40 AM, Peter Klügl wrote:
>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>>> from the NOTICE/LICENSE in the top level project since they are both not
>>>> part of the source release. Then, I have to add NOTICE/LICENSE files (with
>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>>> the uimaj-ep-textmarker-engine project since those two binaries will contain
>>>> the third party libraries. The other plugins also need their own
>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>>> that correct? Is there a shortcut, something that influences maven what to
>>>> put in those files, or which file to copy?
>>> +1, sounds good.
>> Unfortunately, this did not work. I added individual LICENSE/NOTICE files to
>> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains the
>> default files and additionally files with ".txt" extension and the same
>> content. The -sources jar contains also only the default files.
>>
>> Any ideas?
>>
>> Peter
>>
>>
>>
>>> Jörn
>>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
hi - I'm digging into this.
Here's what I've found so far (taking the uimaj-ep-configurator project as a
sample).
The build process chain includes early on the maven-remote-resources plugin.
This fetches "standard" things from a standard place for the license and notice
files, puts them into
.../target/maven-shared-archive-resources.
The maven-remote-resources plugin runs "velocity" macro expansion; this allows
inserting at build time extra stuff. Our Notice template (in
build/trunk/uima-build-resources/src/main/resources/META-INF/NOTICE.vm) is a
slight modification from the Apache-wide Notice template, in that it has an
extra bit at the bottom that says, if the maven property
"project.properties.postNoticeText" is set, then insert it. We use this to
modify the Notice file for things which originally had IBM copyrights which were
moved to the notice file.
The documentation for the maven-remote-resources plugin says the goal we're
using ("process") after running the velocity macro expansion on the resources,
they "are injected into the current (in-memory) Maven project, making them
available to the process-resources phase."
What you have to know to have this make sense, is that if you have
(subsequently) an invocation of the maven-resources-plugin with the "resources"
goal, running in the "process-resources" phase, then that will copy the files in
.../target/maven-shared-archive-resources into the .../target/classes spot - so
the eventual JAR plugin will package these (it Jars up everything it finds in
the .../target/classes directory).
So, that's how the files get to the right spot in the Jar.
I think our current build process is lacking the ability to do customization of
the LICENSE file prototype. We could modify that, to work just like the Notice
file works, to allow extending the standard LICENSE with arbitrary text. We
might want to do something different, though, in the case of large modifications
to the standard LICENSE / NOTICE files. One thing that would probably work is
to use a copy-resources kind of step to replace/override the "standard"
LICENSE/NOTICE files in ...target/classes/MEAT-INF with the custom ones from
some standard spot (I would suggest using the same spot as you already used).
=====================
I think the reason this hasn't come up before, is that the JARs we built did not
(normally) contain other Jars that needed special LICENSE/NOTICE files. The
things that did have that need were normally zip and tar assemblies of JARs,
where we used the assembly plugin to do this packaging.
I haven't looked to see what the case is with your packaging - if you're using
Assembly, then there are other conventions involving the instructions you were
following. My guess is that you're not using assembly, so those instructions
don't help.
=====================
Let me know if you need help in doing something like this...
-Marshall
On 1/25/2013 8:40 AM, Peter Klügl wrote:
> On 25.01.2013 14:02, Jörn Kottmann wrote:
>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>> from the NOTICE/LICENSE in the top level project since they are both not
>>> part of the source release. Then, I have to add NOTICE/LICENSE files (with
>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>> the uimaj-ep-textmarker-engine project since those two binaries will contain
>>> the third party libraries. The other plugins also need their own
>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>> that correct? Is there a shortcut, something that influences maven what to
>>> put in those files, or which file to copy?
>>
>> +1, sounds good.
>
> Unfortunately, this did not work. I added individual LICENSE/NOTICE files to
> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains the
> default files and additionally files with ".txt" extension and the same
> content. The -sources jar contains also only the default files.
>
> Any ideas?
>
> Peter
>
>
>
>>
>> Jörn
>
>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 25.01.2013 14:02, Jörn Kottmann wrote:
> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>> If I undestand that correctly, then I have to remove ANTLR and
>> htmlparser from the NOTICE/LICENSE in the top level project since
>> they are both not part of the source release. Then, I have to add
>> NOTICE/LICENSE files (with ANTLR and htmlparser) to src/main/readme/
>> in the top level project and to the uimaj-ep-textmarker-engine
>> project since those two binaries will contain the third party
>> libraries. The other plugins also need their own NOTICE/LICENSE files
>> in src/main/readme/ since they contain the icons. Is that correct? Is
>> there a shortcut, something that influences maven what to put in
>> those files, or which file to copy?
>
> +1, sounds good.
Unfortunately, this did not work. I added individual LICENSE/NOTICE
files to src/main/readme in uimaj-ep-textmarker-engine but the binary
just contains the default files and additionally files with ".txt"
extension and the same content. The -sources jar contains also only the
default files.
Any ideas?
Peter
>
> Jörn
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Jörn Kottmann <ko...@gmail.com>.
On 01/25/2013 01:13 PM, Peter Klügl wrote:
> If I undestand that correctly, then I have to remove ANTLR and
> htmlparser from the NOTICE/LICENSE in the top level project since they
> are both not part of the source release. Then, I have to add
> NOTICE/LICENSE files (with ANTLR and htmlparser) to src/main/readme/
> in the top level project and to the uimaj-ep-textmarker-engine project
> since those two binaries will contain the third party libraries. The
> other plugins also need their own NOTICE/LICENSE files in
> src/main/readme/ since they contain the icons. Is that correct? Is
> there a shortcut, something that influences maven what to put in those
> files, or which file to copy?
+1, sounds good.
Jörn
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 24.01.2013 16:57, Marshall Schor wrote:
> On 1/24/2013 7:46 AM, Peter Klügl wrote:
>> On 24.01.2013 12:20, Jörn Kottmann wrote:
>>> On 01/24/2013 10:39 AM, Peter Klügl wrote:
>>>>> I found the icons in the uimaj-ep-textmarker-ide binary plugin jar file, but
>>>>> the LICENSE and NOTICE files do not contain the attribution and license for
>>>>> them:
>>>>>
>>>> Hmm, yes. I thought it is enough to provide those modified files for the
>>>> root project, which is released. I assume that maven has put the standard
>>>> LICENSE/NOTICE files in META-INF. The question is: what do I need to do?
>>>> Does each jar needs its individual files?
>>> I am afraid to tell you that you need to have accurate NOTICE/LICENSE files
>>> for all the artifacts you want to distribute.
>>> As far as I know you can tell maven to not follow the standard behavior, I
>>> believe Marshall already did it for
>>> some of our artifacts already, e.g. the Cas Editor.
>>>
>> Can you or Marhsall elaborate on that? I looked at the Cas Editor, but have
>> not found anything in the pom nor in the jar distributed in the downloadable
>> archive.
> In the Jar there is in the directory /META-INF added "LICENSE" and "NOTICE" files.
>
> There is a writeup of how the packaging for license/notice files works (I think
> it is mostly up to date :-) ), here:
>
> http://uima.apache.org/maven-design.html#LICENSE and NOTICE files
> <http://uima.apache.org/maven-design.html#LICENSE%20and%20NOTICE%20files>
>
> It would best to follow the conventions, of course :-)
>
> HTH. -Marshall
Thanks for the links. I've read it some time ago, but forgot about it.
If I undestand that correctly, then I have to remove ANTLR and
htmlparser from the NOTICE/LICENSE in the top level project since they
are both not part of the source release. Then, I have to add
NOTICE/LICENSE files (with ANTLR and htmlparser) to src/main/readme/ in
the top level project and to the uimaj-ep-textmarker-engine project
since those two binaries will contain the third party libraries. The
other plugins also need their own NOTICE/LICENSE files in
src/main/readme/ since they contain the icons. Is that correct? Is there
a shortcut, something that influences maven what to put in those files,
or which file to copy?
What about the source release? The complete source release contains the
file I provided. However,
"org.apache.uima.textmarker.caseditor_2.0.0-sources.jar" for example,
only contains the default NOTICE/LICENSE files. Can I somehow change
these files to those I provide? Or are these files put there as a binary
release?
I must admit that I am a bit confused. I thought maven would just
distribute the NOTICE/LICENSE files that I provide in the top level
project, which is released.
Peter
>> Can I simply put a manually adapted NOTICE/LICENSE file in the META-INF folder
>> of the respective projects? Or what is the normal procedure here?
>>
>>> See this release policy:
>>> http://www.apache.org/dev/release.html#distribute-other-artifacts
>>>
>>> The attribution and notices you included in the svn tag files look good,
>>> you just need to make sure that they are included in all of your artifacts
>>> you want
>>> to distribute. The basic principle here is that you just include what is
>>> mandatory.
>>>
>>> The textmarker ide plugin jar file includes the icons, and uses ANTLR
>>> libraries through
>>> the textmarker engine. For the LICENSE and NOTICE file it only counts what is
>>> inside the distributable,
>>> in this case you only need to put the icons in the LICENSE/NOTICE but not
>>> ANTLR because their
>>> work is not included.
>>>
>>> The NOTICE file in the svn tag still has 2012 in it, should be updated to 2013.
>>>
>> Thanks for your help :-)
>>
>> Peter
>>
>>> Hope that helps,
>>> Jörn
>>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
On 1/24/2013 7:46 AM, Peter Klügl wrote:
> On 24.01.2013 12:20, Jörn Kottmann wrote:
>> On 01/24/2013 10:39 AM, Peter Klügl wrote:
>>>> I found the icons in the uimaj-ep-textmarker-ide binary plugin jar file, but
>>>> the LICENSE and NOTICE files do not contain the attribution and license for
>>>> them:
>>>>
>>>
>>> Hmm, yes. I thought it is enough to provide those modified files for the
>>> root project, which is released. I assume that maven has put the standard
>>> LICENSE/NOTICE files in META-INF. The question is: what do I need to do?
>>> Does each jar needs its individual files?
>>
>> I am afraid to tell you that you need to have accurate NOTICE/LICENSE files
>> for all the artifacts you want to distribute.
>> As far as I know you can tell maven to not follow the standard behavior, I
>> believe Marshall already did it for
>> some of our artifacts already, e.g. the Cas Editor.
>>
>
> Can you or Marhsall elaborate on that? I looked at the Cas Editor, but have
> not found anything in the pom nor in the jar distributed in the downloadable
> archive.
In the Jar there is in the directory /META-INF added "LICENSE" and "NOTICE" files.
There is a writeup of how the packaging for license/notice files works (I think
it is mostly up to date :-) ), here:
http://uima.apache.org/maven-design.html#LICENSE and NOTICE files
<http://uima.apache.org/maven-design.html#LICENSE%20and%20NOTICE%20files>
It would best to follow the conventions, of course :-)
HTH. -Marshall
>
> Can I simply put a manually adapted NOTICE/LICENSE file in the META-INF folder
> of the respective projects? Or what is the normal procedure here?
>
>> See this release policy:
>> http://www.apache.org/dev/release.html#distribute-other-artifacts
>>
>> The attribution and notices you included in the svn tag files look good,
>> you just need to make sure that they are included in all of your artifacts
>> you want
>> to distribute. The basic principle here is that you just include what is
>> mandatory.
>>
>> The textmarker ide plugin jar file includes the icons, and uses ANTLR
>> libraries through
>> the textmarker engine. For the LICENSE and NOTICE file it only counts what is
>> inside the distributable,
>> in this case you only need to put the icons in the LICENSE/NOTICE but not
>> ANTLR because their
>> work is not included.
>>
>> The NOTICE file in the svn tag still has 2012 in it, should be updated to 2013.
>>
>
> Thanks for your help :-)
>
> Peter
>
>> Hope that helps,
>> Jörn
>
>
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Jörn Kottmann <ko...@gmail.com>.
On 01/24/2013 01:46 PM, Peter Klügl wrote:
> Can you or Marhsall elaborate on that? I looked at the Cas Editor, but
> have not found anything in the pom nor in the jar distributed in the
> downloadable archive.
Thats ok, because the distributable (zip/tar.gz package) contains
everything in its top-level NOTICE/LICENSE, but the Cas Editor
is also distributed via the eclipse update site, and there the jar file
must have non-default NOTICE/LICENSE files.
I will check if thats the case, then we can at least fix it for the next
release.
Jörn
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 24.01.2013 12:20, Jörn Kottmann wrote:
> On 01/24/2013 10:39 AM, Peter Klügl wrote:
>>> I found the icons in the uimaj-ep-textmarker-ide binary plugin jar
>>> file, but
>>> the LICENSE and NOTICE files do not contain the attribution and
>>> license for them:
>>>
>>
>> Hmm, yes. I thought it is enough to provide those modified files for
>> the root project, which is released. I assume that maven has put the
>> standard LICENSE/NOTICE files in META-INF. The question is: what do I
>> need to do? Does each jar needs its individual files?
>
> I am afraid to tell you that you need to have accurate NOTICE/LICENSE
> files for all the artifacts you want to distribute.
> As far as I know you can tell maven to not follow the standard
> behavior, I believe Marshall already did it for
> some of our artifacts already, e.g. the Cas Editor.
>
Can you or Marhsall elaborate on that? I looked at the Cas Editor, but
have not found anything in the pom nor in the jar distributed in the
downloadable archive.
Can I simply put a manually adapted NOTICE/LICENSE file in the META-INF
folder of the respective projects? Or what is the normal procedure here?
> See this release policy:
> http://www.apache.org/dev/release.html#distribute-other-artifacts
>
> The attribution and notices you included in the svn tag files look good,
> you just need to make sure that they are included in all of your
> artifacts you want
> to distribute. The basic principle here is that you just include what
> is mandatory.
>
> The textmarker ide plugin jar file includes the icons, and uses ANTLR
> libraries through
> the textmarker engine. For the LICENSE and NOTICE file it only counts
> what is inside the distributable,
> in this case you only need to put the icons in the LICENSE/NOTICE but
> not ANTLR because their
> work is not included.
>
> The NOTICE file in the svn tag still has 2012 in it, should be updated
> to 2013.
>
Thanks for your help :-)
Peter
> Hope that helps,
> Jörn
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Jörn Kottmann <ko...@gmail.com>.
On 01/24/2013 10:39 AM, Peter Klügl wrote:
>> I found the icons in the uimaj-ep-textmarker-ide binary plugin jar
>> file, but
>> the LICENSE and NOTICE files do not contain the attribution and
>> license for them:
>>
>
> Hmm, yes. I thought it is enough to provide those modified files for
> the root project, which is released. I assume that maven has put the
> standard LICENSE/NOTICE files in META-INF. The question is: what do I
> need to do? Does each jar needs its individual files?
I am afraid to tell you that you need to have accurate NOTICE/LICENSE
files for all the artifacts you want to distribute.
As far as I know you can tell maven to not follow the standard behavior,
I believe Marshall already did it for
some of our artifacts already, e.g. the Cas Editor.
See this release policy:
http://www.apache.org/dev/release.html#distribute-other-artifacts
The attribution and notices you included in the svn tag files look good,
you just need to make sure that they are included in all of your
artifacts you want
to distribute. The basic principle here is that you just include what is
mandatory.
The textmarker ide plugin jar file includes the icons, and uses ANTLR
libraries through
the textmarker engine. For the LICENSE and NOTICE file it only counts
what is inside the distributable,
in this case you only need to put the icons in the LICENSE/NOTICE but
not ANTLR because their
work is not included.
The NOTICE file in the svn tag still has 2012 in it, should be updated
to 2013.
Hope that helps,
Jörn
Re: [VOTE] Apache UIMA TextMarker Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Hi,
On 23.01.2013 18:53, Jörn Kottmann wrote:
> Hello,
>
> the NOTICE / LICENSE files must contain the attribution and
> licenses of the redistributed 3rd party work.
>
> There are many of these files in many places, from the NOTICE / LICENSE
> pair at the root level of the svn tag I got the impression that you
> include
> these 3rd party works somewhere:
>
> - ANTLR libraries (BSD)
> - htmlparser (CPL)
> - Icons (Creative Commons)
>
> At which places are these actually included?
>
- ANTLR libraries (BSD) are packaged in
org.apache.uima.textmarker.engine_2.0.0.jar and are additionally used by
org.apache.uima.textmarker.ide_2.0.0.jar
- htmlparser (CPL) is packaged in
org.apache.uima.textmarker.engine_2.0.0.jar and used by an AE
implemented in this jar.
- Icons (Creative Commons) are packaged in all plugins
ANTLR and htmlparser are dependencies of uimaj-textmarker (the core
implementation of the rule-based AE) and
org.apache.uima.textmarker.engine is a fetcher plugin, which makes the
implementation and all neccessary dependencies available in Eclipse,
similar to the UIMA runtime plugin. org.apache.uima.textmarker.ide
contains also an antlr grammar for creating an AST (for editor support)
and therefore depends on the ANTLR implementation.
> I found the icons in the uimaj-ep-textmarker-ide binary plugin jar
> file, but
> the LICENSE and NOTICE files do not contain the attribution and
> license for them:
>
Hmm, yes. I thought it is enough to provide those modified files for the
root project, which is released. I assume that maven has put the
standard LICENSE/NOTICE files in META-INF. The question is: what do I
need to do? Does each jar needs its individual files?
There is a new page:
http://www.apache.org/dev/licensing-howto.html
I gonna take a look at it.
Peter
> Here is the link to the file:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/src_bin/org.apache.uima.textmarker.ide_2.0.0.jar
>
>
> Jörn
>
>
>
> On 01/23/2013 06:02 PM, Peter Klügl wrote:
>> Hi,
>>
>> the first release candidate of the sandbox project Apache UIMA
>> TextMarker is ready for voting.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-163/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Eclipse update site:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
>>
>>
>> The update site only contains the UIMA TextMarker plugins and is not
>> yet integrated in the composite repository because the composite
>> repository is not yet officially released.
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
>>
>>
>> As it is the first release, the report contains all fixed issues.
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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 Release Candidate 1
Posted by Jörn Kottmann <ko...@gmail.com>.
Hello,
the NOTICE / LICENSE files must contain the attribution and
licenses of the redistributed 3rd party work.
There are many of these files in many places, from the NOTICE / LICENSE
pair at the root level of the svn tag I got the impression that you include
these 3rd party works somewhere:
- ANTLR libraries (BSD)
- htmlparser (CPL)
- Icons (Creative Commons)
At which places are these actually included?
I found the icons in the uimaj-ep-textmarker-ide binary plugin jar
file, but
the LICENSE and NOTICE files do not contain the attribution and license
for them:
Here is the link to the file:
http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/src_bin/org.apache.uima.textmarker.ide_2.0.0.jar
Jörn
On 01/23/2013 06:02 PM, Peter Klügl wrote:
> Hi,
>
> the first release candidate of the sandbox project Apache UIMA
> TextMarker is ready for voting.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-163/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Eclipse update site:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
>
>
> The update site only contains the UIMA TextMarker plugins and is not
> yet integrated in the composite repository because the composite
> repository is not yet officially released.
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
>
>
> As it is the first release, the report contains all fixed issues.
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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 Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
On 1/24/2013 11:35 AM, Peter Klügl wrote:
> Hi,
>
> Am 24.01.2013 17:09, schrieb Marshall Schor:
>> On 1/24/2013 4:52 AM, Peter Klügl wrote:
>>> Just another comment about the composite repository:
>>>
>>> I refrained from providing an extended composite repository, because, as I
>>> already mentioned, it is not yet officially available (or am I wrong?).
>>> However, there are also two small additional reasons: I do not believe that
>>> this rc is the last one (so that the extended composite repository would be
>>> released as it is) and my feature (should) use another category. Therefore, it
>>> should be quite independent of the other subsites.
>> My thought was that we would use the release vote for TextMarker to do the
>> switch from our previous non-P2 repo to the new P2 repo (with composite
>> repository) design :-). However, if there is a need to go ahead and release the
>> new p2 update site before the textmarker release, we could do that, too (but in
>> the interest of avoiding extra "churn" and work, I'd like to avoid that if we
>> could).
>
> Ah OK, no problem. I will provide the composite repository with the three
> update sites in the next RC and change the name of the vote to reflect that we
> also vote on the conposite repository.
+1
>
>> I agree your feature should likely use a new category ("TextMarker" ?). Or, if
>> you think it will be just one feature, it could be added to the
>> uima-tooling-and-runtimes category.
>>
>> (We currently have 2 categories: the uima-tooling-and-runtimes, and the
>> uima-as-tooling.)
>
> Currently, there is a new category "uima-textmarker" / "Apache UIMA
> TextMarker" with one feature "UIMA TextMarker Workbench". When I think now
> about that, then we should probably have two features, one for the
> workbench/ide/tooling and one for the engine. (We can do that in the next
> release if there is a need)
+1
>
> I think it is better to have a separate update site since the code quality of
> the textmarker projects is still way behind the rest of uima. There will also
> probably be shorter release cycles. So, we do not have to touch the other
> update sites, when we release a new textmarker update site. The textmarker
> update site is already ready, thus merging would be more work now and for the
> next release.
+1. Once the composite site is setup for the textmarker subsite, it won't need
to be touched for subsequent release cycles of textmarker :-)
-Marshall
>
> Peter
>
>
>>
>> -Marshall
>>> Peter
>>>
>>>
>>> On 23.01.2013 18:02, Peter Klügl wrote:
>>>> Hi,
>>>>
>>>> the first release candidate of the sandbox project Apache UIMA TextMarker is
>>>> ready for voting.
>>>>
>>>> Staging repository:
>>>> https://repository.apache.org/content/repositories/orgapacheuima-163/
>>>>
>>>> SVN tag:
>>>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
>>>>
>>>>
>>>>
>>>> Archive with all sources:
>>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
>>>>
>>>>
>>>>
>>>> Eclipse update site:
>>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
>>>>
>>>>
>>>>
>>>> The update site only contains the UIMA TextMarker plugins and is not yet
>>>> integrated in the composite repository because the composite repository is
>>>> not yet officially released.
>>>>
>>>> Binaries and sources:
>>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
>>>>
>>>>
>>>>
>>>> As it is the first release, the report contains all fixed issues.
>>>>
>>>> Documentation (pdf file):
>>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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 Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Hi,
Am 24.01.2013 17:09, schrieb Marshall Schor:
> On 1/24/2013 4:52 AM, Peter Klügl wrote:
>> Just another comment about the composite repository:
>>
>> I refrained from providing an extended composite repository, because, as I
>> already mentioned, it is not yet officially available (or am I wrong?).
>> However, there are also two small additional reasons: I do not believe that
>> this rc is the last one (so that the extended composite repository would be
>> released as it is) and my feature (should) use another category. Therefore, it
>> should be quite independent of the other subsites.
> My thought was that we would use the release vote for TextMarker to do the
> switch from our previous non-P2 repo to the new P2 repo (with composite
> repository) design :-). However, if there is a need to go ahead and release the
> new p2 update site before the textmarker release, we could do that, too (but in
> the interest of avoiding extra "churn" and work, I'd like to avoid that if we
> could).
Ah OK, no problem. I will provide the composite repository with the
three update sites in the next RC and change the name of the vote to
reflect that we also vote on the conposite repository.
> I agree your feature should likely use a new category ("TextMarker" ?). Or, if
> you think it will be just one feature, it could be added to the
> uima-tooling-and-runtimes category.
>
> (We currently have 2 categories: the uima-tooling-and-runtimes, and the
> uima-as-tooling.)
Currently, there is a new category "uima-textmarker" / "Apache UIMA
TextMarker" with one feature "UIMA TextMarker Workbench". When I think
now about that, then we should probably have two features, one for the
workbench/ide/tooling and one for the engine. (We can do that in the
next release if there is a need)
I think it is better to have a separate update site since the code
quality of the textmarker projects is still way behind the rest of uima.
There will also probably be shorter release cycles. So, we do not have
to touch the other update sites, when we release a new textmarker update
site. The textmarker update site is already ready, thus merging would be
more work now and for the next release.
Peter
>
> -Marshall
>> Peter
>>
>>
>> On 23.01.2013 18:02, Peter Klügl wrote:
>>> Hi,
>>>
>>> the first release candidate of the sandbox project Apache UIMA TextMarker is
>>> ready for voting.
>>>
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapacheuima-163/
>>>
>>> SVN tag:
>>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
>>>
>>>
>>> Archive with all sources:
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
>>>
>>>
>>> Eclipse update site:
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
>>>
>>>
>>> The update site only contains the UIMA TextMarker plugins and is not yet
>>> integrated in the composite repository because the composite repository is
>>> not yet officially released.
>>>
>>> Binaries and sources:
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
>>>
>>>
>>> As it is the first release, the report contains all fixed issues.
>>>
>>> Documentation (pdf file):
>>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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 Release Candidate 1
Posted by Marshall Schor <ms...@schor.com>.
On 1/24/2013 4:52 AM, Peter Klügl wrote:
> Just another comment about the composite repository:
>
> I refrained from providing an extended composite repository, because, as I
> already mentioned, it is not yet officially available (or am I wrong?).
> However, there are also two small additional reasons: I do not believe that
> this rc is the last one (so that the extended composite repository would be
> released as it is) and my feature (should) use another category. Therefore, it
> should be quite independent of the other subsites.
My thought was that we would use the release vote for TextMarker to do the
switch from our previous non-P2 repo to the new P2 repo (with composite
repository) design :-). However, if there is a need to go ahead and release the
new p2 update site before the textmarker release, we could do that, too (but in
the interest of avoiding extra "churn" and work, I'd like to avoid that if we
could).
I agree your feature should likely use a new category ("TextMarker" ?). Or, if
you think it will be just one feature, it could be added to the
uima-tooling-and-runtimes category.
(We currently have 2 categories: the uima-tooling-and-runtimes, and the
uima-as-tooling.)
-Marshall
>
> Peter
>
>
> On 23.01.2013 18:02, Peter Klügl wrote:
>> Hi,
>>
>> the first release candidate of the sandbox project Apache UIMA TextMarker is
>> ready for voting.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapacheuima-163/
>>
>> SVN tag:
>> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
>>
>>
>> Archive with all sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
>>
>>
>> Eclipse update site:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
>>
>>
>> The update site only contains the UIMA TextMarker plugins and is not yet
>> integrated in the composite repository because the composite repository is
>> not yet officially released.
>>
>> Binaries and sources:
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
>>
>>
>> As it is the first release, the report contains all fixed issues.
>>
>> Documentation (pdf file):
>> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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 Release Candidate 1
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Just another comment about the composite repository:
I refrained from providing an extended composite repository, because, as
I already mentioned, it is not yet officially available (or am I
wrong?). However, there are also two small additional reasons: I do not
believe that this rc is the last one (so that the extended composite
repository would be released as it is) and my feature (should) use
another category. Therefore, it should be quite independent of the other
subsites.
Peter
On 23.01.2013 18:02, Peter Klügl wrote:
> Hi,
>
> the first release candidate of the sandbox project Apache UIMA
> TextMarker is ready for voting.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-163/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/sandbox/TextMarker/tags/uimaj-textmarker-parent-2.0.0-rc1
>
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/uimaj-textmarker-parent-2.0.0-source-release.zip
>
>
> Eclipse update site:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/eclipse-update-site
>
>
> The update site only contains the UIMA TextMarker plugins and is not
> yet integrated in the composite repository because the composite
> repository is not yet officially released.
>
> Binaries and sources:
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/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
>
>
> As it is the first release, the report contains all fixed issues.
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/TextMarker-2.0.0-rc1/tools.textmarker.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter