[JAVAMONEY-144] Resolve License issue with Eclipse Created: 23/Aug/15  Updated: 07/Feb/16

Status: Open
Project: javamoney
Component/s: API
Affects Version/s: 1.0
Fix Version/s: 1.x

Type: Task Priority: Major
Reporter: keilw Assignee: atsticks
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to UNITSOFMEASUREMENT-64 Make JSR available to Eclipse Orbit Resolved
Tags: Eclipse, MREL, license

 Description   

Due to a different understanding of what API vs. Implementation is by Eclipse Foundation, there's a blocking issue based on the current LICENSE files in Money-API or Money-API-BP, see https://java.net/jira/browse/UNITSOFMEASUREMENT-64
This Bugzilla ticket lines out the problem for a downstream Eclipse project (SmartHome) wanting to use JSR 363:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=434006

There is no request to add JSR 354 to Orbit at this point, but several business-related projects like Scout may benefit from it quite a lot.

This would require a change in the LICENSE file of both APIs, thus it is impossible to "just throw it in", if done, it must be under a MR.






[JAVAMONEY-156] Bootstrap should not sort in getService() Created: 04/Oct/15  Updated: 04/Jun/16

Status: Open
Project: javamoney
Component/s: API
Affects Version/s: 1.0
Fix Version/s: 1.1.1

Type: Bug Priority: Major
Reporter: keilw Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: bootstrap, spi

 Description   

The SPI class Bootstrap currently sorts services by simple name when getService() is called. This is unnecessary, if any sorting was done, the implementation of ServiceProvider would take care of it.
Thus simply calling ServiceProvider.getService() should be enough.






[JAVAMONEY-154] NumberValue.getNumberType() should return a type that extends Number. Created: 25/Sep/15  Updated: 28/Sep/15

Status: Open
Project: javamoney
Component/s: API
Affects Version/s: 1.0
Fix Version/s: 1.x

Type: Improvement Priority: Minor
Reporter: msgilligan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 Description   

See PR #52 on Github

NumberValue.getNumberType() should provide an explicit guarantee that
the type returned extends Number. So it should be:

public abstract Class<? extends Number> getNumberType();

instead of

public abstract Class<?> getNumberType();


 Comments   
Comment by otaviojava [ 27/Sep/15 ]

I totally agree with you, I did this suggestion the problem is: We cannot change the API, because it is in final release. To change it we need to either create a maintenance JSR or create a new JSR to update a JAR (1.0.1).
But it absolutely gonna to 1.0.1 version.

Comment by keilw [ 27/Sep/15 ]

No at most 1.1, which could be a MR1. The API must not be changed on the fly without an actual MR.

Comment by otaviojava [ 27/Sep/15 ]

Werner, do you mind explain more what is MR?

Comment by keilw [ 27/Sep/15 ]

Maintenance Release. Guess you haven't represented SouJava in the EC that long to vote on one, did you?

Comment by otaviojava [ 27/Sep/15 ]

Yes, I did.
But I know how we can do it.

Comment by msgilligan [ 28/Sep/15 ]

I just noticed that the Spec says, in Section 4.2.3 "Externalizing the Numeric Value of an Amount":

getNumberType() provides information about the numeric representation used internally. It explicitly does not constrain the type returned to be a subtype of java.lang.Number to allow alternate implementations to be used.

So I think that means that this issue should be closed as "won't fix".

(Although it sure would be handy if every NumberValue could return a standard type and with arbitrary-precision types available I don't see that it would be too difficult of a requirement.)





[JAVAMONEY-125] Add missing tests Created: 27/May/15  Updated: 09/Feb/16

Status: Open
Project: javamoney
Component/s: API
Affects Version/s: None
Fix Version/s: 1.x

Type: Improvement Priority: Minor
Reporter: znurgl Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVAMONEY-142 Define some tests as "integration-test" Open
is related to JAVAMONEY-104 Make coverage visible on all key arti... Open

 Description   

Test coverage is 76% at the moment. It needs to make sure every function has its test.



 Comments   
Comment by keilw [ 09/Feb/16 ]

This also applies to RIs, but the 76% refers to the API code coverage.





[JAVAMONEY-104] Make coverage visible on all key artifacts Created: 13/May/15  Updated: 04/Jun/16

Status: Open
Project: javamoney
Component/s: API, General: Build and quality management, Impl: RI, Test: TCK
Affects Version/s: 1.0
Fix Version/s: 1.0.1, 1.2

Type: Task Priority: Minor
Reporter: keilw Assignee: atsticks
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVAMONEY-125 Add missing tests Open
Relates
relates to JAVAMONEY-135 Ensure Unit Test coverage and results... Reopened
Tags: coverage, test

 Description   

Considerable effort was spent on increasing code coverage recently. Similar to the public API: https://github.com/JavaMoney/jsr354-api (showing 76% that's not bad, unless you're into safety critical software even corporate projects often don't insist on more than 60 or 70%) its BP and all other major artifacts (RI+RI-BP as well as TCK where applicable) should present theirs, too. API-BP has a badge, but no Coveralls profile seems to exist. Where missing, those should be created.






[JAVAMONEY-103] Create JEP for Java 10+ Created: 12/May/15  Updated: 04/Jun/16

Status: Open
Project: javamoney
Component/s: API, Impl: RI, Misc: JCP Administration
Affects Version/s: 1.0, 1.1
Fix Version/s: 2.x

Type: Task Priority: Minor
Reporter: keilw Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones JAVAMONEY-73 Create JEP for Java 9+ Closed
Tags: java10, jdk

 Description   

As discussed, it seems like a good idea to have an OpenJDK committer file a JEP for monetary improvements in a future Java version. Whether that's 10 or later should be determined by Oracle and the OpenJDK program. but without filing it, that's never going to happen.






Generated at Wed Aug 31 02:11:39 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.