Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-138] Core Module Created: 16/Jul/15  Updated: 19/Jul/15

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

Type: Sub-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





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-141] Pass TCK Created: 27/Jul/15  Updated: 01/Aug/15

Status: In Progress
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0.1
Fix Version/s: None

Type: Sub-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

Attachments: PNG File result_test.png     PNG File tck_example_diff.png     PNG File tck_example_result.png     PNG File update_version_diff.png     PNG File update_version_result.png    
Issue Links:
Blocks
is blocked by JAVAMONEY-143 JavaMoney TCK Usage Example results d... In Progress
Related
is related to JAVAMONEY-140 Convert Module In Progress
Tags: test

 Description   

Ensure, a modular RI still passes the TCK.
At least https://github.com/JavaMoney/javamoney-tck-usage-example contains a POM entry like

<impl.groupId>org.javamoney</impl.groupId>
<impl.artifactId>moneta</impl.artifactId>
<impl.version>1.0</impl.version>
<impl.packageType>jar</impl.packageType>

Which is not going to work if "moneta" is now a "BOM"/POM rather than a JAR artifact. At the very least the TCK Guideline must be updated, potentially the TCK itself, too. Since JSR 107 published an on-the-fly update 1.0.1 of its TCK: http://mvnrepository.com/artifact/javax.cache/tck-parent/1.0.1 it looks like this is generally possible without an official MR, as long as the RI and other implementations still pass the TCK



 Comments   
Comment by otaviojava [ 27/Jul/15 ]

Werner, I ran the test and everything goes ok.
The moneta is a pom that has all code as dependency, so the behavior doesn't changed just the architecture.

I just ran the command on tck:

mvn test 

Do I need to do more anything?

Comment by keilw [ 27/Jul/15 ]

Did you use the TCK example for that?

Comment by otaviojava [ 27/Jul/15 ]

No, this one:
https://github.com/JavaMoney/jsr354-tck

Comment by keilw [ 27/Jul/15 ]

Though it seems legitimate, please try the Moneta (Java 8) version of that TCK demo to see, if it works. "jar" as artifact sounds fishy, so maybe a few adjustments could be necessary (and a 1.0.1-SNAPSHOT, too)

Comment by otaviojava [ 27/Jul/15 ]

This way?

Comment by keilw [ 27/Jul/15 ]

Also the version of the actual test. Strange, the

<type>${impl.packageType}</type> 

seems to be ignored or irrelevant? Maybe it's optional anyway, then it would be better to leave it than call a POM JAR?

Comment by otaviojava [ 27/Jul/15 ]

I believe the type is irrelevant.

Comment by keilw [ 28/Jul/15 ]

Then let's try to remove it. I can't run it here now, but happy to try as a 2nd opinion. For now best adjusting master of those TCK tests and run them to verify if it still works
I would not forget a "format" modularization, but if everything else was sound we may postpone that step till a 1.0.2+ build.

Comment by keilw [ 28/Jul/15 ]

Actually there is one error message (though it doesn't cause the build or TCK to fail)

Jul 28, 2015 7:36:22 PM org.javamoney.moneta.spi.MonetaryConfig <init>
SCHWERWIEGEND: Error loading javamoney.properties, ignoring jar:file:/C:/Users/Werner/.m2/repository/org/javamoney/moneta/moneta-convert/1.0.1-SNAPSHOT/moneta-convert-1.0.1-SNAPSHOT.jar!/javamoney.properties
java.lang.IllegalStateException: AmbiguousConfiguration detected for 'conversion.default-chain'.
	at org.javamoney.moneta.spi.MonetaryConfig.updateConfig(MonetaryConfig.java:90)
	at org.javamoney.moneta.spi.MonetaryConfig.<init>(MonetaryConfig.java:53)
	at org.javamoney.moneta.spi.MonetaryConfig.<clinit>(MonetaryConfig.java:39)
	at org.javamoney.moneta.internal.DefaultMonetaryCurrenciesSingletonSpi.getDefaultProviderChain(DefaultMonetaryCurrenciesSingletonSpi.java:99)
	at org.javamoney.moneta.internal.DefaultMonetaryCurrenciesSingletonSpi.collectProviders(DefaultMonetaryCurrenciesSingletonSpi.java:69)
	at org.javamoney.moneta.internal.DefaultMonetaryCurrenciesSingletonSpi.getCurrencies(DefaultMonetaryCurrenciesSingletonSpi.java:42)
	at javax.money.spi.MonetaryCurrenciesSingletonSpi.getCurrency(MonetaryCurrenciesSingletonSpi.java:72)
	at javax.money.Monetary.getCurrency(Monetary.java:420)
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testCurrencyClassesComparable(ModellingCurrenciesTest.java:138)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)
	at org.javamoney.test.tck.RunTCKTest.runTCK(RunTCKTest.java:25)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:69)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:120)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:104)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:113)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

Looks like the same properties file is in 2 JARs now. On one hand it is used by SPI/core, but logically it belongs to "convert".

Comment by keilw [ 28/Jul/15 ]

The cause is, because a proper dissection of "core" and "convert" was somehow lost (or undone) so a whole "common convert" module is missing and stuff that should be there got into core. See https://java.net/jira/browse/JAVAMONEY-140

Comment by otaviojava [ 28/Jul/15 ]

Werner, are you using the modularized_money_ri branch?
it`s fine.

Comment by keilw [ 28/Jul/15 ]

No it's not
There are still improper things in core that belong to the convert module.
It is not just about making ECB or IMF optional/modular, it's about making the entire convert subsystem modular.
Through some changes or merges this was lost

Somehow "moneta" turned from pure POM to a chimera between "convert-shared" (I'm recreating that) and core, holding primarily conversion-related stuff. That makes no sense.

Comment by otaviojava [ 28/Jul/15 ]

@werner.
it`s following the email list, if you want do other changes about this history, please rollback to email list.
Please, don`t commit directly on modularized_money_ri branch.
This branch follows the issue on email list.

Comment by keilw [ 28/Jul/15 ]

It is incomplete and wrong. Especially that misplaced moneta/convert/core.

Something got very messed up, as it it the branch doesn't add value over the 2 separate lib modules

Comment by otaviojava [ 28/Jul/15 ]

You tould about the Jigsaw, but did you look to Jigsaw on OpenJDK?
http://hg.openjdk.java.net/jdk9/jdk9
If you look to the pach:
jdk9/jdk/src
You will see:

  • java.base
  • java.corba
  • java.datatransfer
  • java.desktop
  • java.instrument
  • java.logging
  • java.management
  • java.naming
  • java.prefs
  • java.rmi
  • java.scripting
  • java.security.jgss
  • java.security.sasl
  • java.smartcardio
  • java.sql
  • ...

So the modularization is by feature, so the javax.money is the same feature, isn't? So they will stay together. This modules doesn't make sense to OpenJDK.

you need the mercurial installed then execute this command:

hg clone http://hg.openjdk.java.net/jdk9/jdk9 jdk_1_9
Comment by keilw [ 28/Jul/15 ]

I know what Mark told us, that's enough.

E.g. you should be able to use Swing without JavaFX and vice versa.
The Circular dependencies make that impossible. Hence, you would always get Swing (except for a particular L&F like "Metal") even if you don't need it.

That is the purpose of clean modularity

Comment by otaviojava [ 28/Jul/15 ]

I really don't understand how.
We have the core code, and the exchange-rate splitted, so three modules.
The exchange rate depends the core, but the core does not depend of the exchange-rate modules.

Comment by keilw [ 28/Jul/15 ]

So if you do not need currency conversion you'll only use
-moneta.core (at the moment that includes formatting)

but not
-moneta-convert-shared
-moneta-convert-ecb
or
-moneta-convert-imf

The API is cleanly separated, too, even if it comes in a single JAR.
Except for the SPI package (which has similar dependencies in JSR 363)
"convert" and "format" are completely independent of each other and there are no circular dependencies from javax.money elements to javax.money.convert, just the other way round

This is what the RI must also accomplish, at least for "convert" and ideally "format", too.

Comment by otaviojava [ 28/Jul/15 ]

There isn't proposal to remove format to the core.
The circular dependencies is when a module A depends of a module B and the B depends of module A.
If the convert depends of core but the core doen's depends of the module convert, so there isn't circular dependencies.

Comment by keilw [ 28/Jul/15 ]

There is a sub-task, and it's possible, but you first gotta cleanly separate core from convert and downstream modules

core -> convert-shared ->
convert-ecb
convert-imf

And no circular dependencies back into core.
Only the "BOM" moneta artifact pulls all of them together

Comment by keilw [ 28/Jul/15 ]

In the incomplete branch you got lots of conversion stuff in moneta, which is not part of convert, so you have a circular dependency (back from ECB/IMF, that's where the tests fail if you do this properly)

Comment by otaviojava [ 28/Jul/15 ]

Werner, there isn't convert on moneta, just the ExchangeRateProvider,
The ExchangeRateProvider is an interface on money-api.
Does the moneta-core depend of the money-api?
So, there isn't circular dependency.
Please, check it again.

This class is on api:
https://github.com/JavaMoney/jsr354-api/blob/master/src/main/java/javax/money/convert/ExchangeRateProvider.java

The moneta-core depends of the money-api, but the money-api does not depend of the moneta-core, still not circular dependency.

BTW: If you find circular dependency just tell me the class, because I will propose this branch on Wednesday to master and send an email to public list. But until now the branch modularized_money_ri is working, with all TCK tests passed, without circular dependency and really complete.

Comment by keilw [ 28/Jul/15 ]

I'm not talking about ExchangeRateProvider, but this
https://github.com/JavaMoney/jsr354-ri/blob/modularized_money_ri/moneta/src/main/java/org/javamoney/moneta/ExchangeRateType.java
It does not belong there, because the "moneta" artifact has dependencies

<dependencies>
<dependency>
<groupId>org.javamoney</groupId>
<artifactId>moneta-convert-imf</artifactId>
<version>$

{project.version}</version>
</dependency>
<dependency>
<groupId>org.javamoney</groupId>
<artifactId>moneta-convert-ecb</artifactId>
<version>${project.version}

</version>
</dependency>

Other stuff that belongs to "convert-shared" was left in "core" so the content of "moneta" JAR is a chimera and doesn't really make sense since one or two enums were randomly removed from "core" instead of properly moving all of it into a reusable convert module.

Gotta go to bed now, will have to continue later. As of now, it is quite likely TCK picked up the single JAR which is all over the place. therefore a unique version number is necessary to really test it. As soon as the version number is distinct and not a snapshot that's been deployed 100 times from a single JAR moneta under the same version, both the TCK and examples are missing some classes.

Comment by otaviojava [ 28/Jul/15 ]

The moneta project has all dependencies and this class still there to keep the compatibility.
moneta is different of the moneta-core, so still compatible.

Comment by keilw [ 28/Jul/15 ]

I'm afraid not. Just ran both against the actual TCK and it fails all but 20 tests.

tck-example even if you select a totally different RI version number (I built them as 1.0.1-RC0 for the "old" attempt and 1.0.1-RC1 for the new untangled onne) always passes, but it doesn't even seem to care about the TCK version, always calls TCK 1.0.
The 233 tests are said to pass, but they run against "god knows what". In fact the original TCK being built against the Java 7 Moneta-BP, so chances are very high you always run those 233 passing tests against Moneta-BP and not even the Java 8 version

That is exactly why the two variations must remain consistent and compatible. Disecting one will not work if the other isn't .

Comment by keilw [ 29/Jul/15 ]

Running TCKRunner is actually best inside the actual TCk module.
Against 1.0.1-SNAPSHOT (most likely Moneta-BP in that case ) results already look bad
------------------------------------------

TOTAL TESTS EXECUTED : 233
TOTAL TESTS SKIPPED : 0
TOTAL TESTS SUCCESS : 222
TOTAL TESTS FAILED : 11

– JSR 354 TCK finished –

Against the 1.0.1-RC0

JSR 354 TCK, version 1.0 Summary
------------------------------------------

TOTAL TESTS EXECUTED : 233
TOTAL TESTS SKIPPED : 0
TOTAL TESTS SUCCESS : 10
TOTAL TESTS FAILED : 223

– JSR 354 TCK finished –

Comment by otaviojava [ 29/Jul/15 ]

I updated the version and still working.

Comment by keilw [ 29/Jul/15 ]

Then it's been running against Moneta-BP all the time
When the TCK is truly run against a modularized Moneta (regardless of the branch) it fails as outlined
TOTAL TESTS EXECUTED : 233
TOTAL TESTS SKIPPED : 0
TOTAL TESTS SUCCESS : 10
TOTAL TESTS FAILED : 223

Both the modularized and semi-modularized versions show the same result here.

Comment by otaviojava [ 29/Jul/15 ]

Wener probaly you broke the local branch, please try download the remote one.
I did all necessary modifications on the pom.

Comment by keilw [ 29/Jul/15 ]

That's exactly the one run against the TCK. RC0 which is the remote one. You may have to do a clean before running TCKRunner, otherwise you're just running against a previous result.
The TCK tests it shows failing (will attach the exact Maven log some time later)
In any case the flawed branch contains a convert-relic like https://github.com/JavaMoney/jsr354-ri/tree/modularized_money_ri/moneta/src/main/java/org/javamoney/moneta/convert for no other reason than providing a pseudo-JAR. That's not the right way to do it, these are classes that have no place there, they must be in "convert"
And all of these imports

import org.javamoney.moneta.convert.ecb.ECBCurrentRateProvider;
import org.javamoney.moneta.convert.ecb.ECBHistoric90RateProvider;
import org.javamoney.moneta.convert.ecb.ECBHistoricRateProvider;
import org.javamoney.moneta.convert.imf.IMFHistoricRateProvider;
import org.javamoney.moneta.convert.imf.IMFRateProvider;

are unused, and given this is a "shared convert" class, also won't work this way.

Probably tricking Maven into pulling stuff from other modules but that's a dirty hack. As a matter of fact, the enum will require splitting up because it refers to stuff in different modules.
And getting the dependency chain right without an empty shell that contains just 2 classes that don't fit there.

Comment by keilw [ 29/Jul/15 ]

In fact nobody needs to check out all of OpenJDK or use Hg to see how the Jigsaw modules are dependent on each other.
Looking at this 2000 line "Uber POM" http://hg.openjdk.java.net/jdk9/jdk9/file/887a2657adef/modules.xml is more than enough.

It contains all details of packages or "bundles" that make up larger feature modules like "java.base".
We discussed in great detail on the mailing list that the "Sins of our fathers" in the JDK all the way up to Java 8 and further bloating like "java.time" made it almost impossible to break it down further. Developers who use only java.util.Date or Calendar won't care about "java.time" but they were tied to each other in some ways (or as Stephen mentioned share underlying TZ data in a shared but clumsy fashion) so they were molded together in an inseparable manner. Similar in many other cases where short-sighted or insignificant API design caused a big mess. That's why Jigsaw was delayed for so many years. "java.desktop" clearly does not contain the JavaFX codebase. That is a very separate module which has dependencies at least to "java.base" maybe a few other modules but is not required for any of them java.desktop (with AWT and Swing) can be completely taken away for smaller devices.

What you propose and drafted in the earlier branch is no more than taking these away out of "java.desktop"

<export>
      <name>javax.swing.plaf.basic</name>
    </export>
    <export>
      <name>javax.swing.plaf.metal</name>
    </export>
    <export>
      <name>javax.swing.plaf.multi</name>
    </export>
    <export>
      <name>javax.swing.plaf.nimbus</name>
    </export>
    <export>
      <name>javax.swing.plaf.synth</name>
    </export>

(L 739ff in the current modules.xml)

Leaving the rest of it in there. These providers are no more than Swing PLAF extensions, they barely mean any footprint and don't bring benefit to users e.g. if they don't care about foreign exchange but just need to do rounding and calculations in their own local currency.

HTH

Comment by keilw [ 29/Jul/15 ]

So this is the entire Maven console running against the old branch (1.0.1-RC0, everything in sync with GitHub, just check it)

-- JSR 354 TCK started --
Writing to file C:\Users\Werner\git\jsr354-tck\.\target\tck-results.txt ...
[TestNG] Running:
  Command line suite

Jul 29, 2015 8:17:59 PM org.javamoney.moneta.DefaultMonetaryContextFactory createMonetaryContextNonNullConfig
INFORMATION: Using custom MathContext: precision=256, roundingMode=HALF_EVEN
Jul 29, 2015 8:18:00 PM org.javamoney.moneta.internal.loader.LoadRemoteDataLoaderService execute
INFORMATION: The exchange rate with resourceId IMFHistoricRateProvider was started remotely
Jul 29, 2015 8:18:00 PM org.javamoney.moneta.internal.loader.LoadRemoteDataLoaderService execute
INFORMATION: The exchange rate with resourceId IMFRateProvider was started remotely
Jul 29, 2015 8:18:00 PM org.javamoney.moneta.internal.loader.LoadRemoteDataLoaderService execute
INFORMATION: The exchange rate with resourceId ECBCurrentRateProvider was started remotely
Jul 29, 2015 8:18:01 PM org.javamoney.moneta.convert.ecb.ECBAbstractRateProvider newDataLoaded
INFORMATION: Loaded ECBCurrentRateProvider exchange rates for days:1
Jul 29, 2015 8:18:01 PM org.javamoney.moneta.spi.CompoundRateProvider getExchangeRate
WARNUNG: Rate Provider did not return data though at check before data was flagged as available, provider=ECB, query=ConversionQuery (
{Query.termCurrency=org.javamoney.tck.tests.internal.TestCurrencyUnit@4c40b76e, Query.baseCurrency=CHF})
Jul 29, 2015 8:18:01 PM org.javamoney.moneta.convert.ecb.ECBAbstractRateProvider newDataLoaded
INFORMATION: Loaded ECBHistoric90RateProvider exchange rates for days:63

===============================================
JSR354-TCK, version 1.0
Total tests run: 233, Failures: 11, Skips: 0
===============================================


********************************************************************************
**** JSR 354 - Money & Currency, Technical Compatibility Kit, version 1.0.
********************************************************************************

Executed on Wed Jul 29 20:17:57 CEST 2015

[FAILED]  4.2.1 Ensure registered CurrencyUnit classes are Comparable.(ModellingCurrenciesTest#testCurrencyClassesComparable):
java.lang.ExceptionInInitializerError
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testCurrencyClassesComparable(ModellingCurrenciesTest.java:134)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)
Caused by: java.lang.IllegalStateException: No valid implementation of org.javamoney.tck.JSR354TestConfiguration is registered with the ServiceLoader.
	at org.javamoney.tck.TCKTestSetup.loadTestConfiguration(TCKTestSetup.java:33)
	at org.javamoney.tck.TCKTestSetup.<clinit>(TCKTestSetup.java:19)
	... 23 more

[FAILED]  4.2.1 Ensure registered CurrencyUnit classes implement hashCode.(ModellingCurrenciesTest#testCurrencyClassesEqualsHashcode):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testCurrencyClassesEqualsHashcode(ModellingCurrenciesTest.java:93)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.1 Test currencies provided have correct ISO 3-letter currency codes.(ModellingCurrenciesTest#testEnforce3LetterCode4ISO)
[FAILED]  4.2.1 Ensure TCK has CurrencyUnit classes configured.(ModellingCurrenciesTest#testEnsureCurrencyUnit):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testEnsureCurrencyUnit(ModellingCurrenciesTest.java:36)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.1 Test currencies provided equal at least currencies from java.util.Currency.(ModellingCurrenciesTest#testEqualISOCurrencies)
[SUCCESS] 4.2.1 Test currencies provided have correct default fraction digits and numeric code.(ModellingCurrenciesTest#testISOCodes)
[SUCCESS] 4.2.1 Ensure registered CurrencyUnit classes implement equals.(ModellingCurrenciesTest#testImplementsEquals)
[FAILED]  4.2.1 Ensure registered CurrencyUnit classes are serializable.(ModellingCurrenciesTest#testImplementsSerializable):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testImplementsSerializable(ModellingCurrenciesTest.java:164)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[FAILED]  4.2.1 Ensure registered CurrencyUnit classes are immutable.(ModellingCurrenciesTest#testIsImmutable):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingCurrenciesTest.testIsImmutable(ModellingCurrenciesTest.java:149)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.2 For each amount class, test absolute().(ModellingMonetaryAmountsTest#testAbsolute)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m1, m2 = mixed fractions.(ModellingMonetaryAmountsTest#testAddMixedFractions)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m1, m2 = mixed ints.(ModellingMonetaryAmountsTest#testAddMixedIntegers)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m1 <0, m2<0.(ModellingMonetaryAmountsTest#testAddNegativeIntegers)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m2 is fraction.(ModellingMonetaryAmountsTest#testAddPositiveFractions)
[SUCCESS] 4.2.2 For each amount class, check m1.add(m2), m1 >0, m2>0.(ModellingMonetaryAmountsTest#testAddPositiveIntegers)
[SUCCESS] 4.2.2 For each amount class, ensure ArithemticException is thrown when adding exceeding values.(ModellingMonetaryAmountsTest#testAdd_ExceedsCapabilities)
[SUCCESS] 4.2.2 For each amount class, ensure currency compatibility is working.(ModellingMonetaryAmountsTest#testAdd_IncompatibleCurrencies)
[SUCCESS] 4.2.2 For each amount class, ensure NullPointerException is thrown when calling m.add(null).(ModellingMonetaryAmountsTest#testAdd_Null)
[SUCCESS] 4.2.2 For each amount class, ensure m2 = m1,add(0) -> m1==m2.(ModellingMonetaryAmountsTest#testAdd_Zero)
[SUCCESS] 4.2.2 Ensure amount can be created with all default currencies.(ModellingMonetaryAmountsTest#testCurrencyCode)
[SUCCESS] 4.2.2 For each amount class, ensure correct division.(ModellingMonetaryAmountsTest#testDivide)
[SUCCESS] 4.2.2 For each amount class, ensure correct divideAndRemainder().(ModellingMonetaryAmountsTest#testDivideAndRemainder)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(Double.NEGATIVE_INFINITY) returns ZERO amount.(ModellingMonetaryAmountsTest#testDivideAndRemainderDoubleNEGATIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(Double.NaN) throws a ArithmeticException.(ModellingMonetaryAmountsTest#testDivideAndRemainderDoubleNaN)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(Double.POSITIVE_INFINITY) returns ZERO amount.(ModellingMonetaryAmountsTest#testDivideAndRemainderDoublePOSITIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(null) throws a NullPointerException.(ModellingMonetaryAmountsTest#testDivideAndRemainderNull)
[SUCCESS] 4.2.2 For each amount class, ensure divideAndRemainder(1) returns same instance.(ModellingMonetaryAmountsTest#testDivideAndRemainderOne)
[SUCCESS] 4.2.2 For each amount class, ensure correct divideAndRemainderZero().(ModellingMonetaryAmountsTest#testDivideAndRemainderZero)
[SUCCESS] 4.2.2 For each amount class, ensure divide(Double.NEGATIVE_INFINITY) return ZERO amount.(ModellingMonetaryAmountsTest#testDivideDoubleNEGATIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure divide(Double.NaN) throws ArithmeticException.(ModellingMonetaryAmountsTest#testDivideDoubleNaN)
[SUCCESS] 4.2.2 For each amount class, ensure divide(Double.POSITIVE_INFINITY) return ZERO amount.(ModellingMonetaryAmountsTest#testDivideDoublePOSITIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure divide by null throws NullPointerException.(ModellingMonetaryAmountsTest#testDivideNull)
[SUCCESS] 4.2.2 For each amount class, ensure divide 1 returns same instance.(ModellingMonetaryAmountsTest#testDivideOne)
[SUCCESS] 4.2.2 For each amount class, ensure correct division with int values.(ModellingMonetaryAmountsTest#testDivideToIntegralValue)
[SUCCESS] 4.2.2 For each amount class, ensure divide(0) throws ArithmeticException.(ModellingMonetaryAmountsTest#testDivideZero)
[SUCCESS] 4.2.2 Ensure Monetary.getAmountTypes() is not null and not empty.(ModellingMonetaryAmountsTest#testEnsureMonetaryAmount)
[SUCCESS] 4.2.2 Ensure amounts created return correct getContext().(ModellingMonetaryAmountsTest#testGetMonetaryContext)
[SUCCESS] 4.2.2 Ensure amounts created return correct getNumber().(ModellingMonetaryAmountsTest#testGetNumber)
[FAILED]  4.2.2 For each amount class, test iis immutable.(ModellingMonetaryAmountsTest#testImmutable):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingMonetaryAmountsTest.testImmutable(ModellingMonetaryAmountsTest.java:2543)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.2 For each amount class, test is Comparable.(ModellingMonetaryAmountsTest#testImplementComparable)
[SUCCESS] 4.2.2 For each amount class, test implements equals().(ModellingMonetaryAmountsTest#testImplementsEquals)
[SUCCESS] 4.2.2 For each amount class, test implements hashCode().(ModellingMonetaryAmountsTest#testImplementsHashCode)
[SUCCESS] 4.2.2 For each amount class, test isNegative().(ModellingMonetaryAmountsTest#testIsNegative)
[SUCCESS] 4.2.2 For each amount class, test isNegativeOrZero().(ModellingMonetaryAmountsTest#testIsNegativeOrZero)
[SUCCESS] 4.2.2 For each amount class, test isPositive().(ModellingMonetaryAmountsTest#testIsPositive)
[SUCCESS] 4.2.2 For each amount class, test isPositiveOrZero().(ModellingMonetaryAmountsTest#testIsPositiveOrZero)
[SUCCESS] 4.2.2 For each amount class, test isZero().(ModellingMonetaryAmountsTest#testIsZero)
[SUCCESS] 4.2.2 For each amount class, test isZero(), advanced.(ModellingMonetaryAmountsTest#testIsZeroAdvanced)
[SUCCESS] 4.2.2 For each amount class, access factory and of amounts.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories)
[SUCCESS] 4.2.2 For each amount class, check multiple instances are not equal.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_CreateWithCurrencies)
[SUCCESS] 4.2.2 For each amount class, check new amounts with explcit MonetaryContext.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_CreateWithMonetaryContext)
[SUCCESS] 4.2.2 For each amount class, check new amounts are not equal for different currencies and contexts.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_CreateWithMonetaryContextNumberAndCurrency)
[SUCCESS] 4.2.2 For each amount class, access factory and of amounts, ensure amounts are equal if theyshould.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_InstancesMustBeEqual)
[SUCCESS] 4.2.2 For each amount class, check new amounts are not equal.(ModellingMonetaryAmountsTest#testMonetaryAmountFactories_InstantesMustBeNotEqual)
[SUCCESS] 4.2.2 For each amount class, check isEqualTo().(ModellingMonetaryAmountsTest#testMonetaryAmount_isEqualTo)
[SUCCESS] 4.2.2 For each amount class, check isEqualTo(), regardless different MonetaryContext instances.(ModellingMonetaryAmountsTest#testMonetaryAmount_isEqualToRegardlessMonetaryContext)
[SUCCESS] 4.2.2 For each amount class, check isEqualTo(), regardless implementation type.(ModellingMonetaryAmountsTest#testMonetaryAmount_isEqualToRegardlessType)
[SUCCESS] 4.2.2 For each amount class, check isGreaterThan().(ModellingMonetaryAmountsTest#testMonetaryAmount_isGreaterThan)
[SUCCESS] 4.2.2 For each amount class, check isGreaterThanOrEquals().(ModellingMonetaryAmountsTest#testMonetaryAmount_isGreaterThanOrEquals)
[SUCCESS] 4.2.2 For each amount class, check isLessThan().(ModellingMonetaryAmountsTest#testMonetaryAmount_isLessThan)
[SUCCESS] 4.2.2 For each amount class, check isLessThanOrEqualTo().(ModellingMonetaryAmountsTest#testMonetaryAmount_isLessThanOrEqualTo)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication with exceeding values throws ArithmeticException.(ModellingMonetaryAmountsTest#testMultiplyExceedsCapabilities)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication of null throws NullPointerException.(ModellingMonetaryAmountsTest#testMultiplyNull)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication by one returns same instance.(ModellingMonetaryAmountsTest#testMultiplyOne)
[SUCCESS] 4.2.2 For each amount class, ensure correct multiplication of decimal values.(ModellingMonetaryAmountsTest#testMultiply_Decimals)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication of Double.NEGATIVE_INFINITY throws ArithmeticException.(ModellingMonetaryAmountsTest#testMultiply_DoubleNEGATIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication of Double.NaN throws ArithmeticException.(ModellingMonetaryAmountsTest#testMultiply_DoubleNaN)
[SUCCESS] 4.2.2 For each amount class, ensure multiplication of Double.POSITIVE_INFINITY throws ArithmeticException.(ModellingMonetaryAmountsTest#testMultiply_DoublePOSITIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure correct multiplication of int values.(ModellingMonetaryAmountsTest#testMultiply_Integral)
[SUCCESS] 4.2.2 For each amount class, test negate().(ModellingMonetaryAmountsTest#testNegate)
[SUCCESS] 4.2.2 For each amount class, test query().(ModellingMonetaryAmountsTest#testQuery)
[SUCCESS] 4.2.2 For each amount class, test query(), MonetaryQuery throws exception, MonetaryException expected.(ModellingMonetaryAmountsTest#testQueryInvalidQuery)
[SUCCESS] 4.2.2 For each amount class, test query(null), NullPointerException expected.(ModellingMonetaryAmountsTest#testQueryNull)
[SUCCESS] 4.2.2 For each amount class, ensure correct results for remainder.(ModellingMonetaryAmountsTest#testRemainder)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(null), throws NullPointerException.(ModellingMonetaryAmountsTest#testRemainderNull)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(0), double, throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainderZero_Double)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(0), long, throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainderZero_Long)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(0), Number, throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainderZero_Number)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(Double.NEGATIVE_INFINITY), throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainder_DoubleNEGATIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(Double.NaN), throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainder_DoubleNaN)
[SUCCESS] 4.2.2 For each amount class, ensure remainder(Double.POSITIVE_INFINITY), throws ArithmeticException.(ModellingMonetaryAmountsTest#testRemainder_DoublePOSITIVE_INFINITY)
[SUCCESS] 4.2.2 For each amount class, ensure scaleByPowerOfTen(1) returns correct results.(ModellingMonetaryAmountsTest#testScaleByPowerOfTen)
[SUCCESS] 4.2.2 For each amount class, test signum().(ModellingMonetaryAmountsTest#testSignum)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of mixed fractions.(ModellingMonetaryAmountsTest#testSubtractMixedFractions)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of mixed ints.(ModellingMonetaryAmountsTest#testSubtractMixedIntegers)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of negative ints.(ModellingMonetaryAmountsTest#testSubtractNegativeIntegers)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of positive fractions.(ModellingMonetaryAmountsTest#testSubtractPositiveFractions)
[SUCCESS] 4.2.2 For each amount class, ensure correct subtraction of positive ints.(ModellingMonetaryAmountsTest#testSubtractPositiveIntegers)
[SUCCESS] 4.2.2 For each amount class, ensure subtraction with exceeding capabilities throws ArithmeticException.(ModellingMonetaryAmountsTest#testSubtract_ExceedsCapabilities)
[SUCCESS] 4.2.2 For each amount class, ensure subtraction with invalid currency throws MonetaryException.(ModellingMonetaryAmountsTest#testSubtract_IncompatibleCurrencies)
[SUCCESS] 4.2.2 For each amount class, ensure subtraction with null throws NullPointerException.(ModellingMonetaryAmountsTest#testSubtract_Null)
[SUCCESS] 4.2.2 For each amount class, ensure subtraction of 0 returns same instance.(ModellingMonetaryAmountsTest#testSubtract_Zero)
[SUCCESS] 4.2.2 For each amount class, test with().(ModellingMonetaryAmountsTest#testWith)
[FAILED]  4.2.2 For each amount class, test with().(ModellingMonetaryAmountsTest#testWith4ProvidedOperators):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingMonetaryAmountsTest.testWith4ProvidedOperators(ModellingMonetaryAmountsTest.java:2285)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.2 Bad case: For each amount class, test with(), operator throws exception.(ModellingMonetaryAmountsTest#testWithInvalidOperator)
[SUCCESS] 4.2.2 Bad case: For each amount class, test with(null), expected NullPointerException.(ModellingMonetaryAmountsTest#testWithNull)
[FAILED]  4.2.2 Bad case: For each amount class, test with(), operator throws exception.(ModellingMonetaryAmountsTest#testWithNull4ProvidedOperators):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.ModellingMonetaryAmountsTest.testWithNull4ProvidedOperators(ModellingMonetaryAmountsTest.java:2366)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances are accessible for all amount types under test.(CreatingMonetaryAmountsTest#testAccessToMonetaryAmountFactory)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create zero amounts from a factory with an invalid currency.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateAmountsWithInvalidCurrency)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create zero amounts from a factory with an invalid MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateAmountsWithInvalidMonetaryContext)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts, with no currency, expect MonetaryException.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateNegativeInvalidContext_BadCase)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts, with invalid currency, expect MonetaryException.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateNegativeInvalidCurrency_BadCase)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts, with no currency, expect MonetaryException.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateNegativeNoCurrency_BadCase)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create positive amounts.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWitCurrencies)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create positive amounts with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWithContexts)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create positive amounts using doubles with explicit MonetaryContext (precision/scale).(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWithContexts2)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create positive amounts using BigDecimal with explicit MonetaryContext (precision/scale).(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWithContexts3)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create positive amounts using invalid numbers, expecting ArithemticException thrown.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveAmountsWithInvalidNumber)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts with an invalid currency, expecting MonetaryException thrown.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveInvalidContext_BadCase)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts with an invalid currency, expecting MonetaryException thrown.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveInvalidCurrency_BadCase)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts without currency, expecting MonetaryException thrown.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreatePositiveNoCurrency_BadCase)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances support creation of 0 amounts, with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateZeroAmountsWithDiffContexts)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances support creation of 0 amounts, with different explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateZeroAmountsWithDiffContexts2)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances support creation of 0 amounts, with different explicit MonetaryContext (precision, scale).(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateZeroAmountsWithDiffContexts3)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances support creation of 0 amounts.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryCreateZeroAmountsWithDiffCurrencies)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances accessible for all amount types under test return correct min/max MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryMinMaxCapabilities)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances accessible for all amount types under test return correct min/max MonetaryContext (min <= max).(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryMinMaxCapabilities_Compare)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create negative amounts.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWitCurrencies)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create negative amounts, with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWithContexts)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create negative amounts, with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWithContexts2)
[SUCCESS] 4.2.6 For each MonetaryAmount Factory: Create negative amounts, with explicit MonetaryContext.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWithContexts3)
[SUCCESS] 4.2.6 Bad case: For each MonetaryAmount Factory: Create negative amounts, with invalid numeric value, expect ArithmeticException.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryNegativePositiveAmountsWithInvalidNumber)
[SUCCESS] 4.2.6 Ensure MonetaryAmountFactory instances accessible for all amount types under test return correct amount type.(CreatingMonetaryAmountsTest#testMonetaryAmountFactoryReturnsCorrectType)
[SUCCESS] 4.2.7 Ensure the types available, must be at least one type.(CreatingMonetaryAmountsTest#testMonetaryAmountTypes_Available)
[SUCCESS] 4.2.3 Checks if a correct Double value is returned, no truncation is allowed to be performed.(ExternalizingNumericValueTest#testDoubleNegative)
[SUCCESS] 4.2.3 Check if a correct double value is returned, truncation is allowed to be performed (but is not necessary).(ExternalizingNumericValueTest#testDoubleValueWithTruncationZero)
[SUCCESS] 4.2.3 Checks if a correct double value is returned, truncation is allowed to be performed.(ExternalizingNumericValueTest#testDoubleWithTruncationNegative)
[SUCCESS] 4.2.3 Checks if a correct Integer value is returned, no truncation is allowed to be performed.(ExternalizingNumericValueTest#testIntegerNegative)
[SUCCESS] 4.2.3 Check if a correct integer value is returned, truncation is allowed to be performed. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testIntegerValueWithTruncationZero)
[SUCCESS] 4.2.3 Check if a correct integer value is returned, truncation is allowed to be performed..(ExternalizingNumericValueTest#testIntegerWithTruncationNegative)
[SUCCESS] 4.2.3 Check if a correct integer value is returned, no truncation is  allowed to be performed.(ExternalizingNumericValueTest#testIntegerZero)
[SUCCESS] 4.2.3 Checks if a correct negative long value is returned, no truncation is allowed to be performed.(ExternalizingNumericValueTest#testLongNegative)
[SUCCESS] 4.2.3 Check if a correct long value is returned, truncation is allowed to be performed. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testLongValueWithTruncationZero)
[SUCCESS] 4.2.3 Checks if a correct long value is returned, truncation is allowed to be performed.(ExternalizingNumericValueTest#testLongWithTruncationNegative)
[SUCCESS] 4.2.3 Check if a correct long zero value is returned, no truncation is  allowed to be performed.(ExternalizingNumericValueTest#testLongZero)
[SUCCESS] 4.2.3 Ensure NumberValue numberValue() works correnctly.(ExternalizingNumericValueTest#testNumberTypeNegative)
[SUCCESS] 4.2.3 Checks if number type is not null and returning a concrete (no abstract class or interface).(ExternalizingNumericValueTest#testNumberTypeZero)
[SUCCESS] 4.2.3 Checks if a correct long value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative)
[SUCCESS] 4.2.3 Checks if a correct double value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Double)
[SUCCESS] 4.2.3 Checks if a correct double value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Float)
[SUCCESS] 4.2.3 Checks if a correct int value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Integer)
[SUCCESS] 4.2.3 Checks if a correct Number value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Long)
[SUCCESS] 4.2.3 Checks if a correct double value is returned, truncation is allowed to be performed. Check should be done for every JDK type.(ExternalizingNumericValueTest#testNumberValueWithTruncationNegative_Short)
[SUCCESS] 4.2.3 Check if a correct Number value is returned, truncation is allowed to be performed. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testNumberValueWithTruncationZero)
[SUCCESS] 4.2.3 Check if a correct long zero value is returned, no truncation is  allowed to be performed.(ExternalizingNumericValueTest#testNumberValueZero)
[SUCCESS] 4.2.3 Check if a correct number value is returned, truncation is  allowed to be performed. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testNumberWithTruncationNegative)
[SUCCESS] 4.2.3 Test correct precision values, including border cases.(ExternalizingNumericValueTest#testPrecisionNegative)
[SUCCESS] 4.2.3 Ensure NumberValue getPrecision() works correctly.(ExternalizingNumericValueTest#testPrecisionValues)
[SUCCESS] 4.2.3 Check if a correct precision value is returned. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testPrecisionZero)
[SUCCESS] 4.2.3 Amount types do not return a NumberValue of null.(ExternalizingNumericValueTest#testReturningNumberValueIsNotNull)
[SUCCESS] 4.2.3 Test correct scale values, including border cases.(ExternalizingNumericValueTest#testScaleNegative)
[SUCCESS] 4.2.3 Ensure NumberValue getScale() works correctly.(ExternalizingNumericValueTest#testScaleValues)
[SUCCESS] 4.2.3 Check if a correct scale value is returned. Check should be done for every JDK type supported.(ExternalizingNumericValueTest#testScaleZero)
[SUCCESS] 4.2.3 Ensure NumberValue doubleValue(), doubleValueExact() provide correct values.(ExternalizingNumericValueTest#testValidDouble)
[SUCCESS] 4.2.3 Ensure NumberValue doubleValue() is truncated.(ExternalizingNumericValueTest#testValidDoubleWithTruncation)
[SUCCESS] 4.2.3 Ensure NumberValue intValue(), intValueExact() provide correct values.(ExternalizingNumericValueTest#testValidInteger)
[SUCCESS] 4.2.3 Ensure NumberValue intValue() is truncated.(ExternalizingNumericValueTest#testValidIntegerWithTruncation)
[SUCCESS] 4.2.3 Ensure NumberValue longValue(), longValueExact() provide correct values.(ExternalizingNumericValueTest#testValidLong)
[SUCCESS] 4.2.3 Ensure NumberValue longValue() is truncated.(ExternalizingNumericValueTest#testValidLongWithTruncation)
[SUCCESS] 4.2.3 Ensure NumberValue asType(BigDecimal.class) provides correct values.(ExternalizingNumericValueTest#testValidNumberBD)
[SUCCESS] 4.2.3 Ensure NumberValue asType(BigInteger.class) provides correct values.(ExternalizingNumericValueTest#testValidNumberBI)
[SUCCESS] 4.2.3 Ensure NumberValue byteValue() is truncated.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Byte)
[SUCCESS] 4.2.3 Ensure NumberValue doubleValue() is truncated.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Double)
[SUCCESS] 4.2.3 Ensure NumberValue floatValue() is truncated.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Float)
[SUCCESS] 4.2.3 Ensure NumberValue intValue() is truncated correctly.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Integer)
[SUCCESS] 4.2.3 Ensure NumberValue shortValue() is truncated.(ExternalizingNumericValueTest#testValidNumberWithTruncation_Short)
[FAILED]  4.2.4 Ensures the result of all operators under test is of the same class as the input.(FunctionalExtensionPointsTest#testOperatorReturnTypeEqualsParameter):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.FunctionalExtensionPointsTest.testOperatorReturnTypeEqualsParameter(FunctionalExtensionPointsTest.java:43)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.7 Access named roundings and ensure TCK named roundings are registered.(AccessingCurrenciesAmountsRoundingsTest#testAccessCustomRoundings)
[SUCCESS] 4.2.7 Ensure Monetary instances are available, for all registered currencies.(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsForCustomCurrencies_Default)
[SUCCESS] 4.2.7 Ensure Monetary instances are available, also for any custom currency (not registered).(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsForCustomCurrencies_Explicit)
[SUCCESS] 4.2.7 Expected NullPointerException accessing a rounding with 'Monetary.getRounding(null)'.(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsForCustomCurrencies_Explicit_Null)
[SUCCESS] 4.2.7 Ensure NullPointerException is thrown for 'Monetary.getRounding((RoundingContext) null)'.(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsWithMonetaryContext_Null)
[SUCCESS] 4.2.7 Ensure correct MonetaryRounding returned for a mathematical RoundingQuery.(AccessingCurrenciesAmountsRoundingsTest#testAccessRoundingsWithRoundingContext)
[SUCCESS] 4.2.7 Test if Monetary provides all ISO related entries similar to java.util.Currency.(AccessingCurrenciesAmountsRoundingsTest#testAllISOCurrenciesAvailable)
[SUCCESS] 4.2.7 Test if Monetary provides all locale related entries similar to java.util.Currency.(AccessingCurrenciesAmountsRoundingsTest#testAllLocaleCurrenciesAvailable)
[SUCCESS] 4.2.7 Ensure a default MonetaryAmountFactory is available.(AccessingCurrenciesAmountsRoundingsTest#testAmountDefaultType)
[SUCCESS] 4.2.7 Ensure correct query function, Monetary.getAmountFactories should return factoryfor explicit acquired amount types.(AccessingCurrenciesAmountsRoundingsTest#testAmountQueryType)
[FAILED]  4.2.7 Ensure amount factories are accessible for all types available in Monetary.(AccessingCurrenciesAmountsRoundingsTest#testAmountTypesInstantiatable):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.AccessingCurrenciesAmountsRoundingsTest.testAmountTypesInstantiatable(AccessingCurrenciesAmountsRoundingsTest.java:260)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[FAILED]  4.2.7 Ensure amount classes to test are setup and registered/available in Monetary.(AccessingCurrenciesAmountsRoundingsTest#testAmountTypesProvided):
java.lang.NoClassDefFoundError: Could not initialize class org.javamoney.tck.TCKTestSetup
	at org.javamoney.tck.tests.AccessingCurrenciesAmountsRoundingsTest.testAmountTypesProvided(AccessingCurrenciesAmountsRoundingsTest.java:235)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
	at org.testng.TestNG.run(TestNG.java:1057)
	at org.javamoney.tck.TCKRunner.main(TCKRunner.java:108)

[SUCCESS] 4.2.7 Test if Monetary provides correct ISO related entries similar to java.util.Currency.(AccessingCurrenciesAmountsRoundingsTest#testCorrectISOCodes)
[SUCCESS] 4.2.7 Test if Monetary provides correct locale related entries similar to java.util.Currency.(AccessingCurrenciesAmountsRoundingsTest#testCorrectLocales)
[SUCCESS] 4.2.7 Test if Monetary provides customized locale identified currencies.(AccessingCurrenciesAmountsRoundingsTest#testCustomCurrencies)
[SUCCESS] 4.2.7 Access custom roundings and ensure correct functionality.(AccessingCurrenciesAmountsRoundingsTest#testCustomRoundings)
[SUCCESS] 4.2.7 Ensure MonetaryException is thrown for accessing invalid named rounding.(AccessingCurrenciesAmountsRoundingsTest#testCustomRoundings_Foo)
[SUCCESS] 4.2.7 Ensure NullPointerException is thrown for Monetary.getRounding((String) null).(AccessingCurrenciesAmountsRoundingsTest#testCustomRoundings_Null)
[SUCCESS] 4.3.1 Access Conversion to term currency code XXX for all providers that support according conversion, ifavailable a non-null CurrencyConversion must be provided.(MonetaryConversionsTest#testConversionsAreAvailable)
[SUCCESS] 4.3.1 Access Conversion by query to term currency XXX for all providers that support according conversion, ifavailable a non-null CurrencyConversion must be provided.(MonetaryConversionsTest#testConversionsAreAvailableWithQuery)
[SUCCESS] 4.3.1 Access and test conversion using the default provider chain.(MonetaryConversionsTest#testDefaultConversion)
[SUCCESS] 4.3.1 Access and test the default conversion provider chain.(MonetaryConversionsTest#testDefaultProviderChainIsDefined)
[SUCCESS] 4.3.1 Access and test the default conversion provider chain, by accessing a defaultCurrencyConversion for term CurrencyUnit CHF.(MonetaryConversionsTest#testDefaultProviderChainIsDefinedDefault)
[SUCCESS] 4.3.1 Access and test the default conversion provider chain, by accessing a defaultCurrencyConversion for term currency code CHF.(MonetaryConversionsTest#testDefaultProviderChainIsDefinedDefault2)
[SUCCESS] 4.3.1 Access and test the default conversion provider chain, by accessing a defaultCurrencyConversion for ConversionQuery.(MonetaryConversionsTest#testDefaultProviderChainIsDefinedDefaultWithContext)
[SUCCESS] 4.3.1 Test if all ExchangeRateProvider instances returns valid ProviderContext.(MonetaryConversionsTest#testProviderMetadata)
[SUCCESS] 4.3.1 Test if all CurrencyConversion instances returns valid ConversionContext, accessed by currency code.(MonetaryConversionsTest#testProviderMetadata2)
[SUCCESS] 4.3.1 Test if all CurrencyConversion instances returns valid ConversionContext, accessed by ConversionQuery/currency code.(MonetaryConversionsTest#testProviderMetadata2WithContext)
[SUCCESS] 4.3.1 Test if all CurrencyConversion instances returns valid ConversionContext, accessed by CurrencyUnit.(MonetaryConversionsTest#testProviderMetadata3)
[SUCCESS] 4.3.1 Test if all CurrencyConversion instances returns valid ConversionContext, accessed by ConversionQuery/CurrencyUnit.(MonetaryConversionsTest#testProviderMetadata3WithContext)
[SUCCESS] 4.3.1 Ensure at least one conversion provider is available, TestRateProvider must be present.(MonetaryConversionsTest#testProvidersAvailable)
[SUCCESS] 4.3.1 Bad case: Access invalid ExchangeRateProvider, expect MonetaryException thrown, using default provider chain.(MonetaryConversionsTest#testUseInvalidProvider)
[SUCCESS] 4.3.1 Bad case: Access invalid ExchangeRateProvider, expect MonetaryException thrown, using explicit provider.(MonetaryConversionsTest#testUseInvalidProviderWithinChain)
[SUCCESS] 4.3.3 Test access of Conversion Rates, using TCK provided rate provider.(ExchangeRatesAndRateProvidersTest#testAccessKnownRates)
[SUCCESS] 4.3.3 Test access to exchange rates from TestRateProvider, using target CUrrencyUnit.(ExchangeRatesAndRateProvidersTest#testAccessKnownRatesAndContext)
[SUCCESS] 4.3.3 Test access to exchange rates from TestRateProvider, using target currency code.(ExchangeRatesAndRateProvidersTest#testAccessKnownRatesWithCodes)
[SUCCESS] 4.3.3  Test access to conversion rates, including known factor, using TestRateProvider.(ExchangeRatesAndRateProvidersTest#testAccessKnownRatesWithCodesAndContext)
[SUCCESS] 4.3.3 Test access to conversion rate for currency codes, using default provider.(ExchangeRatesAndRateProvidersTest#testAccessRates_IdentityRatesWithCodes)
[SUCCESS] 4.3.3 Test access to identity conversion rate for CurrencyUnits, using default provider(ExchangeRatesAndRateProvidersTest#testAccessRates_IdentityRatesWithUnits)
[SUCCESS] 4.3.3 Test access to conversion rate for CurrencyQuery, using default provider.(ExchangeRatesAndRateProvidersTest#testAccessRates_IdentityRatesWithUnitsAndContext)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with invalid base currency code.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_InvalidSourceCurrency)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null ConversionQuery.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_InvalidSourceCurrencyAndContext)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with invalid term currency code.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_InvalidTargetCurrency)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null base currency code.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_NullSourceCurrency)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null base CurrencyUnit.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_NullSourceCurrencyUnit)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null term currency code.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_NullTargetCurrency)
[SUCCESS] 4.3.3 Bad case: try accessing exchange rates with null term CurrencyUnit.(ExchangeRatesAndRateProvidersTest#testInvalidUsage_NullTargetCurrencyUnit)
[SUCCESS] 4.3.3 Ensure additional ConversionQuery data is passed correctly to SPIs.(ExchangeRatesAndRateProvidersTest#testPassingOverConversionContextToSPIs)
[SUCCESS] 4.3.2 Test successful conversion for CHF -> FOO, using TestRateProvider.(ConvertingAmountsTest#testConversion)
[SUCCESS] 4.3.2 Test correct ExchangeRate is returned for CHF -> FOO, using TestRateProvider.(ConvertingAmountsTest#testConversionComparedWithRate)
[SUCCESS] 4.3.2 Bad case: Access CurrencyConversion with a CurrencyUnit==null, ensure NullPointerException is thrown.(ConvertingAmountsTest#testNullConversion1)
[SUCCESS] 4.3.2 Bad case: Access CurrencyConversion with a currency code==null, ensure NullPointerException is thrown.(ConvertingAmountsTest#testNullConversion2)
[SUCCESS] 4.3.2 Bad case: Try CurrencyConversion to an inconvertible (custom) currency (FOOANY), ensure CurrencyConversionException is thrown.(ConvertingAmountsTest#testUnsupportedConversion)
[SUCCESS] 4.3.4 Test correct rate evaluation for different conversion provider chains, with historic rates.(ProviderChainsTest#testCorrectRateEvaluationInChainHistoric)
[SUCCESS] 4.3.4 Test correct rate evaluation for different conversion provider chains.(ProviderChainsTest#testCorrectRateEvaluationInChain_diffProviders)
[SUCCESS] 4.3.4 Test correct rate evaluation for different conversion provider chains, with duplicate provider entries.(ProviderChainsTest#testCorrectRateEvaluationInChain_sameProviders)
[SUCCESS] 4.3.4 Test availability of TCK provided providers.(ProviderChainsTest#testTCKRateChainAvailability)
[SUCCESS] 4.4.3 Ensures for each locale defined by DecimalFormat.getAvailableLocales() a MonetaryFormats.getAmountFormat(AmountFormatQuery) returns a formatter.(FormattingMonetaryAmountsTest#testAmountStyleOf)
[SUCCESS] 4.4.1 Formats amounts using all available locales.(FormattingMonetaryAmountsTest#testFormattingIsIndependentOfImplementation)
[SUCCESS] 4.4.3 Ensures for each locale defined by DecimalFormat.getAvailableLocales() a MonetaryAmountFormat instance is provided.(FormattingMonetaryAmountsTest#testGetAmountFormat)
[SUCCESS] 4.4.3 Ensures for each locale defined by DecimalFormat.getAvailableLocales() a MonetaryFormats.isAvailable(Locale) is true.(FormattingMonetaryAmountsTest#testGetAvailableLocales)
[SUCCESS] 4.4.3 Ensures all Locales defined by DecimalFormat.getAvailableLocales() are available for monetary formatting.(FormattingMonetaryAmountsTest#testLocalesSupported)
[SUCCESS] 4.4.1 Ensures the system.s default locale is supported for MonetaryAmountFormat.(FormattingMonetaryAmountsTest#testNoDepOnAmountImplementation)
[SUCCESS] 4.4.2 Test formats and parses (round-trip) any supported amount type for each supported Locale, using different format queries.(FormattingMonetaryAmountsTest#testParseDifferentStyles)
[SUCCESS] 4.4.1 Test formats and parses (round-trip) any supported amount type for each supported Locale.(FormattingMonetaryAmountsTest#testParseIsIndependentOfImplementation)
[SUCCESS] 4.4.1 Test formats and parses (round-trip) any supported amount type for each supported Locale, checks results for different currencies(FormattingMonetaryAmountsTest#testParseWithDifferentCurrencies)

JSR 354 TCK, version 1.0 Summary
------------------------------------------

TOTAL TESTS EXECUTED : 233
TOTAL TESTS SKIPPED  : 0
TOTAL TESTS SUCCESS  : 222
TOTAL TESTS FAILED   : 11

-- JSR 354 TCK  finished --

All dependencies show the 1.0.1-RC0 versions of the moneta, moneta-core, moneta-convert-ecb and moneta-convert-imf are used.

Comment by otaviojava [ 31/Jul/15 ]

Werner.
Maybe you did a little confusion with physical module with logical module.

Example:
The Swing module is together physically, in the same folder (java.desktop), but on different logical module, in different package.

If you look to swing module, all classes are on the same physical module:

But we have different packages, in other words, different logical module:

  • javax.swing.border
  • javax.swing.colorchooser

The same thing will happen with javax.money, it stay together, all core, just there is logic module, it will split by package.
The initial proposal to split the core to the exchange rate is because neither we and OpenJDK team can't provide, support, ensure availability, perform maintenance, etc. on third service such IMF or ECB service.
So we will propose just the core to him, following the openjdk standard, using logical modules, in other words, just the core modularized by packages.

Referencies:

Comment by keilw [ 31/Jul/15 ]

Conversion is a logical module. Its need is determined if an application requires multiple currencies or just one.
ECB and IMF providers are not "Third Party", they are developed by us, the EG. We don't provide the rates, but with currency codes, timezones, etc. that keeps happening all the time in JDK. Java also checks for new versions every time you call it on the web, so "Update Checks" are the daily bread of the JDK for a long time. Convert without at least one or two default providers is worthless, thus you can either chose to use conversion or not.

Java SE (as of 8) comes in 3 different profiles. With Java 9 while it's still a while till the final release there will be more such profiles.
And a Modular Moneta will offer at least 2 profiles, too. "Minimal" (essentially moneta-core) and "Full" including the convert feature.

And in future versions of the API similar to pioneers (JSR 361, 363) some packages like "javax.money.convert" could well be optional, but compared to Moneta (~700kb for the 1.0 JAR) the API JAR is only around 10% in size.

The Minimal profile of Moneta is only around 200kb while the Full profile is comparable to 1.0 in size.

Comment by otaviojava [ 31/Jul/15 ]

Are you sure about this?
Did the EC make the service or the client side of the IMF and ECB?
I believe just the client, isn't?
I means, if the either site of IMF or ECB down, how do you will give support to it, do you have available guarantee?
Do you have guarantee of this service will never change the serialization?
If the IMF or ECB give a wrong rate how do we will fix it?

Comment by keilw [ 31/Jul/15 ]

The EC is not making anything but vote on it
And since both IMF and ECB providers are part of the RI, of course the EG

Both IMF and ECB are international institutions. Exchange rates are used by Millions of business transactions around the globe. While not necessarily real time (that's where Third Party commercial providers may come into play, just like people with special demands may buy Azul's JVM rather than using the free Oracle or OpenJDK versions) they are business-critical, so don't worry about them going away. Both institutions are involved in say keeping Greece from bankruptcy. Should a country like Greece do go bust then the JDK had to be updated in the past to handle new currencies. Same if new states arise like Kosovo, South Sudan or East Timor.

Similar to Unicode CLDR which is updated on a regular basis and used by every Java version, their services have to be reliable. In the unlikely event any of them changed something drastically, we should have CI servers running such Integration tests (as opposed to simply calling them Unit Tests right now) on a daily basis, even if there is no Git push. If a test fails, we'll get notified and may offer a fix pack.
It certainly won't happen as often as new critical security flaws in Java or other languages are found

Similar to ECB (being composed of most EU countries and their National Banks) IMF is an International body, related to the UN: http://www.ngohandbook.org/index.php?title=International_Monetary_Fund_(IMF)_and_NGOs
The UN may sometimes be easy to block by just one veto member (somewhat similar to Oracle in the JCP ) but it won't just "go away" nor do its websites or services.

Comment by otaviojava [ 01/Aug/15 ]

I have never told different stuff about it, both IMF and ECB are respected institution in all the world.
But Does it mean their software can't take a bug, infrastructure problem, etc.?
Java, linux is also are a respected in the all world, so I can say: do they cannot have a bug or problem?
The fact is, if there is a problem on MonetaryAmount implementation either we or the openjdk team can fix it.
But when it there a problem on the third service, how do we can fix it?

Comment by keilw [ 01/Aug/15 ]

This entire thread belonged to https://java.net/jira/browse/JAVAMONEY-140 because it has nothing to do with the TCK itself, so I'll answer there and if you have any more feedback please do there, too

Comment by keilw [ 01/Aug/15 ]

Most arguments and comments actually belong to the Conversion module





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-140] Convert Module Created: 16/Jul/15  Updated: 01/Aug/15

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

Type: Sub-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

Issue Links:
Related
is related to JAVAMONEY-141 Pass TCK In Progress

 Comments   
Comment by keilw [ 28/Jul/15 ]

Something went wrong here recently
A lot of good changes were "merged away" somehow. And convert-related classes in core again.
Need to fix otherwise true modularization won't work.

Comment by otaviojava [ 28/Jul/15 ]

@keliw
All changes proposed to modularization by public list was made and the TCK passed.
I believe it`s ok.

Comment by keilw [ 28/Jul/15 ]

No, the proposal was not about creating some rudimentary conversion providers, it was about true modularization of the conversion sub-system.
And "moneta" contains stuff that does not belong there.

Comment by keilw [ 28/Jul/15 ]

The mailing list was clear about

moneta-core (primarily root package, spi, loader and likely functional package which is also reused)
moneta-convert
moneta-convert-ecb
moneta-convert-imf
moneta-format

And moneta-convert did not mean just an "umbrella" POM, it means everything that lies under "moneta.internal.convert" and similar packages with dependency to javax.money.convert

Sorry for possible misconception, but that is true modularization, not just cutting a few pieces out.

Comment by otaviojava [ 28/Jul/15 ]

Please, check again.
There isn't this on email list.
There is a picture about it.
The main goal of this issue is split the exchange-rate.
I know it because I send the email and create the proposal.

Comment by keilw [ 28/Jul/15 ]

That was exactly from the mailing list.
And modularization means more than this. There will be more (even for too bloated parts like java.time, they might be thrown into some giant "core") of that in Jigsaw, and the aim was to create a jigsaw capable fully modular convert, meaning no dependency to javax.money.convert in core, allowing the conversion as a whole to be optional. Everything else makes no sense and would require to do it all again.

Comment by otaviojava [ 28/Jul/15 ]

Werner, this proposal was sent as first step.
If you want do this, please create a new proposal with these modification.

Comment by keilw [ 28/Jul/15 ]

Btw. this is wrong (also have chance to fix it) initializing a mandatory variable in a separate @Test

    @Test
    public void init() {
        provider = new ExchangeRateProviderMock();
    }

JUnit or TestNG don't guarantee in what order tests are executed, they may happen on separate threads in parallel which would cause NPEs.
Will move it to @Before or similar to fix this.

Comment by otaviojava [ 28/Jul/15 ]

Thanks, but don't worry I did it.

Comment by keilw [ 28/Jul/15 ]

Please do not commit to that branch while I'm fixing it

Comment by keilw [ 28/Jul/15 ]

The TCK gave errors because of circular dependencies e.g. the moneta "JAR" module defining convert stuff while then using convert again. Only one of the biggest problems.

Comment by otaviojava [ 28/Jul/15 ]

Werner, again
Don't commit in this branch, please, create own branch with your proposal.
There isn't circular dependency.

Comment by keilw [ 28/Jul/15 ]

The proper branch already exists. with clean modularization.
Tests in some "core" module show clearly they refer to ECBconversion or IMFConversion. As soon as dependencies are clarified and resolved these show what was wrong.

Last but not least each module must be an OSGi bundle, otherwise they are worthless for Jigsaw when it comes (there are already bridging projects, so a proper OSGi bundle will work as proper Jigsaw module, too)

Comment by otaviojava [ 28/Jul/15 ]

You can create a new branch using this branch as base.
To do this you can use the command:

git chechout -b new_branch
Comment by keilw [ 28/Jul/15 ]

long done

But the 2 branches must not build into the same snapshot, this way the dependencies are mixed up on JFrog

Comment by keilw [ 01/Aug/15 ]

@otavio your concerns about ECB or IMF may have good intentions, but they are without reason. These organizations bail out entire countries. Should Brazil due to current economic crisis go bankrupt like its neighbor Argentinia did before, the IMF will help them. Apache Foundation, Eclipse Foundation, Linux Foundation or even Oracle's Open Source efforts like OpenJDK are NGOs funded by a few big corporate donors (often to save taxes at least in the US ) Being ApacheCon speaker again this year, there similar to EclipseCon these NGOs report transparently on their budget, but usually we're talking in the range of 1 Mio. $ or a 7 digit amount at most. That's less than the interest IMF or ECB gets by large "problem children" like Greece each month!

They normally do this as transparent as possible. And public APIs like the ones we consume are part of that transparency. So it's in their DNA and highest interest to provide them. Occasional hacks by the likes of Anonymous, well, everyone who is exposed gets these today, even the White House or Pentagon.

Glassfish was practically disintegrated by Oracle, so the amount of donation both time and money by a few or just one big corporate donor is much more volatile than either of these economic institutions. Larry alone could pull the plug on OpenJDK at any time if he wanted, but there is not a single country that could destroy or stop the IMF, neither Greece nor the USA, though they probably have a certain stake bigger than others

Comment by otaviojava [ 01/Aug/15 ]

Werner, the proposal of one service be working. I know, but its not change the fact of we cannot provide the support to their service.

Comment by otaviojava [ 01/Aug/15 ]

Just moving this argument to here. once I believe it's important:

Werner.
Maybe you did a little confusion with physical module with logical module.

Example:
The Swing module is together physically, in the same folder (java.desktop), but on different logical module, in different package.

If you look to swing module, all classes are on the same physical module:

But we have different packages, in other words, different logical module:

  • javax.swing.border
  • javax.swing.colorchooser

The same thing will happen with javax.money, it stay together, all core, just there is logic module, it will split by package.
The initial proposal to split the core to the exchange rate is because neither we and OpenJDK team can't provide, support, ensure availability, perform maintenance, etc. on third service such IMF or ECB service.
So we will propose just the core to him, following the openjdk standard, using logical modules, in other words, just the core modularized by packages.

Referencies:

Comment by keilw [ 01/Aug/15 ]

Yes, so our "java.desktop" in Moneta is "moneta.convert". Which consists of

  • org.javamoney.moneta.convert
  • org.javamoney.moneta.internal.convert
  • org.javamoney.moneta.convert.ecb
  • org.javamoney.moneta.convert.imf

Plus a few classes e.g. in "spi" that in the near future should be moved to a proper package (since packages also allow version control like OSGi bundles if Jigsaw becomes usable reality)

like "java.desktop" can be used or not in Java 9, the whole conversion can be either used or left away.
In fact, since java.desktop also has AWT under the hood, moneta-convert is much more like AWT and the providers similar to Swing on top of that.
Oracle may not offer them separately in Java 9 because the number of pure AWT apps is too small or they just want people to use either Swing or JavaFX, but Swing is an extention to AWT and could be left out while pure "native" AWT apps would still run without it.

So the properly modularized branch does exactly what you mention, it offers 2 logical modules

  • core
  • convert
    Where the latter comes with sub-modules or built-in extensions, which in a future (not before Java 10 as it seems) version some of them could be optional.

As Anatole said, having absolutely none will not make sense, but users may chose between those two or others if we come across viable (Free and offered by an accepted global institution like IMF or ECB) alternatives by then. Maybe the "BRICS" countries do come up with their own system, but until that even provices an API I guess we'd at least see Java 9 Final or even 10

Comment by otaviojava [ 01/Aug/15 ]

Werner,
The logical module happen on split by package, qualified.
If we are submit with this dependency, include the exchange rate provider. The code is already done to it on the master.
I just doubt strongly the Java SE team will accept the implementation whose need internet and third service.

Comment by keilw [ 01/Aug/15 ]

The fully modulariized branch (based on the one you started ) https://github.com/JavaMoney/jsr354-ri/tree/properly_modularized_moneta has moneta-core without a single reference to javax.money.convert.
At least all Money types and their toString() helper refers to javax.money.format, thus it makes less sense to offer that as a module right now. Formatting while there are local specialties (e.g. Indian Cr. or Lkh JavaMoney DOES take care of, while OpenJDK still fails them ) rarely depends on regular updates like conversion. And if conversion was optional on the API level iit might even make it easier for persistent business-denying libraries like JodaMoney to implement JSR 354
JodaTime and JSR 310 are equaly business-denying since they lack basic features like a holiday calendar, something ICU4J got for ages...
This might require occasional updates from the internet, but hey, JodaTime offers updates almost every month for some TZ cosmetics or bug fixes

Comment by otaviojava [ 01/Aug/15 ]

Werner I mean, modularized looking to OpenJDK concert that I showed the code on last comment.
The OpenJDK does not use maven project.

Comment by keilw [ 01/Aug/15 ]

Otavio, I think while browsing the code of Java 9 you still don't get how Oracle aims to distribute and regularly update it .
Over the Internet

Should they have a problem with Convert as a whole, then making that modular and optional solves their problems even more or that of people who may be behind a strong, intrusive firewall (of course they would likely not even get the full Java 9 or 10 this way either )
Nobody bothered creating a JEP, so we talk about some Sci-fi possibility beyond Java 10 (if JEP isn't filed soon, it won't be 10 but 11 or 12!)
The feature branch for 1.0,1 is reality, and meets all requirements to be used either via a SP or at least MR (if Anatole and/or CS were to prefer that)

What's currently in master is broken and polluted anyway. The whole "Conversion Operator" stuff breaks proper modularity, that's why the properly modularized branch is the future and contains both, but cleanly separated into Core and Convert

Comment by keilw [ 01/Aug/15 ]

Gradle is Maven
They use exactly the same dependency mechanism and Mark Reinhold explicitely referred to Maven or MavenCentral, so do the specs for Jigsaw.
It must be compatible with Maven, Gradle and likely some even still use Ant/Ivy, so it's also using that.

Don't worry about Hg either, who knows what Java 10 or 11 will use by 2018 (that's the earliest a "jdk.money" module might be worth a thought from Oracle's perspective)

Comment by otaviojava [ 01/Aug/15 ]

Yes, you are right, we have no idea if the money go and when.
I believe, maybe, we just freeze this issue when it be really necessary.
Just stay the branch alive and rebasing with the master, when it and if be necessary will almost done. Do a code looking to speculation is not good.

Comment by keilw [ 01/Aug/15 ]

We don't have to release a 1.0.1 build any time soon either.
In fact, as it's no secret, Anatole is moving to a new company by the end of this month. And from an administrative point CS is the Spec Lead/Maintenance Lead, so unless there was a transition (similar to what Liferay just took over from Oracle with the Portlet Bridge ) or another company/individual joined as Co ML (that also happened, see Antoine with CDI before V2) we better wait till that is sorted out before even publishing a 1.0.1 version.
Unless there's a critical bug that would prevent users of 1.0 from doing their job.

For that the 1.0 branch is closest to the Final state and critical bug-fixes should be applied there or to a new branch off 1.0

Comment by otaviojava [ 01/Aug/15 ]

That's the point, we have stuff a lot on the master that include bug fixes, etc. I have more time to release the next version than Ubuntu, and Ubuntu is a S.O (the ubuntu release a version each six month).
I believe we need to run this process on parallel, mainly because we need to have a meeting with the OpenJDK team before. And just merge to master when necessary.
Make the monomodule stable is a really good stuff.





[JAVAMONEY-120] Inconsistency of "convert" elements in RI Created: 15/May/15  Updated: 15/May/15

Status: In Progress
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0.1
Fix Version/s: None

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVAMONEY-122 "Clone" conversion classes currently ... Sub-task In Progress keilw  
Tags: design, inconsistency, naming, package

 Description   

I noticed, ExchangeRateType, DefaultExchangeRate (though not a public class) or ExchangeRateBuilder are all in the top "moneta" package,
while a new class HistoricConversionQueryBuilder was created in a "convert" package of the RIs.

All of them refer to API elements like javax.money.convert.ConversionContext. For simplification "internal.convert" classes were put to the root package, but at least one was newly created in its own package. This is confusing and should be resolved.

Either by removing HistoricConversionQueryBuilder and "convert" (by making it @deprecated and putting a copy to the other place except for non-public elements) or moving the mentioned classes to "convert" instead (also treating them the same at least for an SP or two)



 Comments   
Comment by otaviojava [ 15/May/15 ]

I did: https://github.com/JavaMoney/jsr354-ri/pull/104

I moved this class to the root of moneta, if you have advise, please let me know by PR.

Comment by keilw [ 15/May/15 ]

This should be properly discussed, please don't RUSH anything before a consensus is reached where to locate ALL conversion-relevant classes.
As internal also contains a convert sub-package, there is some reason behind adding this to the root package, too and relocate classes previously in a wrong place.

Those MUST however be kept in both places so code that's using Moneta 1.0 doesn't break (deprecated it at least for several versions, if it was already part of the JDK we'd be in a bigger pickle here )





Inconsistency of "convert" elements in RI (JAVAMONEY-120)

[JAVAMONEY-122] "Clone" conversion classes currently in Moneta root package Created: 15/May/15  Updated: 17/May/15

Status: In Progress
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0.1
Fix Version/s: None

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

Tags: conversion, design, modules

 Description   

To improve modularization of RI elements, the following classes in the root package of Moneta should be "cloned" into convert

  • ExchangeRateType
  • ExchangeRateBuilder
  • DefaultExchangeRate (though not a public class, but it goes with above)

To avoid breaking existing code, they must remain in their original location at least till some versions (if we wait for the first MR or not has to be discussed) down the road, but be @deprecated pointing to the new types to use.



 Comments   
Comment by keilw [ 17/May/15 ]

ExchangeRateType is practically unused. Mostly by JUnit tests (which are in fact already in the "convert" sub-package ) so started by cloning it, but leaving old version @deprecated for the time being.





[JAVAMONEY-142] Define some tests as "integration-test" Created: 27/Jul/15  Updated: 27/Jul/15

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

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

Tags: test

 Description   

Some CI servers like Circle-CI call mvn integration-test by default. For those tests in need of external services by ECB, IMF, Yahoo, etc. we should try to rebrand them into "Integration Tests" and run them separately or optionally where necessary. See http://stackoverflow.com/questions/1399240/how-do-i-get-my-maven-integration-tests-to-run






[JAVAMONEY-104] Make coverage visible on all key artifacts Created: 13/May/15  Updated: 31/Jul/15

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

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

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.






Generated at Mon Aug 03 23:59:02 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.