You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de> on 2013/08/18 19:24:31 UTC
[VOTE] Release uimaFIT 2.0.0 rc2
Hi,
I've posted uimaFIT 2.0.0 rc2. There were 85 Jiras fixed, see
https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
The source and binary zip/tars are staged to
http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc2/
<http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc2/>
The Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapacheuima-104/org/apache/uima/
The SVN tags are here:
https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc2
See http://uima.apache.org/testing-builds.html for suggestions on how to test
release candidates.
Please vote on release:
[ ] +1 OK to release
[ ] 0 Don't care
[ ] -1 Not OK to release, because …
This RC incorporates the comments from Marshal (thanks!) on RC1 as well as some issues that meanwhile had cropped up.
Thanks.
-- Richard
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
Added an explanatory section on the modules, including the Spring module,
in the README.
I did search if "Spring Framework" was trademarked, but apparently it is not.
Some people seem to be cautious and add a (tm) behind it, but I did not found
is being attributed to any entity. Neither did a USTPO TESS search yield any
results. So I didn't add a TM for Spring in the README.
Cheers,
-- Richard
Am 20.08.2013 um 17:05 schrieb Marshall Schor <ms...@schor.com>:
> nice blog link :-)
>
> My personal preference is to be perhaps more up-front/transparent, and state in
> the README what you say here - that it's there as a proof-of-concept etc.
>
> -Marshall
>
> On 8/19/2013 4:13 PM, Richard Eckart de Castilho wrote:
>> uimafit-spring is an experimental module. I built it as a proof of concept,
>> but never used it myself. Still, it has been made public (even to Maven
>> Central) in case somebody finds it useful. Apparently, it has found some
>> users (and even somebody to blog about it!) [1], but I have never considered
>> it as finished or an official part of the package. It has been released with
>> past releases with the same version number as the rest of uimaFIT to
>> Maven Central. It wasn't part of the binary distribution though.
>>
>> Personally, I'd stick to that strategy. Put it on Maven for the hardcore
>> few that may find it useful, but keep it out of the binary distribution,
>> at least until it has received some more attention. Currently, it uses
>> reflection to patch itself into the UIMA framework and then passes all
>> components created through UIMA through Spring to provide for the wiring
>> of Spring context dependencies.
>>
>> -- Richard
>>
>> [1] http://agibsonccc.tumblr.com
>>
>> Am 19.08.2013 um 21:59 schrieb Marshall Schor <ms...@schor.com>:
>>
>>> missed one:
>>>
>>> The build builds uimafit-spring, but that's not a dependency by anything?
>>> Is it needed?
>>>
>>> -Marshall
>>>
>>> On 8/19/2013 3:26 PM, Marshall Schor wrote:
>>>> The binary release includes 3 jars from uimafit:
>>>>
>>>> uimafit-core
>>>> uimafit-cpe
>>>> uimafit-legacy-support
>>>>
>>>> I looked through the readme and the documentation for mentions of the last 2.
>>>> The readme says you only need uimafit-core. The docbook doesn't mention cpe or
>>>> legacy. I also looked in the uimafit-core pom and uimafit-parent pom for
>>>> references to thes last 2 and didn't find any (maybe it's there and I just
>>>> missed it...)
>>>>
>>>> Are these last 2 jars needed? If so, should they be documented somewhere?
>>>>
>>>> -Marshall
>
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
nice blog link :-)
My personal preference is to be perhaps more up-front/transparent, and state in
the README what you say here - that it's there as a proof-of-concept etc.
-Marshall
On 8/19/2013 4:13 PM, Richard Eckart de Castilho wrote:
> uimafit-spring is an experimental module. I built it as a proof of concept,
> but never used it myself. Still, it has been made public (even to Maven
> Central) in case somebody finds it useful. Apparently, it has found some
> users (and even somebody to blog about it!) [1], but I have never considered
> it as finished or an official part of the package. It has been released with
> past releases with the same version number as the rest of uimaFIT to
> Maven Central. It wasn't part of the binary distribution though.
>
> Personally, I'd stick to that strategy. Put it on Maven for the hardcore
> few that may find it useful, but keep it out of the binary distribution,
> at least until it has received some more attention. Currently, it uses
> reflection to patch itself into the UIMA framework and then passes all
> components created through UIMA through Spring to provide for the wiring
> of Spring context dependencies.
>
> -- Richard
>
> [1] http://agibsonccc.tumblr.com
>
> Am 19.08.2013 um 21:59 schrieb Marshall Schor <ms...@schor.com>:
>
>> missed one:
>>
>> The build builds uimafit-spring, but that's not a dependency by anything?
>> Is it needed?
>>
>> -Marshall
>>
>> On 8/19/2013 3:26 PM, Marshall Schor wrote:
>>> The binary release includes 3 jars from uimafit:
>>>
>>> uimafit-core
>>> uimafit-cpe
>>> uimafit-legacy-support
>>>
>>> I looked through the readme and the documentation for mentions of the last 2.
>>> The readme says you only need uimafit-core. The docbook doesn't mention cpe or
>>> legacy. I also looked in the uimafit-core pom and uimafit-parent pom for
>>> references to thes last 2 and didn't find any (maybe it's there and I just
>>> missed it...)
>>>
>>> Are these last 2 jars needed? If so, should they be documented somewhere?
>>>
>>> -Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
uimafit-spring is an experimental module. I built it as a proof of concept,
but never used it myself. Still, it has been made public (even to Maven
Central) in case somebody finds it useful. Apparently, it has found some
users (and even somebody to blog about it!) [1], but I have never considered
it as finished or an official part of the package. It has been released with
past releases with the same version number as the rest of uimaFIT to
Maven Central. It wasn't part of the binary distribution though.
Personally, I'd stick to that strategy. Put it on Maven for the hardcore
few that may find it useful, but keep it out of the binary distribution,
at least until it has received some more attention. Currently, it uses
reflection to patch itself into the UIMA framework and then passes all
components created through UIMA through Spring to provide for the wiring
of Spring context dependencies.
-- Richard
[1] http://agibsonccc.tumblr.com
Am 19.08.2013 um 21:59 schrieb Marshall Schor <ms...@schor.com>:
> missed one:
>
> The build builds uimafit-spring, but that's not a dependency by anything?
> Is it needed?
>
> -Marshall
>
> On 8/19/2013 3:26 PM, Marshall Schor wrote:
>> The binary release includes 3 jars from uimafit:
>>
>> uimafit-core
>> uimafit-cpe
>> uimafit-legacy-support
>>
>> I looked through the readme and the documentation for mentions of the last 2.
>> The readme says you only need uimafit-core. The docbook doesn't mention cpe or
>> legacy. I also looked in the uimafit-core pom and uimafit-parent pom for
>> references to thes last 2 and didn't find any (maybe it's there and I just
>> missed it...)
>>
>> Are these last 2 jars needed? If so, should they be documented somewhere?
>>
>> -Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
missed one:
The build builds uimafit-spring, but that's not a dependency by anything?
Is it needed?
-Marshall
On 8/19/2013 3:26 PM, Marshall Schor wrote:
> The binary release includes 3 jars from uimafit:
>
> uimafit-core
> uimafit-cpe
> uimafit-legacy-support
>
> I looked through the readme and the documentation for mentions of the last 2.
> The readme says you only need uimafit-core. The docbook doesn't mention cpe or
> legacy. I also looked in the uimafit-core pom and uimafit-parent pom for
> references to thes last 2 and didn't find any (maybe it's there and I just
> missed it...)
>
> Are these last 2 jars needed? If so, should they be documented somewhere?
>
> -Marshall
>
>
>
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
On 8/19/2013 3:40 PM, Richard Eckart de Castilho wrote:
> They are not needed, but convenient to have. The CPE stuff was moved
> to a separate JAR to reduce the dependencies for uimafit-core. It might
> deserve a mention in the documentation. I wouldn't see it as critical though.
>
> The legacy JAR is actually documented, but the documentation is not included
> with the release :/
>
> What do you think, should the migration information be in the README, in
> the docbook?
I have a slight preference for the docbook, with a mention of it's existence in
the readme. Wikis sometimes have a poor reputation of not being thought of as
up-to-date.
-Marshall
>
> https://cwiki.apache.org/confluence/display/UIMA/Migration+guide+1.x+to+2.x
>
> -- Richard
>
> Am 19.08.2013 um 21:26 schrieb Marshall Schor <ms...@schor.com>:
>
>> The binary release includes 3 jars from uimafit:
>>
>> uimafit-core
>> uimafit-cpe
>> uimafit-legacy-support
>>
>> I looked through the readme and the documentation for mentions of the last 2.
>> The readme says you only need uimafit-core. The docbook doesn't mention cpe or
>> legacy. I also looked in the uimafit-core pom and uimafit-parent pom for
>> references to thes last 2 and didn't find any (maybe it's there and I just
>> missed it...)
>>
>> Are these last 2 jars needed? If so, should they be documented somewhere?
>>
>> -Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
They are not needed, but convenient to have. The CPE stuff was moved
to a separate JAR to reduce the dependencies for uimafit-core. It might
deserve a mention in the documentation. I wouldn't see it as critical though.
The legacy JAR is actually documented, but the documentation is not included
with the release :/
What do you think, should the migration information be in the README, in
the docbook?
https://cwiki.apache.org/confluence/display/UIMA/Migration+guide+1.x+to+2.x
-- Richard
Am 19.08.2013 um 21:26 schrieb Marshall Schor <ms...@schor.com>:
> The binary release includes 3 jars from uimafit:
>
> uimafit-core
> uimafit-cpe
> uimafit-legacy-support
>
> I looked through the readme and the documentation for mentions of the last 2.
> The readme says you only need uimafit-core. The docbook doesn't mention cpe or
> legacy. I also looked in the uimafit-core pom and uimafit-parent pom for
> references to thes last 2 and didn't find any (maybe it's there and I just
> missed it...)
>
> Are these last 2 jars needed? If so, should they be documented somewhere?
>
> -Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
The binary release includes 3 jars from uimafit:
uimafit-core
uimafit-cpe
uimafit-legacy-support
I looked through the readme and the documentation for mentions of the last 2.
The readme says you only need uimafit-core. The docbook doesn't mention cpe or
legacy. I also looked in the uimafit-core pom and uimafit-parent pom for
references to thes last 2 and didn't find any (maybe it's there and I just
missed it...)
Are these last 2 jars needed? If so, should they be documented somewhere?
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2 - release notes or augmented
readme in the binary distribution
Posted by Marshall Schor <ms...@schor.com>.
Some information normally present in a binary packaging is missing - things
normally present in release notes. These include a link to the issues-fixed
list (which is also missing in the binary distribution), as well as a high level
summary of the release (e.g., what's new, etc.).
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
I did a compare source w/ svn checkout - OK (but found some iffy files with
respect to line endings).
I checked the licenses & notices, they seem OK, including inside JARs we build.
I checked the signatures / md5/sha - OK
I cleared my .m2 of uimafit things and built from source - OK (except for
excessive RAT excludes, and some pdf formatting issues)
So, basically, I think this is OK to release, except there's quite a few mostly
minor things that probably should be fixed, but not quite show stoppers; because
of this, I recommend fixing these and doing rc3.
So, I'm voting +0 for now :-).
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
two more: uimafit-cpe and uimafit-docbook exclude non-existent wiki
On 8/19/2013 5:08 PM, Marshall Schor wrote:
> The RAT checking is excluding things that probably ought to be checked, and in
> some cases isn't needed (because the artifact in question has the license header).
>
> Generally, RAT exclusions are for files of test data that can't reasonably have
> a header, or for generated files, or for small bits of data that has no IP value.
>
> Some details:
>
> in uimafit-core: src/main/resources/**/* only has 1 file, and that file has the
> license header, so I think this can be removed.
>
> in uimafit-spring: src/main/resources/**/* but there are no files in
> src/main/resources
> in uimafit-spring: src/test/resources/**/* but there are no files in
> src/test/resources
> in uimafit-spring: apidocs/package-list - this directory is not present?
> in uimafit-maven-plugin: wiki/**/* - this directory is not present?
> in Legacy support: src/main/resources/**/* - directory not present
> in legacy support: src/test/java/org/apache/uima/fit/type/**/* there's no such
> directory .../fit/type/...
>
> I probably didn't cover everything; in general, it's important to be pretty
> minimal with RAT exclusions to avoid missing checking something that should be
> checked :-)
>
> -Marshall
>
>
>
>
>
>
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
The RAT checking is excluding things that probably ought to be checked, and in
some cases isn't needed (because the artifact in question has the license header).
Generally, RAT exclusions are for files of test data that can't reasonably have
a header, or for generated files, or for small bits of data that has no IP value.
Some details:
in uimafit-core: src/main/resources/**/* only has 1 file, and that file has the
license header, so I think this can be removed.
in uimafit-spring: src/main/resources/**/* but there are no files in
src/main/resources
in uimafit-spring: src/test/resources/**/* but there are no files in
src/test/resources
in uimafit-spring: apidocs/package-list - this directory is not present?
in uimafit-maven-plugin: wiki/**/* - this directory is not present?
in Legacy support: src/main/resources/**/* - directory not present
in legacy support: src/test/java/org/apache/uima/fit/type/**/* there's no such
directory .../fit/type/...
I probably didn't cover everything; in general, it's important to be pretty
minimal with RAT exclusions to avoid missing checking something that should be
checked :-)
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
I'm starting to review this release. Here's the first batch - non-blockers in
my opinion.
1) The issues fixed title is in German; it says "JIRA-Bericht"
2) The binary distr is missing the issues fixed. The source distribution has
this not at the top level, but rather, as a directory under the uimafit-parent.
3) Some test files might or might not need to have the svn eol-style set
differently than "native", if the tests depend on the line end style being a
certain way. I don't know if this is an issue, but did see one file in examples
with file time ".pos" that looked like test data.
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
On 8/19/2013 5:33 AM, Richard Eckart de Castilho wrote:
> Am 19.08.2013 um 06:41 schrieb Marshall Schor <ms...@schor.com>:
>
>> general question: the source-release zip has a top level folder called "wiki".
>> What's the intent of this?
> It is an artifact of the build process. I have changed the setup so that the
> aggregator POM is also used for the release (as in uimaj). In the initial
> contribution, the "wiki" folder was supplied as a directory under the root.
> Since the source zip basically takes a snapshot of the SVN layout, it is
> included.
>
> So actually, there is no intent to include it - it is just historically in a
> location which in included in the source build.
+1 to move to an archive spot, or, even, svn delete it (it's still there of
course and can be recovered if needed).
-Marshall
>
> The best solution would probably be to delete this folder or move it to some "attic"
> in SVN. Anything that could be salvaged from these pages has been incorporated
> into the docbook module.
>
> -- Richard
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
Am 19.08.2013 um 06:41 schrieb Marshall Schor <ms...@schor.com>:
> general question: the source-release zip has a top level folder called "wiki".
> What's the intent of this?
It is an artifact of the build process. I have changed the setup so that the
aggregator POM is also used for the release (as in uimaj). In the initial
contribution, the "wiki" folder was supplied as a directory under the root.
Since the source zip basically takes a snapshot of the SVN layout, it is
included.
So actually, there is no intent to include it - it is just historically in a
location which in included in the source build.
The best solution would probably be to delete this folder or move it to some "attic"
in SVN. Anything that could be salvaged from these pages has been incorporated
into the docbook module.
-- Richard
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
general question: the source-release zip has a top level folder called "wiki".
What's the intent of this?
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
one responder from trademarks@ thinks that Apache uimaFIT(tm) (on first use) is
fine.
I tend to agree with this, and think this is a good solution.
-Marshall
On 8/20/2013 9:35 AM, Marshall Schor wrote:
> sent a note to trademarks@ asking for their opinion. -Marshall
> On 8/20/2013 9:27 AM, Marshall Schor wrote:
>> After thinking about this overnight, I have a new thought.
>>
>> I think the only trademark we need to be concerned with is Apache UIMA. When I
>> look at the docbook for UIMA-AS, the "TM" is attached to the top of the html /
>> pdf file, where it says "Written and maintained by the Apache UIMA (tm)
>> Development Community". This is at the top in the html, but comes right after
>> the title in the PDF.
>>
>> Following that line of reasoning, we can use uimaFIT without any trademark
>> symbol, if Apache UIMA is "protected" by (tm).
>>
>> I think the ASF requires us to tm only the main project name; other tm's are
>> optional.
>>
>> What do others think?
>>
>> -Marshall
>>
>> On 8/19/2013 5:16 PM, Marshall Schor wrote:
>>> On 8/19/2013 3:52 PM, Richard Eckart de Castilho wrote:
>>>> Am 19.08.2013 um 21:37 schrieb Marshall Schor <ms...@schor.com>:
>>>>> On 8/19/2013 11:12 AM, Richard Eckart de Castilho wrote:
>>>>>> Am 19.08.2013 um 17:03 schrieb Marshall Schor <ms...@schor.com>:
>>>>>>
>>>>>>> trademark checking:
>>>>>>>
>>>>>>> The first use of the word UIMA in a significant document should be written with
>>>>>>> a preceeding "Apache" and a following ™ sign (that's the trademark sign).
>>>>>>> Subsequent uses can just write UIMA.
>>>>>>>
>>>>>>> A significant doc would be things like the docbook (it's missing).
>>>>>>>
>>>>>>> Has anyone talked to trademarks@ to see about the term uimaFIT?
>>>>>> Not explicitly. The IP clearance vote has been done on the incubator
>>>>>> list per workflow:
>>>>>>
>>>>>> Vote: http://markmail.org/message/xz5at7asrnkx4t2e
>>>>>> Result: http://markmail.org/thread/iarcwb7efs3mburu
>>>>>>
>>>>>> Are you suggesting that, possibly in the light of the renaming of Ruta,
>>>>>> a preemptive involvement of trademarks@ would be wise?
>>>>> nope. I'm referring to following these policies:
>>>>> http://www.apache.org/foundation/marks/pmcs.html
>>>>>
>>>>> The relevant sections (written for "web pages", but I think applies to other
>>>>> significant documentation):
>>>>>
>>>>> The first and most prominent reference to a project or product on each page must
>>>>> use the "Apache Foo" form of its name. Other references may use either "Apache
>>>>> Foo" or "Foo" as appropriate for the subject matter.
>>>>>
>>>>> At the top of each project or product homepage, and on the top banner of each
>>>>> page where the project name appears, you should include a "TM" symbol next to
>>>>> the *first* main occurrence of the "Apache Foo" project name. This highlights
>>>>> our trademark claim and emphasizes its importance to us.
>>>>>
>>>>> If you haven't already, please read this too:
>>>>> http://www.apache.org/foundation/marks/responsibility.html
>>>> Thanks for your comments. I wasn't aware this had not been sufficiently addressed
>>>> in the past, but I suppose it wasn't.
>>>>
>>>> Just to make sure I'm not reading this with the wrong set of eyes.
>>>>
>>>> Is it correct that your main concern is currently the presentation of the brand,
>>>> in particular its markings and mentions?
>>>>
>>>> Are there any objections to using the name "Apache uimaFIT"?
>>> I think uimaFIT would need to be a top level project to have that name, but I
>>> think it's best to run these by the trademarks@ folks.
>>>> If so, would "Apache UIMA uimaFIT" be more appropriate?
>>> That's quite a mouthful, but I think that's the "correct" way to say it (one
>>> time); afterwards, I would use just uimaFIT.
>>>
>>> Again, I think it would be good to ask trademarks@ about using just uimaFIT as a
>>> trademark, itself, just to see what they say.
>>>
>>>> Do you think the moniker "Apache (UIMA) uimaFIT" should be discussed with anybody else
>>>> at the foundation?
>>> Other than trademarks@, no. They are the designated people to have this
>>> discussion with.
>>>> Are there any further concerns that I should be particularly aware of or mind when
>>>> reading these pages?
>>> Only that we're required to follow and enforce these policies as PMC members :-).
>>>
>>> -Marshall
>>>
>
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
sent a note to trademarks@ asking for their opinion. -Marshall
On 8/20/2013 9:27 AM, Marshall Schor wrote:
> After thinking about this overnight, I have a new thought.
>
> I think the only trademark we need to be concerned with is Apache UIMA. When I
> look at the docbook for UIMA-AS, the "TM" is attached to the top of the html /
> pdf file, where it says "Written and maintained by the Apache UIMA (tm)
> Development Community". This is at the top in the html, but comes right after
> the title in the PDF.
>
> Following that line of reasoning, we can use uimaFIT without any trademark
> symbol, if Apache UIMA is "protected" by (tm).
>
> I think the ASF requires us to tm only the main project name; other tm's are
> optional.
>
> What do others think?
>
> -Marshall
>
> On 8/19/2013 5:16 PM, Marshall Schor wrote:
>> On 8/19/2013 3:52 PM, Richard Eckart de Castilho wrote:
>>> Am 19.08.2013 um 21:37 schrieb Marshall Schor <ms...@schor.com>:
>>>> On 8/19/2013 11:12 AM, Richard Eckart de Castilho wrote:
>>>>> Am 19.08.2013 um 17:03 schrieb Marshall Schor <ms...@schor.com>:
>>>>>
>>>>>> trademark checking:
>>>>>>
>>>>>> The first use of the word UIMA in a significant document should be written with
>>>>>> a preceeding "Apache" and a following ™ sign (that's the trademark sign).
>>>>>> Subsequent uses can just write UIMA.
>>>>>>
>>>>>> A significant doc would be things like the docbook (it's missing).
>>>>>>
>>>>>> Has anyone talked to trademarks@ to see about the term uimaFIT?
>>>>> Not explicitly. The IP clearance vote has been done on the incubator
>>>>> list per workflow:
>>>>>
>>>>> Vote: http://markmail.org/message/xz5at7asrnkx4t2e
>>>>> Result: http://markmail.org/thread/iarcwb7efs3mburu
>>>>>
>>>>> Are you suggesting that, possibly in the light of the renaming of Ruta,
>>>>> a preemptive involvement of trademarks@ would be wise?
>>>> nope. I'm referring to following these policies:
>>>> http://www.apache.org/foundation/marks/pmcs.html
>>>>
>>>> The relevant sections (written for "web pages", but I think applies to other
>>>> significant documentation):
>>>>
>>>> The first and most prominent reference to a project or product on each page must
>>>> use the "Apache Foo" form of its name. Other references may use either "Apache
>>>> Foo" or "Foo" as appropriate for the subject matter.
>>>>
>>>> At the top of each project or product homepage, and on the top banner of each
>>>> page where the project name appears, you should include a "TM" symbol next to
>>>> the *first* main occurrence of the "Apache Foo" project name. This highlights
>>>> our trademark claim and emphasizes its importance to us.
>>>>
>>>> If you haven't already, please read this too:
>>>> http://www.apache.org/foundation/marks/responsibility.html
>>> Thanks for your comments. I wasn't aware this had not been sufficiently addressed
>>> in the past, but I suppose it wasn't.
>>>
>>> Just to make sure I'm not reading this with the wrong set of eyes.
>>>
>>> Is it correct that your main concern is currently the presentation of the brand,
>>> in particular its markings and mentions?
>>>
>>> Are there any objections to using the name "Apache uimaFIT"?
>> I think uimaFIT would need to be a top level project to have that name, but I
>> think it's best to run these by the trademarks@ folks.
>>> If so, would "Apache UIMA uimaFIT" be more appropriate?
>> That's quite a mouthful, but I think that's the "correct" way to say it (one
>> time); afterwards, I would use just uimaFIT.
>>
>> Again, I think it would be good to ask trademarks@ about using just uimaFIT as a
>> trademark, itself, just to see what they say.
>>
>>> Do you think the moniker "Apache (UIMA) uimaFIT" should be discussed with anybody else
>>> at the foundation?
>> Other than trademarks@, no. They are the designated people to have this
>> discussion with.
>>> Are there any further concerns that I should be particularly aware of or mind when
>>> reading these pages?
>> Only that we're required to follow and enforce these policies as PMC members :-).
>>
>> -Marshall
>>
>
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
After thinking about this overnight, I have a new thought.
I think the only trademark we need to be concerned with is Apache UIMA. When I
look at the docbook for UIMA-AS, the "TM" is attached to the top of the html /
pdf file, where it says "Written and maintained by the Apache UIMA (tm)
Development Community". This is at the top in the html, but comes right after
the title in the PDF.
Following that line of reasoning, we can use uimaFIT without any trademark
symbol, if Apache UIMA is "protected" by (tm).
I think the ASF requires us to tm only the main project name; other tm's are
optional.
What do others think?
-Marshall
On 8/19/2013 5:16 PM, Marshall Schor wrote:
> On 8/19/2013 3:52 PM, Richard Eckart de Castilho wrote:
>> Am 19.08.2013 um 21:37 schrieb Marshall Schor <ms...@schor.com>:
>>> On 8/19/2013 11:12 AM, Richard Eckart de Castilho wrote:
>>>> Am 19.08.2013 um 17:03 schrieb Marshall Schor <ms...@schor.com>:
>>>>
>>>>> trademark checking:
>>>>>
>>>>> The first use of the word UIMA in a significant document should be written with
>>>>> a preceeding "Apache" and a following ™ sign (that's the trademark sign).
>>>>> Subsequent uses can just write UIMA.
>>>>>
>>>>> A significant doc would be things like the docbook (it's missing).
>>>>>
>>>>> Has anyone talked to trademarks@ to see about the term uimaFIT?
>>>> Not explicitly. The IP clearance vote has been done on the incubator
>>>> list per workflow:
>>>>
>>>> Vote: http://markmail.org/message/xz5at7asrnkx4t2e
>>>> Result: http://markmail.org/thread/iarcwb7efs3mburu
>>>>
>>>> Are you suggesting that, possibly in the light of the renaming of Ruta,
>>>> a preemptive involvement of trademarks@ would be wise?
>>> nope. I'm referring to following these policies:
>>> http://www.apache.org/foundation/marks/pmcs.html
>>>
>>> The relevant sections (written for "web pages", but I think applies to other
>>> significant documentation):
>>>
>>> The first and most prominent reference to a project or product on each page must
>>> use the "Apache Foo" form of its name. Other references may use either "Apache
>>> Foo" or "Foo" as appropriate for the subject matter.
>>>
>>> At the top of each project or product homepage, and on the top banner of each
>>> page where the project name appears, you should include a "TM" symbol next to
>>> the *first* main occurrence of the "Apache Foo" project name. This highlights
>>> our trademark claim and emphasizes its importance to us.
>>>
>>> If you haven't already, please read this too:
>>> http://www.apache.org/foundation/marks/responsibility.html
>> Thanks for your comments. I wasn't aware this had not been sufficiently addressed
>> in the past, but I suppose it wasn't.
>>
>> Just to make sure I'm not reading this with the wrong set of eyes.
>>
>> Is it correct that your main concern is currently the presentation of the brand,
>> in particular its markings and mentions?
>>
>> Are there any objections to using the name "Apache uimaFIT"?
> I think uimaFIT would need to be a top level project to have that name, but I
> think it's best to run these by the trademarks@ folks.
>> If so, would "Apache UIMA uimaFIT" be more appropriate?
> That's quite a mouthful, but I think that's the "correct" way to say it (one
> time); afterwards, I would use just uimaFIT.
>
> Again, I think it would be good to ask trademarks@ about using just uimaFIT as a
> trademark, itself, just to see what they say.
>
>> Do you think the moniker "Apache (UIMA) uimaFIT" should be discussed with anybody else
>> at the foundation?
> Other than trademarks@, no. They are the designated people to have this
> discussion with.
>> Are there any further concerns that I should be particularly aware of or mind when
>> reading these pages?
> Only that we're required to follow and enforce these policies as PMC members :-).
>
> -Marshall
>
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
On 8/19/2013 3:52 PM, Richard Eckart de Castilho wrote:
> Am 19.08.2013 um 21:37 schrieb Marshall Schor <ms...@schor.com>:
>> On 8/19/2013 11:12 AM, Richard Eckart de Castilho wrote:
>>> Am 19.08.2013 um 17:03 schrieb Marshall Schor <ms...@schor.com>:
>>>
>>>> trademark checking:
>>>>
>>>> The first use of the word UIMA in a significant document should be written with
>>>> a preceeding "Apache" and a following ™ sign (that's the trademark sign).
>>>> Subsequent uses can just write UIMA.
>>>>
>>>> A significant doc would be things like the docbook (it's missing).
>>>>
>>>> Has anyone talked to trademarks@ to see about the term uimaFIT?
>>> Not explicitly. The IP clearance vote has been done on the incubator
>>> list per workflow:
>>>
>>> Vote: http://markmail.org/message/xz5at7asrnkx4t2e
>>> Result: http://markmail.org/thread/iarcwb7efs3mburu
>>>
>>> Are you suggesting that, possibly in the light of the renaming of Ruta,
>>> a preemptive involvement of trademarks@ would be wise?
>> nope. I'm referring to following these policies:
>> http://www.apache.org/foundation/marks/pmcs.html
>>
>> The relevant sections (written for "web pages", but I think applies to other
>> significant documentation):
>>
>> The first and most prominent reference to a project or product on each page must
>> use the "Apache Foo" form of its name. Other references may use either "Apache
>> Foo" or "Foo" as appropriate for the subject matter.
>>
>> At the top of each project or product homepage, and on the top banner of each
>> page where the project name appears, you should include a "TM" symbol next to
>> the *first* main occurrence of the "Apache Foo" project name. This highlights
>> our trademark claim and emphasizes its importance to us.
>>
>> If you haven't already, please read this too:
>> http://www.apache.org/foundation/marks/responsibility.html
> Thanks for your comments. I wasn't aware this had not been sufficiently addressed
> in the past, but I suppose it wasn't.
>
> Just to make sure I'm not reading this with the wrong set of eyes.
>
> Is it correct that your main concern is currently the presentation of the brand,
> in particular its markings and mentions?
>
> Are there any objections to using the name "Apache uimaFIT"?
I think uimaFIT would need to be a top level project to have that name, but I
think it's best to run these by the trademarks@ folks.
>
> If so, would "Apache UIMA uimaFIT" be more appropriate?
That's quite a mouthful, but I think that's the "correct" way to say it (one
time); afterwards, I would use just uimaFIT.
Again, I think it would be good to ask trademarks@ about using just uimaFIT as a
trademark, itself, just to see what they say.
>
> Do you think the moniker "Apache (UIMA) uimaFIT" should be discussed with anybody else
> at the foundation?
Other than trademarks@, no. They are the designated people to have this
discussion with.
>
> Are there any further concerns that I should be particularly aware of or mind when
> reading these pages?
Only that we're required to follow and enforce these policies as PMC members :-).
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
Am 19.08.2013 um 21:37 schrieb Marshall Schor <ms...@schor.com>:
> On 8/19/2013 11:12 AM, Richard Eckart de Castilho wrote:
>> Am 19.08.2013 um 17:03 schrieb Marshall Schor <ms...@schor.com>:
>>
>>> trademark checking:
>>>
>>> The first use of the word UIMA in a significant document should be written with
>>> a preceeding "Apache" and a following ™ sign (that's the trademark sign).
>>> Subsequent uses can just write UIMA.
>>>
>>> A significant doc would be things like the docbook (it's missing).
>>>
>>> Has anyone talked to trademarks@ to see about the term uimaFIT?
>> Not explicitly. The IP clearance vote has been done on the incubator
>> list per workflow:
>>
>> Vote: http://markmail.org/message/xz5at7asrnkx4t2e
>> Result: http://markmail.org/thread/iarcwb7efs3mburu
>>
>> Are you suggesting that, possibly in the light of the renaming of Ruta,
>> a preemptive involvement of trademarks@ would be wise?
> nope. I'm referring to following these policies:
> http://www.apache.org/foundation/marks/pmcs.html
>
> The relevant sections (written for "web pages", but I think applies to other
> significant documentation):
>
> The first and most prominent reference to a project or product on each page must
> use the "Apache Foo" form of its name. Other references may use either "Apache
> Foo" or "Foo" as appropriate for the subject matter.
>
> At the top of each project or product homepage, and on the top banner of each
> page where the project name appears, you should include a "TM" symbol next to
> the *first* main occurrence of the "Apache Foo" project name. This highlights
> our trademark claim and emphasizes its importance to us.
>
> If you haven't already, please read this too:
> http://www.apache.org/foundation/marks/responsibility.html
Thanks for your comments. I wasn't aware this had not been sufficiently addressed
in the past, but I suppose it wasn't.
Just to make sure I'm not reading this with the wrong set of eyes.
Is it correct that your main concern is currently the presentation of the brand,
in particular its markings and mentions?
Are there any objections to using the name "Apache uimaFIT"?
If so, would "Apache UIMA uimaFIT" be more appropriate?
Do you think the moniker "Apache (UIMA) uimaFIT" should be discussed with anybody else
at the foundation?
Are there any further concerns that I should be particularly aware of or mind when
reading these pages?
-- Richard
> -Marshall
>
>> -- Richard
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
On 8/19/2013 11:12 AM, Richard Eckart de Castilho wrote:
> Am 19.08.2013 um 17:03 schrieb Marshall Schor <ms...@schor.com>:
>
>> trademark checking:
>>
>> The first use of the word UIMA in a significant document should be written with
>> a preceeding "Apache" and a following ™ sign (that's the trademark sign).
>> Subsequent uses can just write UIMA.
>>
>> A significant doc would be things like the docbook (it's missing).
>>
>> Has anyone talked to trademarks@ to see about the term uimaFIT?
> Not explicitly. The IP clearance vote has been done on the incubator
> list per workflow:
>
> Vote: http://markmail.org/message/xz5at7asrnkx4t2e
> Result: http://markmail.org/thread/iarcwb7efs3mburu
>
> Are you suggesting that, possibly in the light of the renaming of Ruta,
> a preemptive involvement of trademarks@ would be wise?
nope. I'm referring to following these policies:
http://www.apache.org/foundation/marks/pmcs.html
The relevant sections (written for "web pages", but I think applies to other
significant documentation):
The first and most prominent reference to a project or product on each page must
use the "Apache Foo" form of its name. Other references may use either "Apache
Foo" or "Foo" as appropriate for the subject matter.
At the top of each project or product homepage, and on the top banner of each
page where the project name appears, you should include a "TM" symbol next to
the *first* main occurrence of the "Apache Foo" project name. This highlights
our trademark claim and emphasizes its importance to us.
If you haven't already, please read this too:
http://www.apache.org/foundation/marks/responsibility.html
-Marshall
> -- Richard
>
>
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
Am 19.08.2013 um 17:03 schrieb Marshall Schor <ms...@schor.com>:
> trademark checking:
>
> The first use of the word UIMA in a significant document should be written with
> a preceeding "Apache" and a following ™ sign (that's the trademark sign).
> Subsequent uses can just write UIMA.
>
> A significant doc would be things like the docbook (it's missing).
>
> Has anyone talked to trademarks@ to see about the term uimaFIT?
Not explicitly. The IP clearance vote has been done on the incubator
list per workflow:
Vote: http://markmail.org/message/xz5at7asrnkx4t2e
Result: http://markmail.org/thread/iarcwb7efs3mburu
Are you suggesting that, possibly in the light of the renaming of Ruta,
a preemptive involvement of trademarks@ would be wise?
-- Richard
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
trademark checking:
The first use of the word UIMA in a significant document should be written with
a preceeding "Apache" and a following ™ sign (that's the trademark sign).
Subsequent uses can just write UIMA.
A significant doc would be things like the docbook (it's missing).
Has anyone talked to trademarks@ to see about the term uimaFIT?
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
On 8/24/2013 5:11 PM, Richard Eckart de Castilho wrote:
> Am 19.08.2013 um 17:00 schrieb Marshall Schor <ms...@schor.com>:
>
>> Also, pdf formatting seems off for literals included in section headers - the
>> font is too small.
> I'm removing the fixed-width font references. This would need to be fixed somewhere
> in the overall docbook style.
>
>> The publication date is missing on pg 2 (I notice this has gone missing in the
>> uima-sdk 2.4.2 too)
> The respective UIMA helper plugin doesn't seem to get called anymore and when I copy it
> explicitly to the uimaFIT POM, it triggers an exception about not being able to convert
> an Object into a Date within the plugin. Working around this by using the
> buildnumber-maven-plugin from codehaus as an alternative.
debugged - was 2 errors. I'll put up a jira...
-Marshall
>
> -- Richard
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
Am 19.08.2013 um 17:00 schrieb Marshall Schor <ms...@schor.com>:
> Also, pdf formatting seems off for literals included in section headers - the
> font is too small.
I'm removing the fixed-width font references. This would need to be fixed somewhere
in the overall docbook style.
> The publication date is missing on pg 2 (I notice this has gone missing in the
> uima-sdk 2.4.2 too)
The respective UIMA helper plugin doesn't seem to get called anymore and when I copy it
explicitly to the uimaFIT POM, it triggers an exception about not being able to convert
an Object into a Date within the plugin. Working around this by using the
buildnumber-maven-plugin from codehaus as an alternative.
-- Richard
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
minor pdf formatting issue - program listing lines too long:
pg: 9, 14, 19, 20, 30, 31,
Also, pdf formatting seems off for literals included in section headers - the
font is too small.
The publication date is missing on pg 2 (I notice this has gone missing in the
uima-sdk 2.4.2 too)
(not blockers, I think).
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
README has the wrong "group-id" for maven for uimaFIT
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2 - partial inclusion of uimaj
sdk
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 19.08.2013 18:17, schrieb Richard Eckart de Castilho:
> I have wondered for some time if a binary release makes sense for uimaFIT at all.
> uimaFIT 1.4.x included a binary release as convenience for those people that do
> not use Maven. The idea was to provide them with all the libraries that uimaFIT
> needs to run, so they do not have to chase them down on the web. The purpose
> of the uimaFIT binary release is therefore quite different from that of the
> UIMA SDK or of UIMA-AS. uimaFIT is a (set of) libraries, not an application
> or tool.
>
> A note in the README is easily added. But I would not want to add more from
> the standard UIMA SDK release. Rather, I'd completely forego the binary release
> and just distribute uimaFIT via Maven. After all, there doesn't seem to be a
> binary release or zipped update site for Ruta either.
I am waiting until someone complains. If nobody needs binary release,
there won't be one.
Peter
> Personally, I don't really need the binary release. I just wanted to keep it
> because looking at the download numbers on Google Code, people apparently
> used it.
>
> -- Richard
>
> Am 19.08.2013 um 17:52 schrieb Marshall Schor <ms...@schor.com>:
>
>> The uimaFIT binary packaging has some, but not all, of the uimaj sdk jars,
>> included. (jars not included are: uima-adapter-soap, uima-document-annotation,
>> uima-examples, uimaj-bootstrap (used by the uimaj launching scripts), and
>> uima-tools (includes the CVD, document analyzer, etc.). Other things missing
>> include the "config" directory (has the standard logging configurations), the
>> scripts in the bin directory, and eclipse plugins (for those who aren't using
>> the Eclipse Install mechanism)
>>
>> I think this partial inclusion of some of the uimaj sdk jars has the potential
>> to confuse a new user of uimaFIT, who may think it comes bundled with UIMA Java
>> SDK. I think a short description of this should be in the README, or
>> preferably, either include all of uimaj sdk, or none of it.
>>
>> -Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2 - partial inclusion of uimaj sdk
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
I have wondered for some time if a binary release makes sense for uimaFIT at all.
uimaFIT 1.4.x included a binary release as convenience for those people that do
not use Maven. The idea was to provide them with all the libraries that uimaFIT
needs to run, so they do not have to chase them down on the web. The purpose
of the uimaFIT binary release is therefore quite different from that of the
UIMA SDK or of UIMA-AS. uimaFIT is a (set of) libraries, not an application
or tool.
A note in the README is easily added. But I would not want to add more from
the standard UIMA SDK release. Rather, I'd completely forego the binary release
and just distribute uimaFIT via Maven. After all, there doesn't seem to be a
binary release or zipped update site for Ruta either.
Personally, I don't really need the binary release. I just wanted to keep it
because looking at the download numbers on Google Code, people apparently
used it.
-- Richard
Am 19.08.2013 um 17:52 schrieb Marshall Schor <ms...@schor.com>:
> The uimaFIT binary packaging has some, but not all, of the uimaj sdk jars,
> included. (jars not included are: uima-adapter-soap, uima-document-annotation,
> uima-examples, uimaj-bootstrap (used by the uimaj launching scripts), and
> uima-tools (includes the CVD, document analyzer, etc.). Other things missing
> include the "config" directory (has the standard logging configurations), the
> scripts in the bin directory, and eclipse plugins (for those who aren't using
> the Eclipse Install mechanism)
>
> I think this partial inclusion of some of the uimaj sdk jars has the potential
> to confuse a new user of uimaFIT, who may think it comes bundled with UIMA Java
> SDK. I think a short description of this should be in the README, or
> preferably, either include all of uimaj sdk, or none of it.
>
> -Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2 - partial inclusion of uimaj sdk
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
I added a note to the README file:
uimaFIT is a part of the Apache UIMA(TM) project. uimaFIT can only be used in conjunction with
a compatible version of the Java version of the Apache UIMA SDK. For your convenience, the binary
distribution package of uimaFIT includes all libraries necessary to use uimaFIT. In particular for
novice users, it is strongly advised to obtain a copy of the full UIMA SDK separately.
-- Richard
Am 19.08.2013 um 17:52 schrieb Marshall Schor <ms...@schor.com>:
> The uimaFIT binary packaging has some, but not all, of the uimaj sdk jars,
> included. (jars not included are: uima-adapter-soap, uima-document-annotation,
> uima-examples, uimaj-bootstrap (used by the uimaj launching scripts), and
> uima-tools (includes the CVD, document analyzer, etc.). Other things missing
> include the "config" directory (has the standard logging configurations), the
> scripts in the bin directory, and eclipse plugins (for those who aren't using
> the Eclipse Install mechanism)
>
> I think this partial inclusion of some of the uimaj sdk jars has the potential
> to confuse a new user of uimaFIT, who may think it comes bundled with UIMA Java
> SDK. I think a short description of this should be in the README, or
> preferably, either include all of uimaj sdk, or none of it.
>
> -Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2 - partial inclusion of uimaj
sdk
Posted by Marshall Schor <ms...@schor.com>.
The uimaFIT binary packaging has some, but not all, of the uimaj sdk jars,
included. (jars not included are: uima-adapter-soap, uima-document-annotation,
uima-examples, uimaj-bootstrap (used by the uimaj launching scripts), and
uima-tools (includes the CVD, document analyzer, etc.). Other things missing
include the "config" directory (has the standard logging configurations), the
scripts in the bin directory, and eclipse plugins (for those who aren't using
the Eclipse Install mechanism)
I think this partial inclusion of some of the uimaj sdk jars has the potential
to confuse a new user of uimaFIT, who may think it comes bundled with UIMA Java
SDK. I think a short description of this should be in the README, or
preferably, either include all of uimaj sdk, or none of it.
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
suspicious: There are 2 files in uimafit-core, in src/test/resources/data, one
called unix-newlines.txt and the other called windows-newlines.txt.
Both of these files have the svn flag eol-style:native set.
If these are meant to be tests for different kinds of newlines, that makes these
fail. The source-release.zip has copies of these with the same newlines
(because the source release was built from an svn checkout).
(assuming this needs fixing:) While fixing this, please see if there are any
other test data where the kind of new line is important, and fix those too.
-Marshall
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
- Cleared Maven repo fully
- Downloaded source zip
- Builds ok
- Cleared Maven repo fully
- Checked out tag
- Built
- source and binary archives appear ok. LICENSE and NOTICE are in place
- The examples folder is for information only - it's not really meant to be buildable or something atm. This should be improved in the future.
[X] +1 OK to release
- Richard
Am 18.08.2013 um 19:24 schrieb Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>:
> Hi,
>
> I've posted uimaFIT 2.0.0 rc2. There were 85 Jiras fixed, see
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
>
> The source and binary zip/tars are staged to
> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc2/
> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc2/>
>
> The Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapacheuima-104/org/apache/uima/
>
> The SVN tags are here:
> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc2
>
> See http://uima.apache.org/testing-builds.html for suggestions on how to test
> release candidates.
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because …
>
> This RC incorporates the comments from Marshal (thanks!) on RC1 as well as some issues that meanwhile had cropped up.
>
> Thanks.
>
> -- Richard
>
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
Am 19.08.2013 um 23:23 schrieb Marshall Schor <ms...@schor.com>:
> (curiosity question)
>
> In the source tree, I see files / directories in src/test/resources/data/html,
> some with names like "2", or "4", and some with empty directories, etc.
>
> Are all the resources in test being used, and if not, perhaps they could be
> deleted (or moved to some archive spot, etc.)?
Thanks for noticing. They were not used. I just deleted them.
The remaining resources look sane.
Cheers,
-- Richard
Re: [VOTE] Release uimaFIT 2.0.0 rc2
Posted by Marshall Schor <ms...@schor.com>.
(curiosity question)
In the source tree, I see files / directories in src/test/resources/data/html,
some with names like "2", or "4", and some with empty directories, etc.
Are all the resources in test being used, and if not, perhaps they could be
deleted (or moved to some archive spot, etc.)?
-Marshall