uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burn Lewis <burnle...@gmail.com>
Subject Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Date Tue, 07 Jul 2015 19:10:21 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message