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


[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