[JAVAMONEY-84] Consolidate license files in API Created: 06/Feb/15  Updated: 11/Feb/15

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

Type: Task 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: documentation

 Description   

The API repo currently contains 2 license HTML files, while the readme text says (see LICENCE.html)
This should be addressed, ideally renaming the applicable one to LICENSE.html or otherwise changing readme.



 Comments   
Comment by atsticks [ 11/Feb/15 ]

when going final we need both licences an evaluation licence and an implementation licence. If to check the details with heather. For comparison you can looks at other JSRs...

Comment by keilw [ 11/Feb/15 ]

So aside from leaving "Public Review" in that file, why did JSR 107 only have 1 LICENSE.txt https://github.com/jsr107/jsr107spec
The detail page points to just 1 license https://jcp.org/en/jsr/detail?id=107
Under "Specification", that PDF has the correct "Final" stage btw, which ideally should also be in the GitHub repo. No 2nd PDF here either, so why would 354 require 2 PDFs?

This template https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt also mentioned on JCP.org is applicable to the Final release of the JSR. We just mentioned that one
>2.18 Please provide a description of the business terms for the Specification
which is why I'm wondering why there should be 2 in the repo. Aside from a very unuseful format that never renders properly in any browser. TXT seemed far easier to read here.

Even special cases like CDI have exceptional "dual-licensing" of everything including the Spec, it contains 2 Maven tool-chains to create a license PDF either for the Spec or Apache License, but aside from that it's always just one, not two license files per distribution.





[JAVAMONEY-90] Try to find a workable solution for Snapshots Created: 11/Feb/15  Updated: 11/Feb/15

Status: Open
Project: javamoney
Component/s: General: Build and quality management
Affects Version/s: 0.9
Fix Version/s: None

Type: Task 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: build, snapshot

 Description   

As of now the Snapshot repository formerly at CloudBees is inactive or deleted. The current Travis CI build runs the default Maven job and cannot find a Snapshot version of the API once the "head" of the API project changes:
317[ERROR] Failed to execute goal on project moneta: Could not resolve dependencies for project org.javamoney:moneta:jar:1.0-SNAPSHOT: Could not find artifact javax.money:money-api:jar:1.0-SNAPSHOT in sonatype-snapshots (https://oss.sonatype.org/content/repositories/snapshots/) -> [Help 1]

Ideally whenever at least API, RI and TCK change, a Snapshot repo like https://oss.sonatype.org/content/repositories/snapshots/ shall be automatically deployed to, otherwise some substitute like Cloudbees, as long as POM settings allow Maven to find it.






[JAVAMONEY-92] Format pattern for decimal digits is ignored Created: 12/Feb/15  Updated: 13/Feb/15

Status: Open
Project: javamoney
Component/s: Impl: RI
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: vitomirs Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVAMONEY-94 Avoid "magic strings" when building M... Open

 Description   

When an amount is printed, decimal digits are always formatted according to the number of the fraction digits defined for the current currency. If pattern is set to show more decimal digits, like in the next example, additional digits are truncated in the output. For example, amount '1234.5678 EUR' will be printed as '1.234,56 EUR', because EUR currency has 2 as number of the fraction digits.

MonetaryAmountFormat format = MonetaryFormats.getAmountFormat(
    AmountFormatQueryBuilder.of(Locale.GERMANY)
        .set(CurrencyStyle.SYMBOL)
        .set("pattern", "#,##0.00### ¤")
        .build());

However, some prices use more decimal digits (like gasoline). Usually, items which are often sold in bigger quantities (tens or hundreds) have a price defined with more decimal digits.

From my brief look at the sources, AmountNumberToken.print() method has three lines which override behavior set by the pattern.

int digits = amount.getCurrency().getDefaultFractionDigits();
this.formatFormat.setMinimumFractionDigits(digits);
this.formatFormat.setMaximumFractionDigits(digits);

IMHO, these lines should be removed. Then, if pattern is not set formatting will be done with regard to number of the fraction digits for the currency. If pattern is set, it should have higher priority and number of the displayed decimal digits should be as defined by the pattern.



 Comments   
Comment by keilw [ 12/Feb/15 ]

Will have a look. Especially Digital currencies whether Bitcoin or others often use an even bigger number of fraction digits





[JAVAMONEY-94] Avoid "magic strings" when building MonetaryAmountFormat Created: 13/Feb/15  Updated: 13/Feb/15

Status: Open
Project: javamoney
Component/s: API, Impl: RI
Affects Version/s: 0.9
Fix Version/s: 1.0

Type: Bug 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:
Related
is related to JAVAMONEY-92 Format pattern for decimal digits is ... Open
Tags: format

 Description   

A recently mentioned case about formatting

MonetaryAmountFormat format = MonetaryFormats.getAmountFormat(
    AmountFormatQueryBuilder.of(Locale.GERMANY)
       .set(CurrencyStyle.SYMBOL)
       .set("pattern", "#,##0.00### ¤")
       .build());

showed, a "magic string" "pattern" is required to get the correct MonetaryAmountFormat. In case of a typo e.g. "Pattern" instead of "pattern" this would fail. Similar to e.g. JDK Calendar.Builder and other places it would be best if the API contains at least a minimal set of default keys already. Allowing

MonetaryAmountFormat format = MonetaryFormats.getAmountFormat(
    AmountFormatQueryBuilder.of(Locale.GERMANY)
       .set(CurrencyStyle.SYMBOL)
       .set(PATTERN, "#,##0.00### ¤")
       .build());

The best place for such constant seems either MonetaryAmountFormat, MonetaryFormats or AmountFormatContext.



 Comments   
Comment by keilw [ 13/Feb/15 ]

That issue showed the usage of a "magic string", the problem raised is however unrelated.

Comment by keilw [ 13/Feb/15 ]

Just an example how similar key constants are declared e.g. by Android Robotium Instrumentation

public static final String  REPORT_KEY_IDENTIFIER 

If included in the status or final bundle sent to an IInstrumentationWatcher, this key identifies the class that is writing the report. This can be used to provide more structured logging or reporting capabilities in the IInstrumentationWatcher. 

Constant Value:   "id" 




Generated at Mon Mar 02 20:50:27 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.