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: Thu, 31 Mar 2016 00:37:25 +0200
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