Consider moving Top-Level Types or Package name

[gablans]

Consider moving Top-Level Types or Package name

[GoogleCodeExporter]

Original comment by [email protected] on 21 Aug 2010 at 5:52

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This is mirrored by UCUM Trac here:
http://www.unitsofmeasure.org/ticket/53

As I used it recently, a good example for an "API" package is Concordion:
http://www.jarvana.com/jarvana/view/org/concordion/concordion/1.3.1/concordion-1
.3.1-javadoc.jar!/org/concordion/api/package-summary.html

Original comment by [email protected] on 21 Aug 2010 at 6:39

• Added labels: Priority-Medium

[GoogleCodeExporter]

I would prefer to avoid the "api" sub-package since API is the whole purpose of 
"org.unitsofmeasure".

Is the following acceptable?

1) Provide only two packages: "org.unitsofmeasure.unit" and 
"org.unitsofmeasure.quantity". All other packages (including 
"org.unitsofmeasure") will disaspear after the points below.

2) Move the Quantity interface to "org.unitsofmeasure.quantity".

3) Move all the remaining of "org.unitsofmeasure" to "org.unitsofmeasure.unit".

4) Move all of "org.unitsofmeasure.util" to "org.unitsofmeasure.unit".

Original comment by [email protected] on 22 Aug 2010 at 8:41

[GoogleCodeExporter]

Regardless of above refactoring (which we're still free to undertake) UCUM 
feels uncomfortable with having them in the top level package, too.

I replied to Gunther, hoping to clarify, it's not an "Implementation" but the 
"Spec" this is about (his suggestion calling the package "jscience" was 
well-meant, but unacceptable, as it would destroy all standardization efforts 
since 2005 and would just put it back to org.jscience) 

Nevertheless, we probably have to face introducing a sub-level like "api", 
"spec" or whatever makes sense? The shorter the better. Since JScience is only 
one of 3+ implementations (not the RI unless we go JSR again some day) the name 
should be neutral and not be mixed with an implementation.

Original comment by [email protected] on 23 Aug 2010 at 1:04

[GoogleCodeExporter]

I'm with Martin: I am not keen on having 'api/spec' as a package name. The 
whole module/bundle is an API bundle (no implementation); so there is no 
"non-API" package to differentiate it from.

I can see the domain owner's point though in wanting to reserve the top level 
domain and give us a single root package.

But I can't think of anything better than 'api', so under the circumstances 
this may be the best option? I certainly prefer it to 'spec'.

If we do introduce this 'api' package, my preference would be to leave the 
subpackage content exactly like it is now (e.g. org.unitsofmeasure.api.Unit, 
org.unitsofmeasure.api.quantity.Length etc.).

Original comment by christopher.senior on 25 Aug 2010 at 9:57

[GoogleCodeExporter]

Thanks for the update. Gunther hasn't come back to us on that, so we could if 
we all agree, the "unit" + "quantity" structure is also best, start doing that.

One caveat regarding Martin's earlier suggestions is, that OSGi (pretty 
mandatory, not only Eclipse or UOMo uses it now, both Apache and Oracle are 
also very into it) naming won't allow version numbers under 3 digits. So for a 
next release it should be "0.5.3".
Any "SNAPSHOT", "DEV" or similar "DAILY" / "NIGHTLY" build must therefore be 
put after 3 digits. We can't have "0.5.SNAPSHOT". And even anticipating 0.6 
would require a "0.6.0.SNAPSHOT" format.

Just wrapping up the domain question, Gunther and UCUM's point is similar to 
let's say us plunging "org.eclipse.unit" and "org.eclipse.quantity" into the 
Eclipse ecosystem. Eclipse would never allow that, and even in javax.* there 
are very few JSRs with more than one "top-level" javax.* package name either. 
CDI seems among the few. Some who declare annotations do this in a pre-defined 
package, all others usually have one, also under javax.

Original comment by [email protected] on 27 Aug 2010 at 10:28

[GoogleCodeExporter]

Original comment by [email protected] on 12 Sep 2010 at 12:03

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by [email protected] on 12 Sep 2010 at 12:03

• Changed state: Fixed