[geotk] JSR-275 (Units of measurement) rejected by the JCP

[Martin Desruisseaux]

Hello all

GeoAPI (and consequently Geotoolkit.org / GeoTools) has one dependency: the 
javax.measure.unit.Unit class defined by JSR-275. JSR-275 has been submitted 
twice for vote to the Java Community Process (JCP) board. The first proposal has 
been rejected for good technical raisons (in my opinion - I was in agreement 
with many of the comments posted by the reviewers). The second proposal was 
considered a significant improvement but still has been rejected. Some JCP 
members wish so see JSR-275 continuing its effort, but it is not clear that we 
are allowed to according JCP procedures.

The JSR-275 leader (which is also a member of the JCP board) considers that 
JSR-275 is terminated (dead) and suggests to move to 
http://www.unitsofmeasure.org (which define UCUM and would apparently be happy 
to host the ex-JSR-275 library). On the other hand, the library implementor 
wishes to move the unit library back to JScience (its original location), as a 
standalone module.

I would like to know what peoples on this list prefer. We need to take a 
decision relatively fast, since the GeoAPI 3.0 specification is already 
submitted to the OGC Architecture Board (this is the step before the 60 days 
public review period). Possible actions are:

1) Continue JSR-275 or start a new JSR (it would be the third one) so we can
    keep the "javax.measure" namespace, but we will need new team of volunters.
    The JCP will probably not accept a new JSR with a team made only of the old
    members.

2) Move the unit library to the http://www.unitsofmeasure.org project. The
    "javax.measure" package name would be renamed as "org.unitsofmeasure".
    This is maybe the closest we can get to a "standard" organisation
    dedicaced to Units.

3) Let the unit library moves back to its original location, JScience. The
    "javax.measure" package name would be renamed as "org.jscience.measure".
    However if we follow that path, GeoAPI will depends on a particular Unit
    implementation, defined by an external project. This is a bit against
    the goal to give implementation freedom.

4) Define our own Unit interface. However it would make more difficult
    to leverage existing libraries like JScience or unitsofmeasure.org,
    since those libraries will not implement our Unit interface.

Any input would be highly appreciated, preferrably in the comming week...

	Best regards,

		Martin