[JAVAMONEY-79] Difficult to add a markup to FX rate Created: 14/Oct/14  Updated: 10/Feb/15

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

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


 Description   

There doesn't seem to be a way to pass in a complete context to the exchange rate mechanism. Specifically whenever we do an FX we would like to add a markup to the rate provided by whatever provider we have setup. For example in the following snippet "markup_rate" is not carried over to the rate provider that is when getExchangeRate(ConverstionQuery q) is called we're unable to extract the passed in value.

MonetaryOperator convertTo(CurrencyUnit currency, BigDecimal forexMarkupPercentage) {
        return getConversion(
                ConversionQueryBuilder.of()
                        .setTermCurrency(currency)
                        .set("markup_rate", forexMarkupPercentage)
                        .build());
    }

Note that this "markup_rate" is something that we expect to what to change on every call and not setup once for the provider.



 Comments   
Comment by atsticks [ 29/Jan/15 ]

Will have a look at it. There were some bugfixes on the AbstractContext, which may have been the root cause that the value was not passed over to the provider.

Comment by atsticks [ 29/Jan/15 ]

Accessing an ExchangeRateProvider does not pass the ConversionQuery, whereas accessing a Conversion passes the query to ExchangeRateProvider.getCurrencyConversion(ConversionQuery);
It is in the reponsibility of the ExchangeRateProvider implementation to store the currency query or its attributes supported.

If the issue is due to the fact that a value is not stored correctly in the query itself it might be solved on the current head.

If the issues is more related to the first part, can you please give as a hint which functions you exactly are calling? THANKS!





[JAVAMONEY-58] Currency data source URL for IsoCurrencyOnlineProvider needs updating Created: 12/Aug/13  Updated: 05/Feb/15

Status: In Progress
Project: javamoney
Component/s: Library: JavaMoney Extensions
Affects Version/s: None
Fix Version/s: 1.0

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


 Description   

The URL which specifies the location of the currency source in net.java.javamoney.ri.ext.provider.iso.IsoCurrencyOnlineProvider#loadCurrencies method is no longer valid. The current source is:

http://www.currency-iso.org/dam/isocy/downloads/dl_iso_table_a1.xml

which results in an Http 404.

I believe the replacement should be:

http://www.currency-iso.org/dam/downloads/table_a1.xml


 Comments   
Comment by keilw [ 12/Aug/13 ]

As a first step I'm fixing the URL to the new version. Where CI server (Jenkins) would also allow us to run Integration Tests there should be some for external services such as this to flag whenever this or another URL changes in future.
Will externalize it into a properties file for easier maintenance, but ultimate customization should be possible similar to Java 7+ Currency class:
>Users can supersede the Java runtime currency data by creating a properties file named <JAVA_HOME>/lib/currency.properties. The contents of the properties file are key/value pairs of the ISO 3166 country codes and the ISO 4217 currency data >respectively. The value part consists of three ISO 4217 values of a currency, i.e., an alphabetic code, a numeric code, and a minor unit. Those three
>ISO 4217 values are separated by commas. The lines which start with '#'s are considered comment lines. For example,...

either we'd use this file or introduce another one or two additional files (not too many, otherwise it gets confusing and we'd have a Spring-like maze of properties

Comment by keilw [ 13/Aug/13 ]

Changed, those URLs are now loaded from a properties file, but neither of the URLs looks like it gets results from parsing
I suppose the 404 error was mainly a browser-based observation, so there may be something left to do.

Debug information (if log level is changed appropriately or System.out/IDE-debugging used) tells currencies is empty, while the list of countries contains 249 of them.

Comment by paulkmoore [ 13/Aug/13 ]

Werner, the mapping also appears to have changed - I guess they did this as part of the "move"...

From the comments in code the previous feed appears to be structured as follows:

// <ISO_CCY_CODES>
// <ISO_CURRENCY>
// <ENTITY>AFGHANISTAN</ENTITY>
// <CURRENCY>Afghani</CURRENCY>
// <ALPHABETIC_CODE>AFN</ALPHABETIC_CODE>
// <NUMERIC_CODE>971</NUMERIC_CODE>
// <MINOR_UNIT>2</MINOR_UNIT>
// </ISO_CURRENCY>
// ...
// </ISO_CCY_CODES>

Whereas the new feed is as follows:

<ISO_4217 Pblshd="">
	<CcyTbl>
		<CcyNtry>
			<CtryNm>AFGHANISTAN</CtryNm>
			<CcyNm>Afghani</CcyNm>
			<Ccy>AFN</Ccy>
			<CcyNbr>971</CcyNbr>
			<CcyMnrUnts>2</CcyMnrUnts>
		</CcyNtry>
		<!--snip-->
	</CcyTbl>
</ISO_4217>
Comment by keilw [ 02/Sep/14 ]

This has been open for a while, does it work now?





[JAVAMONEY-85] Tag releases when something is published to repo Created: 06/Feb/15  Updated: 06/Feb/15

Status: In Progress
Project: javamoney
Component/s: API, Impl: RI, Test: TCK
Affects Version/s: 0.9
Fix Version/s: 1.0

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

Tags: deployment, release

 Description   

At least the milestone build 1.0-RC1 was published to MavenCentral, but no corresponding release tags could be found in any of the GitHub repositories.
It would be cumbersome to roll everything back and re-create such tag for 1.0-RC1, but for the current build 1.0-RC2 all necessary tags shall be created ASAP and ideally in future let's try to do this BEFORE publishing






[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 Fri Feb 27 04:57:17 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.