Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Road to Final Draft
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Road to Final Draft
- Date: Sun, 3 Apr 2016 14:55:55 +0200
Here's the JIRA:
https://java.net/jira/browse/UNITSOFMEASUREMENT-191
Werner
On Sun, Apr 3, 2016 at 2:49 PM, Werner Keil
<
>
wrote:
>
Dear Experts,
>
>
Please have a look at most recent JavaDoc reflecting the SPI
>
simplification:
>
http://unitsofmeasurement.github.io/unit-api/site/apidocs/index.html
>
>
The Spec is also updated where necessary. A few TCK tests missing
>
primarily for the new role of ServiceProvider, otherwise the TCK was very
>
complete after Almas' contribution.
>
>
There is one place where the SPI could be trimmed a bit more. Will create
>
a sub-task under what's now a story called "Refactoring SPI"
>
https://java.net/jira/browse/UNITSOFMEASUREMENT-152
>
>
QuantityFactoryService so far only provides a single call
>
getQuantityFactory() for a given quantity. There is no reason against
>
merging that into ServiceProvider, so that getQuantityFactory(Class) can be
>
called there instead of returning a QuantityFactoryService only to offer
>
that single method once again.
>
>
Will create the sub-task, please check it out and reply or comment there.
>
I don't think a Doodle was necessary. It helped with a slightly larger
>
structural change, smaller things even reducing another class or two should
>
work on JIRA or GitHub, too.
>
>
Kind Regards,
>
Werner
>
>
>
On Thu, Mar 31, 2016 at 12:55 AM, Martin Desruisseaux <
>
>
>
wrote:
>
>
> Thanks Werner for testing on RI and reporting!
>
>
>
> I just created the pull request.
>
>
>
> Martin
>
>
>
>
>
> Le 31/03/16 00:37, Werner Keil a écrit :
>
> > Martin/all,
>
> >
>
> > Happy to share, the PoC/proposal generally works rather well as far as
>
> > RI+SI modules are concerned.
>
> > All tests applied are green in https://github.com/keilw/si-units.
>
> >
>
> > It is possible and right now, the RI discovers its individual services
>
> > via java.util.ServiceLoader, but each module that either extends the
>
> > ServiceLoader provided by an implementation or the API itself is free
>
> > to use whatever it likes to discover or instanciate those services.
>
> > OSGi, a DI framework like Spring or CDI (probably more on SE/EE) or
>
> > simply return new MySystemOfUnitService() to take an example.
>
> >
>
> > Thanks a lot Martin for your useful "Easter Egg". Would you please
>
> > create a PR for the API project based on your fork.
>
> > Referring either to
>
> > https://java.net/jira/browse/UNITSOFMEASUREMENT-190
>
> > or its parent story so we know what it's based on.
>
> >
>
> > After review, any of the Spec Leads should be able to merge the PR
>
> > back into master.
>
> > As our CI system does not automatically trigger downstream builds, the
>
> > important part is, that unit-api master remains green after the merge.
>
> > Combining an interface with an abstract base class may not have a huge
>
> > effect on API code coverage. If ServiceProviderTest covers more lines
>
> > of ServiceProvider now, it might even go up a bit. The more the
>
> > better, as long as we stay above the 60-65% it was before.
>
> >
>
> > Will do the same with the forks of RI and SI module.
>
> > Then uom-se should also be adjusted as well as relevant modules.
>
> >
>
> > I created a branch to the TCK as the only module so far. CI also runs
>
> > off the master, but a branch
>
> > called
>
> https://github.com/unitsofmeasurement/unit-tck/tree/simplified_ServiceProvider
>
> > exists now based on the new structure. As soon as all snapshot builds
>
> > were refreshed, this branch can also be merged back into master. It
>
> > builds locally and all TCK tests pass.
>
> >
>
> > Thanks and Regards,
>
> > Werner
>
> >
>
>
>
>
>