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