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 13:36:47 GMT
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