Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't Parse "mile" or "mi" to USCustomary.MILE #50

Closed
Weizilla opened this issue Jan 1, 2017 · 5 comments
Closed

Can't Parse "mile" or "mi" to USCustomary.MILE #50

Weizilla opened this issue Jan 1, 2017 · 5 comments
Labels
Milestone

Comments

@Weizilla
Copy link

Weizilla commented Jan 1, 2017

I'm trying to parse the string mile into USCustomary.MILE but I get a parse exception instead.

UnitFormat unitFormat = SimpleUnitFormat.getInstance();
Unit<Length> mileUnit = unitFormat.parse("mile").asType(Length.class);
System.out.println(mileUnit);

throws

javax.measure.format.ParserException: Parse Error
	at tec.uom.se.format.SimpleUnitFormat$DefaultFormat.check(SimpleUnitFormat.java:561)
	at tec.uom.se.format.SimpleUnitFormat$DefaultFormat.parseSingleUnit(SimpleUnitFormat.java:414)
	at tec.uom.se.format.SimpleUnitFormat$DefaultFormat.parseProductUnit(SimpleUnitFormat.java:425)
	at tec.uom.se.format.SimpleUnitFormat.parseObject(SimpleUnitFormat.java:269)
	at tec.uom.se.format.SimpleUnitFormat$DefaultFormat.parse(SimpleUnitFormat.java:765)
	at tec.uom.se.format.SimpleUnitFormat$DefaultFormat.parse(SimpleUnitFormat.java:760)
	at tec.uom.se.format.SimpleUnitFormat$DefaultFormat.parse(SimpleUnitFormat.java:751)

I tried parsing mi as well but I get the same error.

Is unit parsing not supported for miles? It works with meters. Or perhaps I'm using the wrong set of libraries?

This is my list of maven dependencies:

  <dependencies>
        <dependency>
            <groupId>javax.measure</groupId>
            <artifactId>unit-api</artifactId>
            <version>1.0</version>
        </dependency>
        <dependency>
            <groupId>tec.uom</groupId>
            <artifactId>uom-se</artifactId>
            <version>1.0.2</version>
        </dependency>
        <dependency>
            <groupId>tec.uom.lib</groupId>
            <artifactId>uom-lib-common</artifactId>
            <version>1.0.1</version>
        </dependency>
        <dependency>
            <groupId>systems.uom</groupId>
            <artifactId>systems-common</artifactId>
            <version>0.5</version>
        </dependency>
        <dependency>
            <groupId>systems.uom</groupId>
            <artifactId>systems-quantity</artifactId>
            <version>0.5</version>
        </dependency>
        <dependency>
            <groupId>systems.uom</groupId>
            <artifactId>systems-common-java8</artifactId>
            <version>0.5</version>
        </dependency>
    </dependencies

Could it be related to #39? When I print USCustomary.MILE, I get m*201168.0/125.0 instead of mile so could it be I'm missing some resource?

@keilw
Copy link
Member

keilw commented Jan 1, 2017

It could be. Would it be possible to try 0.6-SNAPSHOT of systems-common-java8? You find the additional repositories for the snapshot builds in every parent POM like https://github.com/unitsofmeasurement/uom-systems/blob/master/pom.xml
Will have a look and test it after getting back to Germany. It may be fixed in the Snapshot version together with UOM-SE 1.0.2 already.

@Weizilla
Copy link
Author

Weizilla commented Jan 1, 2017

Using 0.6-SNAPSHOT prints mi and parses mi successfully but fails on parsing mile. Is there a way to parse mile too?

@keilw
Copy link
Member

keilw commented Jan 2, 2017

Yes, it's not an API element right now, but with alias() you can do, see

    SimpleUnitFormat.getInstance().alias(USCustomary.MILE, "mile");	    
    Unit u = SimpleUnitFormat.getInstance().parse("mile");

@keilw keilw added this to the 0.6 milestone Jan 2, 2017
@keilw
Copy link
Member

keilw commented Jan 2, 2017

Addressed in 0.6, will close. Plan to release 0.6 after a few more tests.

@keilw keilw closed this as completed Jan 2, 2017
@keilw keilw removed the in progress label Jan 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants