gablans/unitsofmeasure

Automatically exported from code.google.com/p/unitsofmeasure

unitsofmeasure's Issues

Unit should declare a toString() method

The Javadoc of the Unit interface explicitly mentions a toString() method in 
"for example, the string {@code "g/kg"} would result from invoking the method 
toString() on a unit that was created by dividing a gram unit by a kilogram 
unit", but that toString() method is not defined.

The proposal is to explicitly add a toString() method in the Unit interface 
with a specification consistent with the interface Javadoc, and add a link from 
the getSymbol() method to that toString() method so that users know they have 
an alternative when getSymbol() returns null.

This is a compatible change, because implementation of the Unit interface 
inherit the toString() method from Object anyway. The only difference is that 
the behaviour of that method would now be better specified.

Original issue reported on code.google.com by [email protected] on 8 Jan 2013 at 2:55

Explore support for JSR-308

Look at JSR-308 Checkers for Unit-API

Original issue reported on code.google.com by [email protected] on 14 Sep 2011 at 6:00

Should Unit.alternate return type be Unit<Q>?

The alternate() method defined in the Unit interface currently returns Unit<?>. 
It seems to be that it should return Unit<Q> since changing the unit symbol 
should not change the kind of quantity measured by the Unit.

Or, if the quantity type is unrestricted in order to allow switching from 
Energy to Torque (for example), this this should be explained in the javadoc.

Original issue reported on code.google.com by [email protected] on 8 Jan 2013 at 5:01

Consider renaming RadioactiveActivity as RadioActivity

The RadioactiveActivity quantity seems to be a long name for RadioActivity. 
Should it be renamed?

Original issue reported on code.google.com by [email protected] on 8 Jan 2013 at 4:50

Replace AmountOfSubstance with Substance

Given both major implementations (JScience and UOMo) use the term "Amount" for 
actual classes I decided to clone this quantity simply calling it "Substance". 
TODO suggests alternative names, please comment here if you have any additional.

The old interface is there, but @deprecated. Should be eliminated from the API 
as soon as possible, ideally 0.5.3

Original issue reported on code.google.com by [email protected] on 11 Aug 2010 at 10:20

Add missing standard constructors in unit exceptions

Exceptions in Java typically have the following constructors:

Exception(String message);
Exception(Throwable cause);
Exception(String message, Throwable cause);

Some of those constructors are missing in IncommensurableException and 
UnconvertibleException.

Original issue reported on code.google.com by [email protected] on 8 Jan 2013 at 3:24

Add method getSystemsOfUnits to SystemOfUnitsService

The SystemOfUnitsService has a default method and a method to get a single 
system by name, but it should be able to return a collection of ALL known unit 
systems.

A getSystemsOfUnits() method (at least Collection, or could be a Set)
method to be added to SystemOfUnitsService.

Optionally the getSystemOfUnits() method could be renamed to 
getDefaultSystemOfUnits(), if desired.

Original issue reported on code.google.com by [email protected] on 1 Jan 2013 at 7:35

Add methods to Quantity

See thread: https://groups.google.com/d/msg/units-dev/XVwFwzFJEn8/jgpTzbTB25gJ

Original issue reported on code.google.com by [email protected] on 27 Oct 2011 at 8:31

Refactoring

Refactoring based on new package structure

Original issue reported on code.google.com by [email protected] on 13 Sep 2010 at 7:25

UnitFormat.parse(...) should throws ParseException

Despite using some object from java.text package, in particular ParsePosition, 
the UnitFormat.parse(...) method is currently declared to throws 
IllegalArgumentException rather than ParseException. I think it should throws 
ParseException instead for consistency with the java.text package.

Original issue reported on code.google.com by [email protected] on 8 Jan 2013 at 5:04

Consider moving Top-Level Types or Package name

After a conversation with Gunther from UCUM, he remarked the following we 
should take into consideration while 'tenants' in their namespace.

I would want to make sure though that you are not all over the place on 
org.unitsofmeasure
[19:03:34] Gunther Schadow: ideally you have one root under org.unitsofmeasure, 
e.g., org.unitsofmeasure.foobar

Currently I see 2 options:
a) move all that's in package org.unitsofmeasure including sub-packages to e.g. 
"org.unitsofmeasure.api" (which would meet the OSGi ID)
b) if this was too drastic and existing packages "quantity" and "util" 
acceptable, find at least a third one like "unit" similar to earlier JSR-275 
structure

Please advise by commenting here or email. Potentially this may take effect for 
v 0.5.3 or any following release where this is acceptable to using parties.

Original issue reported on code.google.com by [email protected] on 21 Aug 2010 at 5:49

Correct example code sections in JavaDoc

The official JavaDoc (http://www.unitsofmeasurement.org/apidocs/index.html) 
contains many sections of example code. These are not rendered correctly by 
JavaDoc in the API.

For example:

http://www.unitsofmeasurement.org/apidocs/org/unitsofmeasurement/unit/Unit.html#
getSystemUnit()

This is because the Java source uses Wiki style [code] [/code] tags rather than 
the official @code annotation.

(For example - 
http://stackoverflow.com/questions/541920/multiple-line-code-example-in-javadoc-
comment)

Original issue reported on code.google.com by christopher.senior on 29 Oct 2010 at 4:34

Move our code repo to Git from SVN

Hi Everyone,

Can I propose migrating this project from SVN to Git. The experience 
(particularly branching and working on planes) is much more pleasant.

I am happy to do the work, as described here: 
http://code.google.com/p/support/wiki/ConvertingSvnToGit

Original issue reported on code.google.com by christopher.senior on 30 Apr 2012 at 10:54

Unit.add method should be renamed "shift"

The "add" method name usually add something to a quantity. "Adding a value" 
doesn't make much sense to a coordinate system or a scale (we can "shift" a 
scale, but we usually don't said that we "add" something to a scale).

But in the current Unit API, the Unit.add(double) method is used for shifting 
the scale of measurement represented by the Unit object. While some may view 
Unit as a special kind of Quantity, if it was the case the "add" method would 
expect an argument value of opposite sign than the current JScience and UOMo 
behaviour. So the existing implementations in practice really behave like a 
"shift" operations, not "add". We should rename the method accordingly.

Original issue reported on code.google.com by [email protected] on 26 Jan 2013 at 6:59

Further document Implementations in Maven

Adding new implementations to Maven documentation

Original issue reported on code.google.com by [email protected] on 30 Apr 2011 at 3:56

Enhance tests

Add further unit tests and extend existing

Original issue reported on code.google.com by [email protected] on 2 Aug 2010 at 10:14

Graduate 0.6 Release

Based on the relatively stable 0.6 RC2 API and demand by Eclipse Foundation for 
inclusion via its Orbit repository, I intend to graduate Release 0.6 from 
Release Candidate.

Please comment here ASAP if you see any problems with it.

As Eclipse IP issue https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5260 
depends on this, I plan to close this as soon as I can.

Original issue reported on code.google.com by [email protected] on 5 Jun 2011 at 10:11

• Blocking: #6

Remove UnsupportedException from asType(Class) javadoc

The Unit.asType(Class) method is designed to throw ClassCastException if the 
unit can not be casted to a unit of the given quantity class. However the 
Javadoc additionally said "throws UnsupportedOperationException if the given 
type is not recognized". If the type is not recognized, the method can 
obviously not cast to that type, so the ClassCastException should be 
sufficient. Consequently I suggest to remove that sentence from Javadoc.

Original issue reported on code.google.com by [email protected] on 8 Jan 2013 at 2:41

Improve Documentation

Review and where required improvement of documentation.
Mostly Maven-generated, where applicable, the Wiki may also be updated.

Original issue reported on code.google.com by [email protected] on 1 Nov 2011 at 12:37

Attach source jars to build

It would be nice to get source jars (and possibly javadoc jars) included in the 
builds on whichever repository is designated as official (currently 
maven.geotoolkit.org).

See 
http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifac
ts.html.

Original issue reported on code.google.com by [email protected] on 8 Jun 2013 at 4:25

UCUM links in JavaDoc are outdated

Some JavaDoc referring to UCUM still points to an older "aurora" domain. This 
is no longer online, should be changed to new "unitsofmeasure.org" domain for 
UCUM/Regenstrief

Original issue reported on code.google.com by [email protected] on 18 Oct 2013 at 11:08

Check artifactId

Verify artifactId of the project. With respect to other OSGi and Eclipse 
projects like Gemini

Original issue reported on code.google.com by [email protected] on 30 Jul 2010 at 5:30

Change of Dimension breaks implementations

Unfortunately, the statement: "This should not have any impact on existing 
code."
in
>Use <? extends ...> for parameters of collections being returned; otherwise 
>more specialized collections cannot be returned by implementing classes. 
>Tthis should not have any impact on existing code.

hasn't quite applied.

At least 2 previously fine codes in the UOMo implementation require a recast 
to: Map<Unit<?>, Integer> productUnits.

Maybe rewriting that could relieve from such casts, but the original code 
worked fine until the interface changed.

Original issue reported on code.google.com by [email protected] on 13 Oct 2010 at 2:36

Deployment to Maven Repo?

Hi guys,

is there a Maven repo out there containing unitsofmeasure? If not, could it be 
possible to upload the artifacts?

Original issue reported on code.google.com by [email protected] on 25 Sep 2010 at 2:21

• Blocked on: #11

Link API javadocs from the homepage

Before using or even downloading this jar, the first thing I 'd like to check 
is the API, to see if it's of a decent quality. Since I can't check that, I 
presume the worse and don't download it :(

Original issue reported on code.google.com by [email protected] on 24 Apr 2012 at 7:29

IncommensurableException should be a checked exception

In JSR-275, the exception throw by Unit.getConverterToAny(Unit<?>) was a 
checked exception, at the opposite of Unit.getConverterTo(Unit<Q>). This 
checked exception was considered an important safety feature, and one reason 
for having two methods ("getConverterTo", "getConverterToAny"): one is safe, 
the other is not safe and the checked exception make that clear.

However in the unitofmeasurement.org API, the exception has been made 
unchecked. It should be reverted back to a checked exception.

Attached is the SVN patch to apply.

Original issue reported on code.google.com by [email protected] on 18 Jan 2011 at 6:10

Attachments:

• make-IncommensurableException-checked.patch

Velocity interface shall be renamed as Speed

All Quantity sub-interfaces are scalar quantities, except Velocity which is a 
vector quantity. This interface shall be renamed as Speed for consistency with 
the rest of the Quantity package.

More specifically, Speed is a scalar quantity that refers to "how fast an 
object is moving" while Velocity is a vector quantity that refers to "the rate 
at which an object changes its position" (see [1] and [2]). Speed is the 
magnitude of Velocity.

Note that the quantity package already uses Length (a scalar value) instead 
than Displacement (a vector value). Usage of Velocity is inconsistent with the 
above.

[1] http://www.physicsclassroom.com/class/1dkin/u1l1d.cfm
[2] http://en.wikipedia.org/wiki/Speed

Original issue reported on code.google.com by [email protected] on 26 Jan 2013 at 6:49