uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Date Tue, 07 Jul 2015 19:38:31 GMT
I think Burn has found a significant issue.  I'll probably cancel this vote. 
I've started another thread to discuss it.

-Marshall

On 7/7/2015 3:10 PM, Burn Lewis wrote:
> So since this is not a critical API change we don't have to update the
> major version number :)
> I'll see how much of our code it affects.
>
> Burn.
>
> On Tue, Jul 7, 2015 at 10:14 AM, Marshall Schor <msa@schor.com> wrote:
>
>> This was changed on purpose to make things more consumable; see the comment
>> chain toward the bottom of Jira
>> https://issues.apache.org/jira/browse/UIMA-4299
>>
>> It looks like this would affect cases where <TOP> was used.
>>
>> Although I at first thought that TOP would be better, it cannot be used
>> because
>> of the meaning of get-*all*-indexed-fs - some of the Feature Structures
>> returned
>> may not be JCas style cover classes - in case there was no JCas class
>> defined
>> for those types.  So it has to be the more general FeatureStructure.
>>
>> For example, if it was of type TOP, then you could use a method on this
>> which
>> exists only for TOP and not for FeatureStructure (e.g.,
>> myTopInstance.addToIndexes()).
>>
>> Is this a blocker?  I agree it needs to be documented, and if it's not a
>> blocker, it can be documented:
>> a) in the announcement
>> b) in the web-site version of the RELEASE_NOTES
>>
>> If it is a blocker, we'll document it in the manual, and the RELEASE_NOTES.
>>
>> By itself, I would tend to view this as not a blocker.
>>
>> -Marshall
>>
>> On 7/7/2015 9:39 AM, Richard Eckart de Castilho wrote:
>>> Looks like the static byte-code analysis done by the Semantic Versioning
>> plug-in
>>> doesn't catch that :/
>>>
>>> So I guess, we have a binary-compatible change that is not
>> source-compatible.
>>> -- Richard
>>>
>>> On 07.07.2015, at 15:36, Burn Lewis <burnlewis@gmail.com> wrote:
>>>
>>>> The release notes say no API changes, but the return type of
>>>> org.apache.uima.jcas.getAllIndexedFS has changed from  FSIterator<TOP>
>> to
>>>> FSIterator<FeatureStructure> which has produced a compile error in
our
>> code.
>>>> On Mon, Jul 6, 2015 at 3:57 PM, Marshall Schor <msa@schor.com> wrote:
>>>>
>>>>> thanks, again :-) .
>>>>>
>>>>> I remember that the lib folder jar names were debated 6-7 years ago.
>> The
>>>>> debate
>>>>> centered more around whether or not to adopt the standard of how these
>>>>> jars are
>>>>> named in the Maven artifact repository.
>>>>>   e.g.
>>>>>   maven repo: uimaj-core-2.7.0.jar
>>>>>   lib:        uima-core.jar
>>>>>
>>>>> Not only is the "j" different, but the maven repo has the version
>> appended.
>>>>> Also, https://issues.apache.org/jira/browse/UIMA-355 has some
>> comments on
>>>>> renaming.
>>>>>
>>>>> You can find this discussion in the mail archives.  For instance,
>> search
>>>>> uima.markmail.org with the keywords:
>>>>>   naming uima-core uima-355
>>>>>
>>>>> The bottom line for me sort of nets out to the following:
>>>>>
>>>>>  1) Renaming the Jars to follow the Maven names would make things more
>>>>> consistent
>>>>>  2) Renaming the Jars to follow the Maven names would somewhat impact
>> our
>>>>> users
>>>>> (who might be hard-coding the jar name, which for now, doesn't change
>> in
>>>>> the
>>>>> lib/ dir of the binary distribution).
>>>>>
>>>>> When I weight these two reasons, I feel it's more important not to
>> impact
>>>>> our
>>>>> users, given the benefit is only one of some consistency.
>>>>> But if there were no impact to the users, I would be fine with changing
>>>>> this.
>>>>>
>>>>> -Marshall
>>>>>
>>>>>
>>>>>
>>>>> On 7/6/2015 12:52 PM, Richard Eckart de Castilho wrote:
>>>>>> Reason for the missing issuesFixed was that I was looking at a locally
>>>>> built
>>>>>> version (without -Papache-release) at that moment.
>>>>>>
>>>>>> Re-did spot check of licenses/notices against the ZIP you provided
-
>>>>> still
>>>>>> looks all ok and the issuesFixed is there.
>>>>>>
>>>>>> So I maintain the +1.
>>>>>>
>>>>>> Btw. I think I pointed this out in the past: why not switch from
the
>>>>>> "uima-XXX" naming to the proper "uimaj-XXX" naming in the lib folder?
>>>>>> The files identify themselves as "uimaj-XXX" in their NOTICE files.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> -- Richard
>>>>>>
>>>>>> On 06.07.2015, at 16:50, Marshall Schor <msa@schor.com> wrote:
>>>>>>
>>>>>>> Thanks for the quick vote!
>>>>>>>
>>>>>>> On the point about the link to "issues fixed" in RELEASE_NOTES.html
>> of
>>>>> the zip
>>>>>>> distribution - I cannot reproduce this.
>>>>>>> I tried unzipping the uimaj-2.8.0-bin.zip, then opening
>>>>> RELEASE_NOTES.html, then
>>>>>>> clicking on the table-of-contents link " List of JIRA Issues
Fixed in
>>>>> this
>>>>>>> Release", and then clicked on "issuesFixed/jira-report.hmtl"
under
>> the
>>>>> heading
>>>>>>> "Full list of JIRA Issues Fixed in this Release".
>>>>>>>
>>>>>>> I also tried the same thing unzipping the
>>>>> uimaj-2.8.0-source-release.zip.  Both
>>>>>>> worked OK for me.
>>>>>>>
>>>>>>> Can you say more precisely what failed? The zips both included
a
>>>>> directory
>>>>>>> "issuesFixed", and within that, the file "jira-report.html".
(My test
>>>>> was on
>>>>>>> Windows).
>>>>>>>
>>>>>>> -Marshall
>>>>>>>
>>>>>>> On 7/5/2015 5:10 PM, Richard Eckart de Castilho wrote:
>>>>>>>> Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
>>>>>>>>
>>>>>>>> Spot check for licenses and notices - OK
>>>>>>>>
>>>>>>>> Built Apache uimaFIT trunk against this RC - OK
>>>>>>>>
>>>>>>>> Built other software against this RC - OK
>>>>>>>>
>>>>>>>> Spot check signatures - look OK (still need to get into the
web of
>>>>> trust...)
>>>>>>>> [X] +1 OK to release
>>>>>>>>
>>>>>>>>
>>>>>>>> Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution
>> does
>>>>> not work. Shouldn't there be such a file in the ZIP? - Not critical,
>> but
>>>>> should be fixed in next release.
>>>>>>>> Btw. we have many issues that were marked as "resolved" or
"closed"
>>>>> but that do not have an assignee:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
>>>>>>>> I fixed the assignee on those issues that I had initially
reported.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> -- Richard
>>>>>>>>
>>>>>>>> On 04.07.2015, at 20:49, Marshall Schor <msa@schor.com>
wrote:
>>>>>>>>
>>>>>>>>> signatures - OK
>>>>>>>>>
>>>>>>>>> Source compare with tag: OK
>>>>>>>>>
>>>>>>>>> Install into Eclipse Luna: OK; tested by running the
Component
>>>>> Descriptor Editor
>>>>>>>>> Build from sources - OK (needs Java 7, not 8 due to javadoc
issues
>> -
>>>>> not a blocker)
>>>>>>>>> Issues Fixed - OK
>>>>>>>>>
>>>>>>>>> spot checked licenses and notices - OK
>>>>>>>>>
>>>>>>>>> from binary distribution, ran adjust example paths, and
document
>>>>> analyzer, and
>>>>>>>>> Java results viewer (showing new Features view) - OK
>>>>>>>>>
>>>>>>>>> [X] +1 OK to release
>>>>>>>>>
>>>>>>>>> -Marshall Schor
>>


Mime
View raw message