Skip to main content

[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:49:31 +0200

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
> >
>
>


[jsr363-experts] Re: Road to Final Draft

Werner Keil 04/03/2016

[jsr363-experts] Re: Road to Final Draft

Werner Keil 04/03/2016
 
 
Close
loading
Please Confirm
Close