[UNITSOFMEASUREMENT-180] Code Coverage Created: 26/Jan/16  Updated: 02/Jul/16  Resolved: 02/Jul/16

Status: Resolved
Project: unitsofmeasurement
Component/s: API, RI
Affects Version/s: 0.8
Fix Version/s: 0.9

Type: Improvement Priority: Critical
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: coverage, test, testing
Epic Link: Test
Sprint: Final Draft

 Description   

As suggested by LJC we should increase the code coverage of RI and by that where possible API (mostly instantiated through RI, so where feasible those coverage reports should also take "javax.measure" into consideration)



 Comments   
Comment by keilw [ 08/Feb/16 ]

Similar to JSR 354 (https://github.com/JavaMoney/jsr354-api and https://github.com/JavaMoney/jsr354-ri) the build chain should propagate JaCoCo findings to a Coveralls service for JSR 363.

Comment by keilw [ 11/Feb/16 ]

Set up for https://github.com/unitsofmeasurement/unit-api. The coverage only includes classes (as other tools like Cobertura also seem to do) so the API project includes just 6 concrete classes. Mostly exceptions are never thrown by API level unit tests, so we should add more tests to increase coverage rather easily. Whether or not other free and open tests also would cover interfaces, we could see, but generally these are primarily tested by the TCK.

Comment by keilw [ 02/Jul/16 ]

If RI could reach more than 60% it would be nice, but it's a good result so far (e.g. other JSRs like 354 are at 65% till now)





Create TCK (UNITSOFMEASUREMENT-101)

[UNITSOFMEASUREMENT-176] Consider dropping SPI profile from TCK Created: 28/Dec/15  Updated: 03/Apr/16  Resolved: 03/Apr/16

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: 0.8
Fix Version/s: 0.9

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

Issue Links:
Blocks
blocks UNITSOFMEASUREMENT-101 Create TCK Resolved
Tags: profile, test, testing
Sprint: Q1/15, Final Draft

 Description   

It seems, the "spi" profile for the TCK has more or less the same effect as "full". So we might consider dropping it for the sake of simplicity.



 Comments   
Comment by keilw [ 03/Apr/16 ]

Actually SPI covers "core", "format" and "spi" groups, but does not require a full or partial set of quantities. Therefore it makes sense to keep both.





Create TCK (UNITSOFMEASUREMENT-101)

[UNITSOFMEASUREMENT-174] Consider using Reflections.org for TCK Created: 21/Dec/15  Updated: 30/Mar/16  Resolved: 08/Feb/16

Status: Resolved
Project: unitsofmeasurement
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: test
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks UNITSOFMEASUREMENT-101 Create TCK Resolved
Tags: test, utils
Sprint: Q1/15, Final Draft

 Description   

Instead of low level reflection some of the TCK could use Reflections.org (https://github.com/ronmamo/reflections) especially its ReflectionUtils or similar helper classes.






Create TCK (UNITSOFMEASUREMENT-101)

[UNITSOFMEASUREMENT-169] Consider additional profile(s) for TCK Created: 24/Nov/15  Updated: 30/Mar/16  Resolved: 28/Dec/15

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: 0.8
Fix Version/s: 0.9

Type: Sub-task Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: test
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks UNITSOFMEASUREMENT-101 Create TCK Resolved
Related
is related to UNITSOFMEASUREMENT-129 JDK6 compatibility for unit-ri Resolved
Tags: profile, test
Sprint: Q1/15, Final Draft

 Description   

Given at least some Embedded solutions in need of JSR 363 expressed they have dependencies as far back as Java 5, not just 6, as well as being more flexible on smaller devices, we should consider adding another profile or two.

"spi" includes the Bootstrap class which uses Java ServiceLoader (also on ME 8 Embedded a standard, hence it's available even on smaller ME devices) a feature introduced with Java 6. Thus, if a Java 5 "backport" of the RI wants to use the API without changing or porting it, too, all other packages except "spi" seem compatible with that. Hence combining "format" and "quantity" (if also doing so for "base_quantity" is necessary, please share your thoughts) into at least one more profile sounds like a good idea. Chaining profiles similar to say Maven would be an alternative, but it would complicate calling the TCK, so while groups inside a profile are flexible, I'd rather keep the selected profile as one (also similar to e.g. Java SE or EE)



 Comments   
Comment by keilw [ 24/Nov/15 ]

The issue also refers to Java 5/6 compatibility. Especially Java 5 won't support SPI/ServiceLoader, therefore a combination of "format" and other optional packages than "spi" makes sense for such environments.





Portability of TCK (UNITSOFMEASUREMENT-153)

[UNITSOFMEASUREMENT-160] Configure Profiles for TCK Created: 03/Sep/15  Updated: 04/Sep/15  Resolved: 04/Sep/15

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: None
Fix Version/s: 0.8

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

Tags: portability, profile, test, testing
Sprint: Public Draft

 Description   

Similar to Java EE or ME, the TCK should allow to execute only parts that apply to a certain profile.
Given the current optionality, the following profiles or groups look reasonable

  • Core
  • Format
  • Quantity
  • SPI (requires at least Format, too)

CDI deals with this via TestNG groups:
http://docs.jboss.org/cdi/tck/reference/latest/en-US/html/configuration.html#tck-properties

Either doing that or in combination with system properties (and where Maven is used likely its profiles) we should be able to configure which tests in the TCK shall be executed for which profile.

Also see
http://stackoverflow.com/questions/7150302/excluding-testng-groups-from-maven
http://stackoverflow.com/questions/4578971/appending-jvm-parameter-to-the-parameter-specified-explicitly-in-plugin-configur



 Comments   
Comment by keilw [ 04/Sep/15 ]

At the moment, passing a wrong or unknown profile name (e.g. "minime" instead of "minimal") as system property causes an exception in TCKRunner

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running tec.units.tck.TCKRunnerTest
Configuring TestNG with: TestNG652Configurator
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.601 sec <<< FAILURE! - in tec.units.tck.TCKRunnerTest
testTCKRunner(tec.units.tck.TCKRunnerTest)  Time elapsed: 0.024 sec  <<< FAILURE!
java.lang.IllegalArgumentException: No enum constant tec.units.tck.util.TestGroups.Profile.minime
	at java.lang.Enum.valueOf(Enum.java:236)
	at tec.units.tck.util.TestGroups$Profile.valueOf(TestGroups.java:72)
	at tec.units.tck.TCKRunner.<init>(TCKRunner.java:81)
	at tec.units.tck.TCKRunnerTest.testTCKRunner(TCKRunnerTest.java:41)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	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)

This seems acceptable, the exception tells what's wrong, or should we rather override it with no profile ("full")?





Create TCK (UNITSOFMEASUREMENT-101)

[UNITSOFMEASUREMENT-159] Move test-audit.xml to main/resources Created: 31/Aug/15  Updated: 31/Aug/15  Resolved: 31/Aug/15

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to UNITSOFMEASUREMENT-118 Add Tests according to Spec Chapter 4 Resolved
Tags: file, layout, test, testing
Sprint: Q1/15, Final Draft

 Description   

Similar to CDI, the test-audit.xml file should move from the project root folder to src/main/resources.






Create TCK (UNITSOFMEASUREMENT-101)

[UNITSOFMEASUREMENT-158] Add Tests according to Spec Chapter 5 Created: 31/Aug/15  Updated: 02/Jul/16  Resolved: 02/Jul/16

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: None
Fix Version/s: None

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

Tags: spec, spi, test, testing
Sprint: Q1/15, Final Draft

 Description   

Add tests for SPI






[UNITSOFMEASUREMENT-153] Portability of TCK Created: 27/Jul/15  Updated: 04/Sep/15  Resolved: 04/Sep/15

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: None
Fix Version/s: 0.8

Type: Task Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed 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

Issue Links:
Blocks
blocks UNITSOFMEASUREMENT-101 Create TCK Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
UNITSOFMEASUREMENT-160 Configure Profiles for TCK Sub-task Resolved keilw  
Tags: embedded, portability, test, testing
Epic Link: Test
Sprint: Public Draft

 Description   

At least some utility classes in the initial TCK codebase use BigDecimal. If possible this should be avoided, given the API also does not use types that would be incompatible with target platforms like Java ME.



 Comments   
Comment by keilw [ 04/Sep/15 ]

TestUtils was modified to avoid BigDecimal or other elements of java.math. However, since the TCK itself is not meant to run on Java ME Embedded, there are crucial parts including TCKRunner dependent on reflection. These dependencies are OK since the TCK won't have to run on an Embedded VM, it just has to test artifacts that do in a platform-neutral way.





Create TCK (UNITSOFMEASUREMENT-101)

[UNITSOFMEASUREMENT-118] Add Tests according to Spec Chapter 4 Created: 27/Jan/15  Updated: 03/Apr/16  Resolved: 03/Apr/16

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: 0.7.1
Fix Version/s: 0.9

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

Issue Links:
Related
is related to UNITSOFMEASUREMENT-159 Move test-audit.xml to main/resources Resolved
Tags: api, spec, tck-red, test, testing
Sprint: Q1/15, Final Draft

 Description   

Spec Chapter 4 (API) requires TCK Tests

  • Assess if and which tests are required
  • Where necessary update test-audit.xml of the TCK project
  • Write tests for sections identified as relevant


 Comments   
Comment by keilw [ 03/Apr/16 ]

This looks pretty complete





Create TCK (UNITSOFMEASUREMENT-101)

[UNITSOFMEASUREMENT-117] Add Tests according to Spec Chapter 2 Created: 27/Jan/15  Updated: 20/Sep/15  Resolved: 20/Sep/15

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: 0.7.1
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: tck-red, test, testing
Sprint: Q1/15, Final Draft

 Description   

Spec Chapter 2 (Definitions) could require TCK Tests

  • Assess if and which tests are required
  • Where necessary update test-audit.xml of the TCK project
  • Write tests for sections identified as relevant


 Comments   
Comment by keilw [ 20/Sep/15 ]

As of now only Chapter 4 and 5 seem TCK relevant





[UNITSOFMEASUREMENT-101] Create TCK Created: 20/Dec/14  Updated: 02/Jul/16  Resolved: 02/Jul/16

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: 0.7
Fix Version/s: None

Type: Task Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed 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

Issue Links:
Blocks
is blocked by UNITSOFMEASUREMENT-173 Verify minimum Java version for TCK Resolved
is blocked by UNITSOFMEASUREMENT-176 Consider dropping SPI profile from TCK Resolved
is blocked by UNITSOFMEASUREMENT-153 Portability of TCK Resolved
Dependency
depends on UNITSOFMEASUREMENT-169 Consider additional profile(s) for TCK Resolved
depends on UNITSOFMEASUREMENT-174 Consider using Reflections.org for TCK Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
UNITSOFMEASUREMENT-117 Add Tests according to Spec Chapter 2 Sub-task Resolved keilw  
UNITSOFMEASUREMENT-118 Add Tests according to Spec Chapter 4 Sub-task Resolved keilw  
UNITSOFMEASUREMENT-158 Add Tests according to Spec Chapter 5 Sub-task Resolved keilw  
UNITSOFMEASUREMENT-159 Move test-audit.xml to main/resources Sub-task Resolved keilw  
UNITSOFMEASUREMENT-169 Consider additional profile(s) for TCK Sub-task Resolved keilw  
UNITSOFMEASUREMENT-173 Verify minimum Java version for TCK Sub-task Resolved keilw  
UNITSOFMEASUREMENT-174 Consider using Reflections.org for TCK Sub-task Resolved keilw  
UNITSOFMEASUREMENT-176 Consider dropping SPI profile from TCK Sub-task Resolved keilw  
Tags: tck-red, test, testing
Epic Link: Test
Sprint: Q1/15, Final Draft

 Description   

Following Early Draft, for any subsequent stage we shall start a TCK.
While using TestNG, not JUnit the TCK of JSR 354 looks like a good inspiration for those who want to learn what it shall look like: https://github.com/JavaMoney/jsr354-tck
JSR 107 is also a (currently) standalone JSR: https://github.com/jsr107/jsr107tck but adds some complexity by testing against various containers like Weld, Guice, Spring,... Something we will face in a slightly different form, becaus at least on Java ME and SE Embedded implementations are expected to run and be tested. JSR 361 (MEEP 8) was the first offering Optionality, but except to those among us in the EC its TCK is not Open Source or publicly visible.

There should be sub-tasks, others are extremely welcome to help.






[THUCYDIDES-89] Random Failed Test Occurs in Windows Created: 18/Aug/12  Updated: 02/Dec/12  Resolved: 02/Dec/12

Status: Resolved
Project: thucydides
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: xsalefter Assignee: johnsmart
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, Sun JDK 6, Maven 3.0.4


Attachments: PNG File failed1.PNG     PNG File failed2.PNG     Zip Archive failed3.zip    
Tags: JUnit, Test, Windows

 Description   

When build and running test in Windows environment, random failed test happen. Please look at the attachment how the failed test is different for one run/build to another run/build (Note that failed3 contains a lof of failed build, thus contains more than one screenshot attachments). And below is one of stacktrace detail, published in Gist:
https://gist.github.com/3387014
https://gist.github.com/3387047
https://gist.github.com/3387056






[TEAMPANTHER-191] Test Created: 29/May/12  Updated: 09/Jun/12  Resolved: 09/Jun/12

Status: Resolved
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: blomberg_88 Assignee: miktor
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 13 hours
Original Estimate: 16 hours

Tags: micke, sprint4, test

 Comments   
Comment by blomberg_88 [ 07/Jun/12 ]

flyttat 3h till förberedelser





[TEAMPANTHER-125] Test Created: 24/May/12  Updated: 08/Jun/12  Resolved: 08/Jun/12

Status: Resolved
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: blomberg_88 Assignee: miktor
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 8 hours
Original Estimate: 8 hours

Tags: micke, sprint3, test




Testdokumentation (TEAMPANTHER-88)

[TEAMPANTHER-98] Micke: Testdokumentation Created: 03/May/12  Updated: 08/Jun/12  Resolved: 08/Jun/12

Status: Resolved
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: blomberg_88 Assignee: miktor
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: 2 hours
Original Estimate: 4 hours

Tags: micke, sprint2, test, testdokumentation




Testdokumentation (TEAMPANTHER-88)

[TEAMPANTHER-97] Joel M: Testdokumentation Created: 03/May/12  Updated: 08/Jun/12  Resolved: 08/Jun/12

Status: Resolved
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: blomberg_88 Assignee: thecharliekelly
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 2 hours

Tags: joelm, sprint2, test, testdokumentation




Testdokumentation (TEAMPANTHER-88)

[TEAMPANTHER-89] Karin: Testdokumentation Created: 03/May/12  Updated: 08/Jun/12  Resolved: 08/Jun/12

Status: Resolved
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: blomberg_88 Assignee: kardah
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 2 hours

Tags: karin, sprint2, test, testdokumentation




[TEAMPANTHER-88] Testdokumentation Created: 03/May/12  Updated: 03/May/12

Status: Open
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: blomberg_88 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: 2 hours Remaining Estimate: Not Specified
Σ Time Spent: 6 hours Time Spent: Not Specified
Σ Original Estimate: 8 hours Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
TEAMPANTHER-89 Karin: Testdokumentation Sub-task Resolved kardah  
TEAMPANTHER-97 Joel M: Testdokumentation Sub-task Resolved thecharliekelly  
TEAMPANTHER-98 Micke: Testdokumentation Sub-task Resolved miktor  
Tags: sprint2, test, testdokumentation




[TEAMPANTHER-78] Testfall Created: 03/May/12  Updated: 08/Jun/12  Resolved: 08/Jun/12

Status: Resolved
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: blomberg_88 Assignee: miktor
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 3 hours
Time Spent: 10 hours
Original Estimate: 8 hours

Tags: micke, sprint2, test, testfall

 Comments   
Comment by blomberg_88 [ 09/May/12 ]

Flyttat 5h till denna task från andra tasks som inte micke behövde på de andra (Releasecykel -1h, Full spårbarhet 3h och Översättningsstrategier -1h)





Teststrategi/Verktygsval (TEAMPANTHER-68)

[TEAMPANTHER-72] Nathalie: Teststrategi/verktygsval Created: 03/May/12  Updated: 03/May/12

Status: Open
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: blomberg_88 Assignee: Te-em
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours

Tags: nathalie, sprint2, strategi, test, verktyg




Teststrategi/Verktygsval (TEAMPANTHER-68)

[TEAMPANTHER-71] Alexander: Teststrategi/verktygsval Created: 03/May/12  Updated: 09/May/12

Status: Open
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: blomberg_88 Assignee: ryuutora
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: 2 hours

Tags: alexander, sprint2, strategi, test, verktyg

 Comments   
Comment by blomberg_88 [ 09/May/12 ]

1h för teststrategier har flyttats till lösningsverk då alexander lagt ner 1h mindre än beräknat och kan komma att behöva 1h extra på lösningsverk





Teststrategi/Verktygsval (TEAMPANTHER-68)

[TEAMPANTHER-70] Micke: Teststrategi/verktygsval Created: 03/May/12  Updated: 08/Jun/12  Resolved: 08/Jun/12

Status: Resolved
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: blomberg_88 Assignee: miktor
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 2 hours

Tags: micke, sprint2, strategi, test, verktyg




Teststrategi/Verktygsval (TEAMPANTHER-68)

[TEAMPANTHER-69] Joel A: Teststrategi/verktygsval Created: 03/May/12  Updated: 08/Jun/12  Resolved: 08/Jun/12

Status: Resolved
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: blomberg_88 Assignee: JoelAnde
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 2 hours

Tags: joela, sprint2, strategi, test, verktyg




[TEAMPANTHER-68] Teststrategi/Verktygsval Created: 03/May/12  Updated: 03/May/12

Status: Open
Project: teampanther
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: blomberg_88 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: 2 hours Remaining Estimate: Not Specified
Σ Time Spent: 5 hours Time Spent: Not Specified
Σ Original Estimate: 8 hours Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
TEAMPANTHER-69 Joel A: Teststrategi/verktygsval Sub-task Resolved JoelAnde  
TEAMPANTHER-70 Micke: Teststrategi/verktygsval Sub-task Resolved miktor  
TEAMPANTHER-71 Alexander: Teststrategi/verktygsval Sub-task Open ryuutora  
TEAMPANTHER-72 Nathalie: Teststrategi/verktygsval Sub-task Open Te-em  
Tags: sprint2, strategi, test, verktyg




[SWINGX-1473] Correct failing unit tests Created: 15/Nov/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

Status: Resolved
Project: swingx
Component/s: None
Affects Version/s: 1.6.3
Fix Version/s: 1.6.3

Type: Task Priority: Major
Reporter: brettryan Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 0003-Surpress-test-of-dirty-property.patch     Text File 0004-Surpress-errors-to-build-needs-fix.patch     Text File 0006-Disabled-broken-tests.patch    
Tags: test, test_issue

 Description   

There are a 12 unit tests that are either false tests whereby the tests are testing for things they shouldn't be or are written incorrectly.

I've produced a number of patch files which have commented out the broken tests in question and marked them with FIXME so they can be easily identified.



 Comments   
Comment by Karl Schaefer [ 15/Nov/11 ]

I have already been fixing these over the past few days. All tests should now be corrected or ignored as appropriate.

Note: This problem is likely to reoccur, since CI is unable to download the latest Maven artifacts necessary to run the build.





[OZARK-15] Improve test coverage Created: 10/Mar/15  Updated: 06/Aug/15  Resolved: 06/Aug/15

Status: Closed
Project: ozark
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0-m02

Type: Task Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: coverage, test
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: coverage, test

 Description   

Ongoing tasks to keep track of our test coverage improvements.



 Comments   
Comment by Manfred Riem [ 05/Aug/15 ]

I would like to close this one out with the understanding that we need to keep bumping our code coverage





[MVC_SPEC-29] Add assertions to spec document for testing purposes Created: 10/Mar/15  Updated: 30/Mar/15  Resolved: 30/Mar/15

Status: Closed
Project: mvc-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0-edr1

Type: Task Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: assertions, test
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: assertions, test

 Description   

Need to add assertions to make it easier to write tests and improve coverage.



 Comments   
Comment by Santiago Pericas-Geertsen [ 30/Mar/15 ]

Done for EDR1.





[MSRP-12] TestCorrectlyBreaksSentData.java enhancement Created: 16/Mar/09  Updated: 25/Oct/12  Resolved: 25/Oct/12

Status: Closed
Project: msrp
Component/s: library source
Affects Version/s: beta
Fix Version/s: 1.0.4

Type: Improvement Priority: Major
Reporter: dtroit Assignee: uijltje
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 16 hours
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12
Tags: end-line, test, transaction, validate

 Description   

Enhance TestCorrectlyBreaksSentData.java test to verify that the message is
correctly broken into transactions in the case of:
. A big message is to be transmitted;
. The transaction end-line occurs when the write buffer changes so that half of
it should be on one buffer and the other half on the other 2048 bytes buffer
.The transaction end-line occurs completely on the first character of the new
2048 byte write buffer



 Comments   
Comment by uijltje [ 04/Oct/12 ]

page 18 of RFC 4975:
<<<<<
If the request contains a body, the sender MUST ensure that the end-
line (seven hyphens, the transaction identifier, and a continuation
flag) is not present in the body. If the end-line is present in the
body, the sender MUST choose a new transaction identifier that is not
present in the body, and add a CRLF if needed, and the end-line,
including the "$", "#", or "+" character
>>>>>

Is not properly tested (yet), test is ignored for now.

Uncertain whether issue is handled correctly nor if it'll present problems in usage.
Delay fix to version 2 for now.

Comment by uijltje [ 25/Oct/12 ]

Refer to svn r182 for a solution.

Especially the interrupt of a transaction was improved by generating a new one and queueing when it was interrupted.

Unit tests on break now function.

Issue can be closed

Comment by uijltje [ 25/Oct/12 ]

Get into bug-fix release....





[MQ-140] persist store internal API test 'persist/api/file' logs many ERROR [3007] when trying to load destinations or messages Created: 11/Jan/12  Updated: 06/Mar/13  Resolved: 06/Mar/13

Status: Closed
Project: mq
Component/s: test
Affects Version/s: 4.5
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: mathim Assignee: amyk
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MQ broker running on Windows with JDK1.6 and 1.7


Tags: messagequeue, test

 Description   

MQ Broker running on Windows with either JDK1.6 or JDK1.7 some times appear to go on a spin printing the following messages. Some tests fail when this happens.

This behavior is not consistently reproducible. I have seen it most times when running the test tonga/jmsserver/persist/api/file

snippet of the broker log. Attaching the complete test log.

[10/Jan/2012:16:47:21 PST] [B1060]: Loading persistent data...
[10/Jan/2012:16:47:21 PST] Using built-in file-based persistent store: C:\temp\MQ5.0\binary\win32\opt\var\instances\persistapi.file\
[10/Jan/2012:16:47:21 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242839703 on destination T:798511184 could not be found in the store
[10/Jan/2012:16:47:21 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242839734 on destination Q:1997718144 could not be found in the store
[10/Jan/2012:16:47:21 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242839750 on destination Q:1997718144 could not be found in the store
[10/Jan/2012:16:47:23 PST] [B1060]: Loading persistent data...
[10/Jan/2012:16:47:23 PST] Using built-in file-based persistent store: C:\temp\MQ5.0\binary\win32\opt\var\instances\persistapi.file\
[10/Jan/2012:16:47:23 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242841437 on destination Q:1997718144 could not be found in the store
[10/Jan/2012:16:47:23 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242841438 on destination T:798511184 could not be found in the store
[10/Jan/2012:16:47:23 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242841439 on destination T:798511184 could not be found in the store
[10/Jan/2012:16:47:24 PST] [B1060]: Loading persistent data...
[10/Jan/2012:16:47:24 PST] Using built-in file-based persistent store: C:\temp\MQ5.0\binary\win32\opt\var\instances\persistapi.file\
[10/Jan/2012:16:47:24 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242841437 on destination Q:1997718144 could not be found in the store
[10/Jan/2012:16:47:24 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242841438 on destination T:798511184 could not be found in the store
[10/Jan/2012:16:47:24 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242841439 on destination T:798511184 could not be found in the store
[10/Jan/2012:16:47:24 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242841437 on destination Q:1997718144 could not be found in the store
[10/Jan/2012:16:47:24 PST] ERROR [B3013]: Destination Q:270042449 could not be found in the store
[10/Jan/2012:16:47:26 PST] [B1060]: Loading persistent data...
[10/Jan/2012:16:47:26 PST] Using built-in file-based persistent store: C:\temp\MQ5.0\binary\win32\opt\var\instances\persistapi.file\
[10/Jan/2012:16:47:26 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242846547 on destination Q:1722087962 could not be found in the store
com.sun.messaging.jmq.jmsserver.util.BrokerException: Message 0-10.133.161.100-9090-1326242846547 on destination Q:1722087962 could not be found in the store
at com.sun.messaging.jmq.jmsserver.persist.file.MsgStore.moveMessage(MsgStore.java:401)
at com.sun.messaging.jmq.jmsserver.persist.file.FileStore.moveMessage(FileStore.java:896)
at test.jmsserver.persist.MessageTest.moveMessage_test3(MessageTest.java:1383)
at test.jmsserver.persist.MessageTest.runtest(MessageTest.java:102)
at test.jmsserver.persist.StoreTest.runTest(StoreTest.java:121)
at test.jmsserver.persist.StoreTest.main(StoreTest.java:487)
[10/Jan/2012:16:47:28 PST] [B1060]: Loading persistent data...
[10/Jan/2012:16:47:28 PST] Using built-in file-based persistent store: C:\temp\MQ5.0\binary\win32\opt\var\instances\persistapi.file\
[10/Jan/2012:16:47:29 PST] [B1060]: Loading persistent data...
[10/Jan/2012:16:47:29 PST] Using built-in file-based persistent store: C:\temp\MQ5.0\binary\win32\opt\var\instances\persistapi.file\
[10/Jan/2012:16:47:31 PST] [B1060]: Loading persistent data...
[10/Jan/2012:16:47:31 PST] Using built-in file-based persistent store: C:\temp\MQ5.0\binary\win32\opt\var\instances\persistapi.file\
[10/Jan/2012:16:47:31 PST] ERROR [B3008]: Message 0-10.133.161.100-9090-1326242849984 on destination Q:748022277 exists in the store already
[10/Jan/2012:16:47:31 PST] ERROR [B3013]: Destination Q:1944390472 could not be found in the store
[10/Jan/2012:16:47:33 PST] [B1059]: Resetting persistent store...
[10/Jan/2012:16:47:33 PST] Using built-in file-based persistent store: C:\temp\MQ5.0\binary\win32\opt\var\instances\persistapi.file\
[10/Jan/2012:16:47:33 PST] WARNING Existing file: incompleteTxnStorehas older cookie version than current version. Current version = 1. Original file version = 0
[10/Jan/2012:16:47:35 PST] [B1060]: Loading persistent data...
[10/Jan/2012:16:47:35 PST] Using built-in file-based persistent store: C:\temp\MQ5.0\binary\win32\opt\var\instances\persistapi.file\
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855000 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855015 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855016 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855017 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855031 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855032 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855033 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855034 on destination Q:1388340007 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855062 on destination Q:1856554643 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855078 on destination Q:1856554643 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855079 on destination Q:1856554643 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855000 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855015 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855016 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855017 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855031 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855032 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855033 on destination T:633513490 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855187 on destination Q:1388340007 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855188 on destination Q:1856554643 could not be found in the store
[10/Jan/2012:16:47:35 PST] ERROR [B3007]: Message 0-10.133.161.100-9090-1326242855189 on destination Q:1856554643 could not be found in the store



 Comments   
Comment by amyk [ 14/Jan/12 ]

Mathi had reported that he saw the problem while running MQ test list and reported that

"This condition does not occur when run with the newTxnLog disabled."
"The problem happens with 4.5 and 4.5.2 as well"

talked to Mathi afterward, the broker was not "spinning" rather appeared that the newTxnLog was processing a lot of records which caused the broker startup slow but eventually the broker did startup and subsequent test appeared to fail due to timeout

Comment by mathim [ 12/Nov/12 ]

this bug causes problems when running tonga tests on windows. tests run very very slow. Increasing the priority of the bug.

Comment by amyk [ 13/Nov/12 ]

Mathi, did you notice the problem when you run the putback.list ? Is it possible that you could provide a minimum test list by reducing the number of tests in the list that reproduces the problem ?

Comment by mathim [ 13/Nov/12 ]

i think putback.list will definitely reproduce this problem. when ever any test restarts the broker, the broker goes in loops

Comment by amyk [ 14/Nov/12 ]

The test persist/api/file creates its own broker instance with name "persistapi.file". So 1) if any other tests restart a broker it would not be the instance "persistapi.file"; 2) the test persist/api/file does not affect the default broker (the one running on port 7676) that other tests can restart; 3) The broker logging output shown in Description can only come from test persist/api/file

The persist/api/file is a persist store internal API ('white box') test. The test

1. Takes ~7.5min to run (on a Solaris 8x3325 MHz system)
2. The ERROR [B3007] are expected by the test. For example, some sub-tests of the test remove messages from a destination, then verify attempting to retrieve or remove the same message again will get exception as expected - e.g. test outputs like following can be found in .eout file

== Store.getInterestState:test 5:got BrokerException; test passed
== exception: com.sun.messaging.jmq.jmsserver.util.BrokerException: [B3007]: Message 0-10.133.184.56-9090-1362561524324 on destination T:483311002 could not be found in the store
----------------

According to Mathi, some of Mathi's comments above came from his early stage of testing MQ 5.0 Grizzly connection service which was caused by a different issue that has been fixed (see internal jira JMS-216).

Change this issue to test and close. The putback.list (part of nightly.list) has been running on Windows for each nightly/milestone build. Mathi, please file a separate issue if you see problem other than test persist/api/file when running putback.list on your Windows system





[JERSEY-2697] HttpServletRequest fails to inject using grizzly2 container (and JerseyTest) Created: 30/Oct/14  Updated: 10/Sep/15  Resolved: 31/Oct/14

Status: Closed
Project: jersey
Component/s: containers, test-framework
Affects Version/s: 2.13
Fix Version/s: None

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

Java 7. Jersey 2.13, Tomcat 7


Tags: container, grizzly, injection, test

 Description   

For testing purposes I use a simple Java class to start a Grizzly2 container as recommended by the manual.
Code:

URI baseUri = UriBuilder.fromUri("http://localhost/").port(this.port).build();
GrizzlyHttpServerFactory.createHttpServer(baseUri, new ProperApplication());

And I am using:

    <dependency>
      <groupId>org.glassfish.jersey.containers</groupId>
      <artifactId>jersey-container-grizzly2-http</artifactId>
      <scope>compile</scope>
    </dependency>

In my service I want ot use a HttpServletRequest, like this:

@Context private HttpServletRequest httpRequest;

Each time I want to use it, it is null. When I use my application directly in Tomcat (7) it does work.



 Comments   
Comment by Adam Lindenthal [ 31/Oct/14 ]

Hi ivolimmen,

this is completely natural and expected behaviour, as when using grizzly2 http container, your app is running in a non-servlet environment. As such it cannot inject the servlet context nor http servlet request.

There are (afaik) two ways out of this:

  • if you really need the HttpServletRequest to be injected, use some servlet container (for instance, we use jetty in our servlet based tests)
  • if you just wanted some general data from the request, try to inject it directly (e.g. @UriInfo, @HttpHeaders, depending what you actually need for your request processing).

Hope this helps, however, I have to close this as invalid.
Regards,
Adam

Comment by ivolimmen [ 31/Oct/14 ]

Thank you for your comment. I will switch to a full embedded container for my tests. I do think the documentation are not really clear on what you can and cannot do with the different containers. From what I understood is that the grizzly container supported the most features needed for testing (as in resources deployed not directly under root, etc.) but does not mention what you can not do...

I won't fall for the trap again, but others might.

Comment by Adam Lindenthal [ 31/Oct/14 ]

Well, maybe it would be worth it to update the docs in that manner. I just checked the section about the @Context injection and there is a guideline, but it could be maybe more "pronounced" or maybe a link to Chapter 4 (which explains various deployment possibilities) could be added.

The thing is - you are not the only one who had problems with that (and, interestingly, there were several people within the last few days, but AFAIK basically nobody before).
As I am not independent and "unbalanced" enough, I am open to your suggestions how to make that clear enough in the docs. In my opinion, a note under the injection chapter stating that the server related context information does not work (and is null) on non servlet environments, such as ....

Cheers,
Adam





[JERSEY-1486] null as vargars is not cast to Object or Object[] Created: 15/Oct/12  Updated: 10/Sep/15  Resolved: 19/Feb/13

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m13, 2.0

Type: Bug Priority: Trivial
Reporter: Lutz Horn Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours

Attachments: Text File JerseyWebTargetTest.patch    
Tags: client, test, warning

 Description   

null as varargs parameter values of JerseyWebTarget.queryParam(String name, Object... values) is neither cast to Object nor to Object[].

The patches fixes this by casting null to Object.



 Comments   
Comment by Marek Potociar [ 19/Feb/13 ]

Has been resolved already.





[JERSEY-1485] Tests don't use Generics Created: 15/Oct/12  Updated: 10/Sep/15  Resolved: 19/Feb/13

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m13, 2.0

Type: Bug Priority: Trivial
Reporter: Lutz Horn Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: 3 hours

Attachments: Text File ClientConfigTest.patch    
Tags: client, test, warning

 Description   

Two tests of org.glassfish.jersey.client.ClientConfigTest don't use Generics.

The attached patch fixes this.






[JERSEY-1484] Tests override member client Created: 15/Oct/12  Updated: 10/Sep/15  Resolved: 19/Feb/13

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 2.0-m08
Fix Version/s: 2.0-m13, 2.0

Type: Bug Priority: Trivial
Reporter: Lutz Horn Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours

Attachments: Text File JerseyClientTest.patch    
Tags: client, test, warning

 Description   

Two tests in org.glassfish.jersey.client.JerseyClientTest override the member client.

The attached patch fixes this.






[JAX_WS-1046] Client received SOAP Fault from server: ProtocolException inCL_LH_S Created: 25/Jan/12  Updated: 09/Feb/12  Resolved: 09/Feb/12

Status: Resolved
Project: jax-ws
Component/s: handlers
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sreekanth Assignee: Sreekanth
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jaxws 2.2.7, JDK PIT build8


Attachments: File bc-tomcat.properties    
Issue Links:
Dependency
depends on JAX_WS-1034 [Regression]Some tests in handler fra... Resolved
Tags: test

 Description   

Around 16 backward Compatibilty tests were failing with JDK8 PIT Build

Steps to reproduce:

1)Check out the jaxws sqe test suite.
2)Modify jaxws-test/config/setup-props.xml to use &j2se; at line 10
3)Download, install and start the tomcat server.
4)Download the attached properties file "bc-tomcat.properties" to run the tests .
5)Modify the above properties file according to your local workspace
6)now move to jaxws-test/src/handlers/handlers_wsdl_doclit
7)Execute the command :
ant clean build bc-deploy bc-runtest bc-generate-results -propertyfile <path-to>/bc-tomcat.properties
8)You can see the failures

If you run the above command using JDK7 PIT build, you wont see the failures.

with JDK7 and before when there was an exception, ex.getMessage() used to return "Expected:ProtocolException inCL_LH_S",but after some changes( related to JAX_WS-1034), we are receiving "Client received SOAP Fault from server: ProtocolException inCL_LH_S Please see the server log to find more detail regarding exact cause of the failure."



 Comments   
Comment by Sreekanth [ 25/Jan/12 ]

The fix( w.rt. QE test code) for this would be similar to fix to JAXWS-1034.Since these tests are part of backward compatibility tests,I am not sure fixing the client side test code is appropriate.

Comment by miroslav.kos [ 25/Jan/12 ]

actually sources looks already to be fixed with JAX_WS-1034; the question is if, how and when should be binaries for BC tests rebuilt (after new release of JDK? by the last unsupported jdk~jdk5?)

Comment by Martin Grebac [ 25/Jan/12 ]

Best is to test against previous version - that's what JDK does - that means prebuild binaries with JDK6 and run on JDK7 build. Similarly prebuild with JDK7 and run on JDK8 build. If that is too complicated then it would be fine to prebuild with lowest supported JDK - that would be JDK6 at this point and run the same on JDK7 and JDK8.
Onto whether the test code should be fixed and rebuilt in general - it should be certainly fixed if the test relies on particular proprietary feature - such as exception message content which AFAIU is this case.

Comment by miroslav.kos [ 27/Jan/12 ]

Sreekanth, will you take care of this issue?

Comment by Sreekanth [ 30/Jan/12 ]

Miran,I will take care of it.

Comment by Sreekanth [ 03/Feb/12 ]

made the necessary changes to the qe side jar files.

Updated the jar file jaxws-test/bc/handlers_clients.jar file in jaxws-2-2-x-XjdkX-branch branch.Checked the backward compatibility tests against both JDK7 and JDK8 PIT builds.

Comment by Sreekanth [ 09/Feb/12 ]

Fixed the jar files in internal SQE Workspace.Now the backward compatibility tests are passing





[JAX_WS-1003] [Bug 9477981] throw java.lang.exception when test web service operation. Created: 29/Aug/11  Updated: 20/Oct/11  Resolved: 20/Oct/11

Status: Closed
Project: jax-ws
Component/s: None
Affects Version/s: None
Fix Version/s: current

Type: Bug Priority: Major
Reporter: linguo Assignee: linguo
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: BugDB-9477981, NPE, operation, service, test, throw, web, when

 Description   

Migration of existing WebLogic / Oracle bug: https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=9477981

[Bug description]
When the method with @PostConstruct annotation in the webservice is called, Null pointer exception will be thrown.

[Problems Diagnosis]
Web services should default to not having as web methods that are annotated with @PostConstruct, @PreDestroy, @PostActivate, or @PrePassivate. These methods are lifecycle methods, not business methods. They should not be exposed as web services in WSDL.

[Conclusion]
According to notes from the wiki, QA has already agreed that RI has correct generation of legal web operations. So it's not needed to integrate this change to jaxws22.

Original fix: http://tamarac.us.oracle.com/describe.php?change=1388317






[JAVASERVERFACES-2356] Implement UIDebug recordStateSize Created: 27/Mar/12  Updated: 15/Nov/12  Resolved: 15/Nov/12

Status: Closed
Project: javaserverfaces
Component/s: facelets
Affects Version/s: 2.2.0-m01
Fix Version/s: 2.2.0-m07

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Text File i_mojarra_2356-server.log     File jsf-systest.war    
Tags: test

 Description   

Testcase: testUIRepeatStateNotLostOnNonUIRepeatMessage took 0.063 sec
[junit] Testcase: testUIRepeatVarBeginEndStepProperties took 0.045 sec
[junit] Testcase: testForEachVarStatusNoException took 0.038 sec
[junit] Testcase: testDebugViewState took 31.018 sec
[junit] Caused an ERROR
[junit] chunked stream ended unexpectedly
[junit] java.io.IOException: chunked stream ended unexpectedly
[junit] at org.apache.commons.httpclient.ChunkedInputStream.getChunkSizeFromInputStream(ChunkedInputStream.java:252)
[junit] at org.apache.commons.httpclient.ChunkedInputStream.nextChunk(ChunkedInputStream.java:221)
[junit] at org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStream.java:176)
[junit] at java.io.FilterInputStream.read(FilterInputStream.java:116)
[junit] at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java:108)
[junit] at java.io.FilterInputStream.read(FilterInputStream.java:90)
[junit] at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java:127)
[junit] at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025)



 Comments   
Comment by Ed Burns [ 27/Mar/12 ]

Sending jsf-ri/systest/src/com/sun/faces/facelets/UIRepeatTestCase.java
Transmitting file data .
Committed revision 9783.

Sending jsf-ri/systest/build.xml
Transmitting file data .
Committed revision 9784.

Comment by Ed Burns [ 27/Mar/12 ]

Changes in r9783 and 9784 did not fix the problem.

Comment by Ed Burns [ 27/Mar/12 ]

Steps to reproduce.

  • Deploy jsf-systest.war.
  • Wait for the page to load.
  • You should see a gigantic table.
  • Press Ctrl-Shift-D.
  • If your browser prevents a pop-up, enable it, and press the key combination again.
  • You should see a window with "Debug" as the title.
Comment by Ed Burns [ 27/Mar/12 ]

Sending jsf-ri/systest/src/com/sun/faces/facelets/UIRepeatTestCase.java
Transmitting file data .
Committed revision 9785.

  • I've contacted Shing-Wai.

M jsf-ri/systest/src/com/sun/faces/facelets/UIRepeatTestCase.java

+ /******* PENDING(edburns): disable this test until JAVASERVERFACES-2356 is resolved

Comment by Ed Burns [ 27/Mar/12 ]

Server log from failed test run.

Comment by Manfred Riem [ 09/Oct/12 ]

Renaming issue so it reflects what work is being done.

Comment by Ed Burns [ 14/Nov/12 ]

We should fully revert the partial implementation of this for 2.2.

Comment by Manfred Riem [ 15/Nov/12 ]

Applied to 2.2 trunk,

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2356, r=rogerk, reverting back to old behavior."
Sending jsf-ri\src\main\java\com\sun\faces\facelets\tag\ui\UIDebug.java
Transmitting file data .
Committed revision 11012.





[JAVASERVERFACES-2299] Fix test error TEST-_faces_facelets_i_bugdb_13582626_fViewNullLocale.xhtml Created: 23/Jan/12  Updated: 12/Nov/12  Resolved: 12/Nov/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.6
Fix Version/s: 2.1.15, 2.2.0-m07

Type: Bug Priority: Major
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: test

 Description   

Fix the TEST-_faces_facelets_i_bugdb_13582626_fViewNullLocale.xhtml test in the test.facelets area.



 Comments   
Comment by Manfred Riem [ 12/Nov/12 ]

The test is working on 2.1.15 and 2.2.0-m07 so closing it as "Cannot Reproduce".





[JAVASERVERFACES-2268] re-enable TestMethodExpressionImpl.testNullReference() when GLASSFISH-17996 is fixed Created: 13/Dec/11  Updated: 01/Nov/12  Resolved: 01/Nov/12

Status: Closed
Project: javaserverfaces
Component/s: build
Affects Version/s: trunk, 2.1.7
Fix Version/s: 2.1.15, 2.2.0-m06

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Dependency
depends on GLASSFISH-17996 ExpressionFactory.createMethodExpress... Resolved
Tags: test

 Description   

To enable the build to suceed, I have disabled TestMethodExpressionImpl.testNullReference().

This issue exists to ensure the test is re-enabled.



 Comments   
Comment by Ed Burns [ 13/Dec/11 ]

Committed disabling to 2.1 branch:

Sending jsf-ri/test/com/sun/faces/el/TestMethodExpressionImpl.java
Transmitting file data .
Committed revision 9507.

Comment by Ed Burns [ 13/Dec/11 ]

Committed disabling to trunk:

Sending jsf-ri/test/com/sun/faces/el/TestMethodExpressionImpl.java
Transmitting file data .
Committed revision 9508.

Comment by Ed Burns [ 13/Dec/11 ]

Found another failure to exclude, this on the trunk:

Sending jsf-ri/test/com/sun/faces/el/TestMethodExpressionImpl.java
Transmitting file data .
Committed revision 9509.

Comment by Ed Burns [ 13/Dec/11 ]

2.1 branch:

Sending jsf-ri/test/com/sun/faces/el/TestMethodExpressionImpl.java
Transmitting file data .
Committed revision 9510.

Comment by Manfred Riem [ 01/Nov/12 ]

Applied to 2.1 branch,

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2268, r=rogerk, Rework test as per associated Glassfish issue"
Sending jsf-ri\test\com\sun\faces\el\TestMethodExpressionImpl.java
Transmitting file data .
Committed revision 10953.

Comment by Manfred Riem [ 01/Nov/12 ]

Applied to 2.2 trunk,

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2268, r=rogerk, Rework test as per associated Glassfish issue"
Sending jsf-ri\test\com\sun\faces\el\TestMethodExpressionImpl.java
Transmitting file data .
Committed revision 10954.





[JAVASERVERFACES-2109] systest-per-webapp: replace-vdl Test Fails On AIX Created: 12/Jun/11  Updated: 26/Jun/12  Resolved: 03/May/12

Status: Closed
Project: javaserverfaces
Component/s: build
Affects Version/s: trunk
Fix Version/s: 2.1.8, 2.2.0-m02

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2108 systest-per-webapp: replace-vdl Test ... Closed
Tags: test

 Description   

ReplaceViewDeclarationLanguageTestCase.testReplaceVDL method relies on the output from produced stack trace output. The test uses a class, VDLImpl that extends ViewDeclarationLanguage and overrides the logMethodInvocation method. This logMethodInvocation method captures stack trace output:
StackTraceElement stackTrace[] = Thread.currentThread().getStackTrace();
and specifically expects stackTrace[2] to contain method names expected by the test (getViewMetaData, restoreView, buildView, etc...).. This works fine on non AIX machine as for example:

[0] =

{java.lang.StackTraceElement@356}

"java.lang.Thread.getStackTrace(Thread.java:1503)"
[1] =

{java.lang.StackTraceElement@358}

"com.sun.faces.systest.replacevdl.VDLImpl.logMethodInvocation(VDLImpl.java:69)"
[2] =

{java.lang.StackTraceElement@359}

"com.sun.faces.systest.replacevdl.VDLImpl.getViewMetadata(VDLImpl.java:119)"

However on AIX, the stacktrace arry looks like:

[0] =

{java.lang.StackTraceElement@1606}

"java.lang.Thread.getStackTraceImpl(Native Method)"
[1] =

{java.lang.StackTraceElement@1674}

"java.lang.Thread.getStackTrace(Thread.java:1042)"
[2] =

{java.lang.StackTraceElement@1824}

"com.sun.faces.systest.replacevdl.VDLImpl.logMethodInvocation(VDLImpl.java:69)"
[3] =

{java.lang.StackTraceElement@1904}

"com.sun.faces.systest.replacevdl.VDLImpl.getViewMetadata(VDLImpl.java:119)"



 Comments   
Comment by Manfred Riem [ 03/May/12 ]

Moved into the new testing harness. The actual test no longer uses the stack
elements. The logMethodInvocation method now explicitly passes in which
methods is called.

Comment by Manfred Riem [ 03/May/12 ]

Applied to 2.1 branch,

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2109, r=rogerk, Moved into the new testing harness. The actual test no longer uses the stack elements."
Sending jsf-ri\systest-per-webapp\replace-vdl\src\java\com\sun\faces\systest\replacevdl\ReplaceViewDeclarationLanguageTestCase.java
Sending test\agnostic\vdl\facelets\pom.xml
Adding test\agnostic\vdl\facelets\replace-vdl
Adding test\agnostic\vdl\facelets\replace-vdl\nbactions.xml
Adding test\agnostic\vdl\facelets\replace-vdl\pom.xml
Adding test\agnostic\vdl\facelets\replace-vdl\src
Adding test\agnostic\vdl\facelets\replace-vdl\src\main
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic\vdl
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic\vdl\replacevdl
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic\vdl\replacevdl\ReplaceVDLFactory.java
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic\vdl\replacevdl\ReplaceVDLImpl.java
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\resources
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\WEB-INF
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\WEB-INF\faces-config.xml
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\WEB-INF\glassfish-web.xml
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\WEB-INF\web.xml
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\index.xhtml
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\replacevdl.xhtml
Adding test\agnostic\vdl\facelets\replace-vdl\src\test
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test\agnostic
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test\agnostic\vdl
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test\agnostic\vdl\replacevdl
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test\agnostic\vdl\replacevdl\ReplaceVDLIT.java
Transmitting file data ............
Committed revision 9912.

Comment by Manfred Riem [ 03/May/12 ]

Applied to trunk (2.2),

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2109, r=rogerk, Moved into the new testing harness. The actual test no longer uses the stack elements."
Sending jsf-ri\systest-per-webapp\replace-vdl\src\java\com\sun\faces\systest\replacevdl\ReplaceViewDeclarationLanguageTestCase.java
Adding test\agnostic\vdl
Adding test\agnostic\vdl\facelets
Adding test\agnostic\vdl\facelets\replace-vdl
Adding test\agnostic\vdl\facelets\replace-vdl\nbactions.xml
Adding test\agnostic\vdl\facelets\replace-vdl\pom.xml
Adding test\agnostic\vdl\facelets\replace-vdl\src
Adding test\agnostic\vdl\facelets\replace-vdl\src\main
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic\vdl
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic\vdl\replacevdl
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic\vdl\replacevdl\ReplaceVDLFactory.java
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\java\com\sun\faces\test\agnostic\vdl\replacevdl\ReplaceVDLImpl.java
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\WEB-INF
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\WEB-INF\faces-config.xml
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\WEB-INF\glassfish-web.xml
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\WEB-INF\web.xml
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\index.xhtml
Adding test\agnostic\vdl\facelets\replace-vdl\src\main\webapp\replacevdl.xhtml
Adding test\agnostic\vdl\facelets\replace-vdl\src\test
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test\agnostic
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test\agnostic\vdl
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test\agnostic\vdl\replacevdl
Adding test\agnostic\vdl\facelets\replace-vdl\src\test\java\com\sun\faces\test\agnostic\vdl\replacevdl\ReplaceVDLIT.java
Transmitting file data ...........
Committed revision 9920.





[JAVASERVERFACES-2108] systest-per-webapp: replace-vdl Test Fails On AIX Created: 12/Jun/11  Updated: 26/Jun/12  Resolved: 27/Apr/12

Status: Closed
Project: javaserverfaces
Component/s: build
Affects Version/s: trunk
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAVASERVERFACES-2109 systest-per-webapp: replace-vdl Test ... Closed
Tags: test

 Description   

ReplaceViewDeclarationLanguageTestCase.testReplaceVDL method relies on the output from produced stack trace output. The test uses a class, VDLImpl that extends ViewDeclarationLanguage and overrides the logMethodInvocation method. This logMethodInvocation method captures stack trace output:
StackTraceElement stackTrace[] = Thread.currentThread().getStackTrace();
and specifically expects stackTrace[2] to contain method names expected by the test (getViewMetaData, restoreView, buildView, etc...).. This works fine on non AIX machine as for example:

[0] =

{java.lang.StackTraceElement@356}

"java.lang.Thread.getStackTrace(Thread.java:1503)"
[1] =

{java.lang.StackTraceElement@358}

"com.sun.faces.systest.replacevdl.VDLImpl.logMethodInvocation(VDLImpl.java:69)"
[2] =

{java.lang.StackTraceElement@359}

"com.sun.faces.systest.replacevdl.VDLImpl.getViewMetadata(VDLImpl.java:119)"

However on AIX, the stacktrace arry looks like:

[0] =

{java.lang.StackTraceElement@1606}

"java.lang.Thread.getStackTraceImpl(Native Method)"
[1] =

{java.lang.StackTraceElement@1674}

"java.lang.Thread.getStackTrace(Thread.java:1042)"
[2] =

{java.lang.StackTraceElement@1824}

"com.sun.faces.systest.replacevdl.VDLImpl.logMethodInvocation(VDLImpl.java:69)"
[3] =

{java.lang.StackTraceElement@1904}

"com.sun.faces.systest.replacevdl.VDLImpl.getViewMetadata(VDLImpl.java:119)"






[JAVASERVERFACES-2106] systest-per-webapp: ReplaceVariableResolverAndAddELResolverProgrammaticallyTestCase Fails On AIX Created: 12/Jun/11  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2105 systest-per-webapp: ReplaceVariableRe... Closed
Tags: test

 Description   

ReplaceVariableResolverAndAddELResolverProgrammaticallyTestCase is cleverly written to verify that ELResolvers are called in the right sequence. It does this by overriding the toString method (from the call to getValue:

context.getApplication().getELResolver().getValue(context.getELContext(), null,
new Object() {

@Override
public String toString()

{ Bean.captureStackTrace(context); return "traceResolution"; }

});

Bean.captureStackTrace captures the stack trace for the current thread - so if the thread is inside ImplicitObjectELResolver that will show up in the stacktrace. This section of code loops through the stack trace elements looking for the element that contains the string (for example) "ImplicitObjectELResolver". The code is written to loop through 4 times:

for (int i = 0; i < 4; i++) {
StackTraceElement cur = stackTrace[i];
stackTraceElement = cur.toString();
if (!(stackTraceElement.contains("Thread") ||
stackTraceElement.contains("com.sun.faces.systest.Bean")))

{ message.append("<p>").append(stackTraceElement).append("</p>"); break; }

}

On a non AIX machine this is fine as the stack trace elements are:

[0] =

{java.lang.StackTraceElement@7188}

"java.lang.Thread.getStackTrace(Thread.java:1503)"
[1] =

{java.lang.StackTraceElement@7189}

"com.sun.faces.systest.Bean.captureStackTrace(Bean.java:139)"
[2] =

{java.lang.StackTraceElement@7190}

"com.sun.faces.systest.Bean$1.toString(Bean.java:108)"
[3] =

{java.lang.StackTraceElement@7191}

"com.sun.faces.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:101)"
[4] =

{java.lang.StackTraceElement@7192}

"com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)"
[5] =

{java.lang.StackTraceElement@7193}

"com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)"
[6] =

{java.lang.StackTraceElement@7194}

"com.sun.faces.systest.Bean.verifyELResolverChainIsCorrectlyConfigured(Bean.java:103)

However on an AIX machine, the stack trace elements are:

[0] =

{java.lang.StackTraceElement@1084}

"java.lang.Thread.getStackTraceImpl(Native Method)"
[1] =

{java.lang.StackTraceElement@1152}

"java.lang.Thread.getStackTrace(Thread.java:1042)"
[2] =

{java.lang.StackTraceElement@1434}

"com.sun.faces.systest.Bean.captureStackTrace(Bean.java:139)"
[3] =

{java.lang.StackTraceElement@1508}

"com.sun.faces.systest.Bean$1.toString(Bean.java:108)"
[4] =

{java.lang.StackTraceElement@2600}

"com.sun.faces.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:101)"
[5] =

{java.lang.StackTraceElement@1662}

"com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)"
[6] =

{java.lang.StackTraceElement@1750}

"com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)"
[7] =

{java.lang.StackTraceElement@1874}

"com.sun.faces.systest.Bean.verifyELResolverChainIsCorrectlyConfigured(Bean.java:103)"






[JAVASERVERFACES-2105] systest-per-webapp: ReplaceVariableResolverAndAddELResolverProgrammaticallyTestCase Fails On AIX Created: 12/Jun/11  Updated: 27/Apr/12  Resolved: 27/Apr/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: trunk
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rogerk Assignee: rogerk
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAVASERVERFACES-2106 systest-per-webapp: ReplaceVariableRe... Closed
Tags: test

 Description   

ReplaceVariableResolverAndAddELResolverProgrammaticallyTestCase is cleverly written to verify that ELResolvers are called in the right sequence. It does this by overriding the toString method (from the call to getValue:

context.getApplication().getELResolver().getValue(context.getELContext(), null,
new Object() {

@Override
public String toString()

{ Bean.captureStackTrace(context); return "traceResolution"; }

});

Bean.captureStackTrace captures the stack trace for the current thread - so if the thread is inside ImplicitObjectELResolver that will show up in the stacktrace. This section of code loops through the stack trace elements looking for the element that contains the string (for example) "ImplicitObjectELResolver". The code is written to loop through 4 times:

for (int i = 0; i < 4; i++) {
StackTraceElement cur = stackTrace[i];
stackTraceElement = cur.toString();
if (!(stackTraceElement.contains("Thread") ||
stackTraceElement.contains("com.sun.faces.systest.Bean")))

{ message.append("<p>").append(stackTraceElement).append("</p>"); break; }

}

On a non AIX machine this is fine as the stack trace elements are:

[0] =

{java.lang.StackTraceElement@7188}

"java.lang.Thread.getStackTrace(Thread.java:1503)"
[1] =

{java.lang.StackTraceElement@7189}

"com.sun.faces.systest.Bean.captureStackTrace(Bean.java:139)"
[2] =

{java.lang.StackTraceElement@7190}

"com.sun.faces.systest.Bean$1.toString(Bean.java:108)"
[3] =

{java.lang.StackTraceElement@7191}

"com.sun.faces.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:101)"
[4] =

{java.lang.StackTraceElement@7192}

"com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)"
[5] =

{java.lang.StackTraceElement@7193}

"com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)"
[6] =

{java.lang.StackTraceElement@7194}

"com.sun.faces.systest.Bean.verifyELResolverChainIsCorrectlyConfigured(Bean.java:103)

However on an AIX machine, the stack trace elements are:

[0] =

{java.lang.StackTraceElement@1084}

"java.lang.Thread.getStackTraceImpl(Native Method)"
[1] =

{java.lang.StackTraceElement@1152}

"java.lang.Thread.getStackTrace(Thread.java:1042)"
[2] =

{java.lang.StackTraceElement@1434}

"com.sun.faces.systest.Bean.captureStackTrace(Bean.java:139)"
[3] =

{java.lang.StackTraceElement@1508}

"com.sun.faces.systest.Bean$1.toString(Bean.java:108)"
[4] =

{java.lang.StackTraceElement@2600}

"com.sun.faces.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:101)"
[5] =

{java.lang.StackTraceElement@1662}

"com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)"
[6] =

{java.lang.StackTraceElement@1750}

"com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)"
[7] =

{java.lang.StackTraceElement@1874}

"com.sun.faces.systest.Bean.verifyELResolverChainIsCorrectlyConfigured(Bean.java:103)"






[JAVASERVERFACES-1939] nine systest-per-webapp-tests fail in multiple no_cluster virtual-server scenario Created: 06/Feb/11  Updated: 25/Oct/12  Resolved: 25/Oct/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_large

Tags: test

 Description   

The following nine systest-per-webapp tests failed for me when running in no_cluster virtual-server.

absolute-ordering
add-elresolver-and-replace-variableresolver-programmatically
disable-unicode-escaping
document-ordering
flash
jsp-flash
replace-variableresolver-and-add-elresolver-programmatically
replace-variableresolver-programmatically
request-char-encoding-no-session



 Comments   
Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.





[JAVASERVERFACES-1938] Add a test that asserts the InitFacesContext exists after ConfigureListener.contextInitialized() exits. Created: 03/Feb/11  Updated: 25/Oct/12  Resolved: 25/Oct/12

Status: Closed
Project: javaserverfaces
Component/s: build
Affects Version/s: None
Fix Version/s: None

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

Attachments: File jsf-lockhart-testapp.war     File knappsack-basic.war    
Status Whiteboard:

size_small importance_large

Tags: test

 Description   

The fix for GLASSFISH-15632 makes it so the InitFacesContext stick around a little longer so that Servlets and Filters can call FacesContext.getCurrentInstance() from their init() method.



 Comments   
Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.

Comment by Manfred Riem [ 25/Oct/12 ]

We cannot add a test for this particular case. The Mojarra runtime will not have access to InitFacesContext once the first request comes in since it will have been cleaned up BEFORE it hits Mojarra.





[JAVASERVERFACES-1928] Rework "com.sun.faces.el.TestNestedELResolver" to work in light of GLASSFISH-11984, GLASSFISH-15632 Created: 27/Jan/11  Updated: 26/Oct/12  Resolved: 26/Oct/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_medium

Tags: test

 Description   

This test simply does new ApplicationImpl(), this isn't enough any more. Run the test to see how it fails and fix it.



 Comments   
Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.

Comment by Manfred Riem [ 26/Oct/12 ]

Closing old issue out





[JAVASERVERFACES-1927] need to create a dev test for the case exercised by GLASSFISH-15632 Created: 27/Jan/11  Updated: 26/Oct/12  Resolved: 26/Oct/12

Status: Closed
Project: javaserverfaces
Component/s: build
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: sheetalv Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Status Whiteboard:

size_large importance_small

Tags: test

 Description   

As part of the fix for GF issue 11984, need to create a devtest for running a JSF app in as multi-virtual server env



 Comments   
Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.

Comment by Manfred Riem [ 26/Oct/12 ]

The new test harness has the ability to run test in virtual server mode. If a particular test is required to run in a virtual server environment add it to the test/virtual directory.





[JAVASERVERFACES-1836] Enhance groovy test to exercise dynamic modification. Created: 12/Oct/10  Updated: 08/Mar/13  Resolved: 08/Mar/13

Status: Closed
Project: javaserverfaces
Component/s: build
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File AgeComponent.patch    
Issuezilla Id: 1,836
Tags: test

 Description   

Issue 1655 is not truly fixed unless the dynamic script modification feature works.



 Comments   
Comment by Ed Burns [ 12/Oct/10 ]

Take ownership

Comment by Ed Burns [ 06/Apr/11 ]

This work can now proceed by fleshing out the test in jsf-test/JAVASERVERFACES-1655 so that dynamic reloading is exercised and shown to work. Make sure also to move test functionality from the jsf-systest groovy test (now commented out). Most importantly, the groovy top level composite component must be shown to work.

Comment by Ed Burns [ 18/Apr/11 ]

I have dynamism for UIComponent type artifacts. Need to replicate test for other type of artifacts, and also make sure that groovy top level composite component works.

Comment by Ed Burns [ 17/May/11 ]

Make sure that annotations work on Groovy classes.

Make sure that CDI annotations work on Groovy classes.

Comment by Manfred Riem [ 08/Mar/13 ]

Closing out because of inactivity





[JAVASERVERFACES-1686] errors deploying jsf-systest: WARNING: JSF1022: [${partial.state.saving}] Invalid value 'javax.faces.PARTIAL_STATE_SAVING' for configuration option 'true|false'. Valid values are '{3}'. Falling back to the default of '{4}'. Created: 24/May/10  Updated: 13/Nov/12  Resolved: 13/Nov/12

Status: Closed
Project: javaserverfaces
Component/s: lifecycle
Affects Version/s: 1.2_14
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,686
Status Whiteboard:

size_medium importance_small

Tags: test

 Description   

Investigate why this error message is not displaying properly.



 Comments   
Comment by Ed Burns [ 22/Jun/10 ]

Reassign these to edburns

Comment by Ed Burns [ 22/Jun/10 ]

This is clearly a P4





[JAVAMONEY-147] Fix broken Unit tests in RI Created: 27/Aug/15  Updated: 27/Aug/15  Resolved: 27/Aug/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.1, 1.2

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

Tags: implementation, test, test_issue

 Description   

Two unit tests fail for some time building Moneta (and Moneta-BP)

Failed tests: 
  DefaultMonetaryAmountFormatSymbolsTest.shouldPrintMonetaryAmount:66 expected [R$ 10,00] but found [R$10,00]
  DefaultMonetaryAmountFormatSymbolsTest.shouldQueryFromMonetaryAmount:77 expected [R$ 10,00] but found [R$10,00]

Needs to be fixed in both.



 Comments   
Comment by otaviojava [ 27/Aug/15 ]

Fixed





[JAVAMONEY-146] RoundedMoney not immutable Created: 27/Aug/15  Updated: 04/Jun/16

Status: Reopened
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.2

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

Tags: test

 Description   

There's a warning by the TCK seemingly since 1.0 about RoundedMoney not being immutable:

Warning: found non immutable MonetaryAmountType: org.javamoney.moneta.RoundedMoney, details: 
Expected: org.javamoney.moneta.RoundedMoney to be IMMUTABLE
     but: org.javamoney.moneta.RoundedMoney is actually NOT_IMMUTABLE
    Reasons:
        Field can have an abstract type (javax.money.MonetaryRounding) assigned to it. [Field: rounding, Class: org.javamoney.moneta.RoundedMoney]
        The 'this' reference is passed outwith the constructor. [Class: org.javamoney.moneta.RoundedMoney]
        The 'this' reference is passed outwith the constructor. [Class: org.javamoney.moneta.RoundedMoney]
        The 'this' reference is passed outwith the constructor. [Class: org.javamoney.moneta.RoundedMoney]
        The 'this' reference is passed outwith the constructor. [Class: org.javamoney.moneta.RoundedMoney]
    Allowed reasons:
        Field can have an abstract type (javax.money.CurrencyUnit) assigned to it. [Field: currency, Class: org.javamoney.moneta.RoundedMoney]
        Field can have an abstract type (javax.money.CurrencyUnit) assigned to it. [Field: currency, Class: org.javamoney.moneta.RoundedMoney]
        Field can have an abstract type (javax.money.MonetaryOperator) assigned to it. [Field: rounding, Class: org.javamoney.moneta.RoundedMoney]

Is there a reason for it being not immutable, or can this be addressed?



 Comments   
Comment by otaviojava [ 27/Aug/15 ]

It's talking of the Monetary Operator that could be a mutable type, it's looking just to the interface.
But don't worry, the implementations are immutables and I checked again the RoundedMoney. It's immutable.

Comment by keilw [ 28/Aug/15 ]

The message refers to other issues, especially this used outside the constructor of RoundedMoney in places the add() method:

MoneyUtils.checkAmountParameter(amount, this.currency);

Let's fix it so hopefully all warnings go away.

Comment by otaviojava [ 28/Aug/15 ]

Thanks Werner by the information.
I am looking it so or do you are fixing it?





Ensure, RI-BP is in sync (JAVAMONEY-124)

[JAVAMONEY-145] TCK Tests fail in Moneta which pass Moneta-BP Created: 23/Aug/15  Updated: 27/Aug/15  Resolved: 26/Aug/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.1

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

Tags: tck-red, test

 Description   

After recent changes primarily to Moneta, TCK fails in 42 cases, see https://travis-ci.org/JavaMoney/javamoney-tck-usage-example

The same tests agaisnts Moneta-BP 1.0.1 all pass:
https://travis-ci.org/JavaMoney/javamoney-tck-usage-example-bp

This is an absolute showstopper. Not a single test must fail, if necessary "improvements" rolled back, or applied in a compatible way to Moneta-BP without breaking any tests there.



 Comments   
Comment by otaviojava [ 24/Aug/15 ]

There are several problems on TCK:

  • The RI is on Java 8, but the TCK runs on Java 7.
  • The TCK depends of moneta-core
  • The exception talks about, class def not found exception of the class javax.money.convert.MonetaryConversions, that is on the API, and the project hasn't the money-api as dependency.
Comment by keilw [ 24/Aug/15 ]

The RI is on Java 7 and 8, please accept that once and for all. Regardless of PR or declaring Java 7 "End of Life" real users especially in the EE world will keep using Java 7 for at least another 5 to 10 years. And even if a possible new JSR was some day added to Java 10 or 11, the standalone version must then also support the "older" JSR e.g. 8 or 9

The TCK is built against Moneta-BP and Java 7 because there are 2 RIs (for 7 and 8) but only one TCK.
There is no dependency to moneta-core. dependencyManagement would allow to do this in future (in fact, against the modular 1.0.2 branch of Moneta if you run them, only 4 tests fail, not 42) but the current build on Travis compiles the TCK against Moneta-BP 1.0.1-SNAPSHOT, no core there.

The exception says Could not initialize class javax.money.convert.MonetaryConversions that means, the SPI there has a problem created by changes you made in Moneta.
While Moneta-BP works perfectly fine for the same test. So you have to find and fix what breaks conversion SPI in the Java 8 flavor or Moneta to ensure, they behave structurally identical (regardless of their internals)

Spring manages to do that, and since Spring is also among top users of JSR 354, we must not break compatibility by uncoordinated changes.

Comment by keilw [ 24/Aug/15 ]

Just look at
https://github.com/JavaMoney/jsr354-ri-bp/tree/master/src/main/java/org/javamoney/moneta/internal/convert
vs.
https://github.com/JavaMoney/jsr354-ri/tree/master/src/main/java/org/javamoney/moneta/internal/convert

There are at least 5 classes missing in Moneta-BP. Hence, the conversion part is structurally incompatible, which explains why the SPI of MonetaryConversions gets confused and TCK fails in this area. Either add everything correctly to the BP or those changes can't be accepted. They're simply BUGS if they break the TCK.

Comment by otaviojava [ 24/Aug/15 ]

I don't say: "We cannot support the BP", but in the fact there is a problem to put the target on Java 7.
When you put the source and the target to 1.7, the project just will support resources 1.7 or lesser. The resource that the RI uses is lambda, stream, predicate, filter, etc. many stuffs from 1.8. The 1.8 is greater than 1.7, so will not run.

If fixed, but how?

  • I created a new branch on jsr-354-tck, on the pom, I put target and source to 1.8, now resources from 1.8 can run very well, and I just put the RI dependency. Install locally, using the "mvn clean install" command.
  • Then I excuted the javamoney-tck-usage-example and ran very well.

If you want, I can push this new branch.

Comment by keilw [ 24/Aug/15 ]

Sorry but that's totally unnecessary.

The TCK builds against Java 7 and creates a JAR that executes against both Java 7 and 8.
That worked before and must continue to work like that for the entire lifecycle of JavaMoney 1.x (until some day there could be a new JSR)

This branch is useless. There is just one TCK.

The goal is to fix the RI by aligning both development strains, not "doctor the TCK".

Thanks

Comment by otaviojava [ 24/Aug/15 ]

I just find one way to just run a specific implementation. Could I just put the other implementations as "provided"?
This way, the tck runs very well too.
Like this, on jsr354-tck:

diff --git a/pom.xml b/pom.xml
index 907abca..78af29d 100644
--- a/pom.xml
+++ b/pom.xml
@@ -120,6 +120,7 @@
                                <groupId>org.javamoney</groupId>
                                <artifactId>moneta-bp</artifactId>
                                <version>${ri.version}</version>
+                               <scope>provided</scope>
                                <type>jar</type>
                        </dependency>
 
@@ -127,12 +128,14 @@
                                <groupId>org.javamoney.moneta</groupId>
                                <artifactId>moneta-core</artifactId>
                                <version>${ri.version}</version>
+                               <scope>provided</scope>
                        </dependency>
 
                        <dependency>
                                <groupId>org.javamoney</groupId>
                                <artifactId>moneta-core</artifactId>
                                <version>${ri.version}</version>
+                               <scope>provided</scope>
                        </dependency>
 

Comment by keilw [ 25/Aug/15 ]

Feel free to create a pull request against the tck project, but as running the same TCK against 1.0 artifacts, 1.0.1 or even 1.0.2 Snapshot shows, there is no need to rebuild the TCK once the JAR is available on JFrog.

In fact, I think entries like moneta-core were historic. Moneta-BP is just a single JAR and only at Runtime (in tck-usage-example*) it matters if you chose a JAR or POM for it.

Comment by otaviojava [ 25/Aug/15 ]

I can't create remote branch, I haven't authorization to create remote branch anymore.

Comment by keilw [ 25/Aug/15 ]

No freaking branch please, that's why TCK was better protected (it is also the Spec Lead's duty mostly to create and maintain the TCK) just fork it locally and raise a pull request. Everybody can do that even with API

Comment by keilw [ 25/Aug/15 ]

However, please don't waste your time "fixing" something that isn't broken.
If we have dependencyManagement for say JUnit or any other artifact that currently isn't used, that is not your concern. What matters are the actually used dependencies and these work as TCK on master builds fine.

So if you think a 1.0.1-SNAPSHOT of Moneta was worth releasing some day, please fix that to pass the TCK.

Comment by keilw [ 25/Aug/15 ]

In fact "provided" is absolutely wrong here for Moneta ;-/
http://stackoverflow.com/questions/6646959/difference-between-maven-scope-compile-and-provided-for-jar-packaging explains:
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.

Neither moneta-bp nor moneta are "provided" by the TCK or the JDK (until Java 10 or beyond there is no Money RI being part of the JDK ) they must be retrieved from either the local or shared Maven repos when building the TCK. So forget about ANYTHING in the TCK. It works, and we'll clean up some of dependencyManagement when there's time, it isn't used right now.

Comment by otaviojava [ 25/Aug/15 ]

Werner, feel free to neither put "provided" on jsr354-tck or remove from javamoney-tck-usage-example.

But I really prefer the first one, because It's don't make sense to me, test a JSR-354 implementation with other implementation inside. it's smell code.
How will we test a car X with a car Y also in the test?
JSR354-TCK, for me, just need have the RI to compile, the provided scope, and than when you test your implementation, you put it, the implementation, here to run. It's the easier way.

Comment by keilw [ 25/Aug/15 ]

How often, it has the RI. Moneta-BP is the RI. Both Moneta (which should be called "moneta-java8" as we do in JSR 363 downstream projects now) and Moneta-BP (which should ideally have been called "Moneta" or "Moneta-java7") are the RI, they are structurally identical. Which is why Jadira works with both, see this discussion I had with Chris https://github.com/JadiraOrg/jadira/issues/44 and so do other frameworks. You must not break that by introducing something like "car z" with just 3 wheels to stay with your analogy

Comment by otaviojava [ 25/Aug/15 ]

Werner I did a question the about the color and you answered me with the size , it's really not make sense this conversation.
Fine, I will fix looking to javamoney-tck-usage-example.

Comment by keilw [ 25/Aug/15 ]

You're losing me here, what "color"? Anyway, the whole idea with "provided" was wrong. Unless you have a multi-module Maven project where module A, B and C are built, with C having a dependency on A, "provided" will not work for standalone libraries. Moneta is not "provided" with the JDK (and won't be for at least another 3-5 years or more) and compiling the TCK it isn't there if you set this to "provided".

When executing TCKRunner the "SUT" is say moneta-1.0.1-SNAPSHOT and the TCK verifies the signature of that SUT at runtime, it's not compiling the TCK JAR again.

The only place you can fix this is Moneta 1.0.1-SNAPSHOT, TCK and usage examples are perfectly fine. 1.0 passes and 1.0.1-SNAPSHOT BP does, so manipulations to Moneta 1.0.1-SNAPSHOT caused the TCK to break. And also several demos in "javamoney-examples".

Comment by keilw [ 26/Aug/15 ]

It is still fairly bizarre why the problem only started with (also single JAR) moneta 1.0.1 and never hit 1.0 but excluding just moneta-bp seems to solve it for EVERY SR branch of moneta

The whole core exclusion was bogus and unnecessary, since a proper BOM for (modular) 1.0.2-SNAPSHOT requires none of them directly. Nor should they be excluded, on the contrary.

Comment by keilw [ 26/Aug/15 ]

And Otavio, please try to avoid all the verbose branches. Use Git as it's intended and FORK into your personal GitHub user. Then create a pull-request from there. The only branch that's justified is the "modular feature" branch right now for parallel development of 1.0.1 (in master) and 1.0.2. Everything else use forks (especially since Travis-CI has a permanent memory and lists all those branches, whether broken builds or not)

Comment by otaviojava [ 26/Aug/15 ]

The fact is, there is not modularization on 1.0.1 yet.
But ok, you finally understand what I was saying the problem was fixed.

Comment by keilw [ 27/Aug/15 ]

It doesn't explain why 1.0 was fine without that?
Since the "core" and other parts were not even used for a good reason, there was no need to uncomment that or exclude. Your diagram mixed up the modularized 1.0.2 and earlier releases by showing "core" with "moneta-bp". That makes no sense.

While TCK passes at the moment, the structural differences must be resolved anyway. SigTest has to pass, too.

Comment by otaviojava [ 27/Aug/15 ]

Werner, don't worry...
The important thing is the Java understand me and the code passed.
If you see the discussion, I spend too much time to explain what the problem and how the maven works.
And you just saying: "The problem is on moneta and not on TCK".
The next time, I will not explain nothing, just fix the problem.

Comment by keilw [ 27/Aug/15 ]

I understand Maven and used it for over 12 years. In fact, I gave talks to the Eclipse community 10 years ago about Maven and Eclipse before they even thought about writing something like M2E or M2WTP. Getting confused between a modularized version and one with a single JAR was what probably took you a bit of time. Especially drawings that do not describe how it really works. E.g. the Maven BOM.

The fact that it worked without any tweaks to the POM remains. As it failed only Moneta "1.0.1-SNAPSHOT" in master.
As well as a structural deficit created by changes to Moneta that were not yet applied to Moneta-BP (3 or more classes simply missing in just one package alone)
Every public class an application finds in Moneta must exist in Moneta-BP in the same place (there could be slight deviations once modularized, but ideally the package structure should be the same even in a single JAR before that)

Comment by otaviojava [ 27/Aug/15 ]

"The fact of you eat bread everyday, don't make you a baker." Unknown.
Just sorry, I just expect something like "I am wrong sorry", but ok the most important think is the Java code understand me.

Comment by keilw [ 27/Aug/15 ]

I bake software for a long time. Or more importantly design recipes for it. You can put bread into an oven on a conveyor belt and think you're a baker, but more or less do manual labour without knowing what's in it

Part of the change was helpful, but the "core" stuff being bothered with in the proposed PR showed, you did not fully understand the way the TCK and its example work. The part that matters (moneta / moneta-bp) was helpful, so thanks for that.





[JAVAMONEY-143] JavaMoney TCK Usage Example results differ from TCKRunner Created: 29/Jul/15  Updated: 04/Jun/16

Status: Open
Project: javamoney
Component/s: Test: TCK
Affects Version/s: 1.0
Fix Version/s: 1.2

Type: Bug 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:
Blocks
blocks JAVAMONEY-141 Pass TCK Resolved
Tags: tck-red, test, testing

 Description   

When trying to run the SE 8 variant of TCK Usage Example (https://github.com/JavaMoney/javamoney-tck-usage-example) against different approaches to modularizing the RI, it occured the example project always keeps running just one version of the TCK and (probably worse) also does not seem to switch the TCK from Moneta-BP to Moneta.

Running java org.javamoney.tck.TCKRunner as suggested directly from the TCK produces a different result than running the TCK Example.

It feels changing

<impl.version>1.0</impl.version>

or other aspects of the implementation details in the POM has no effect on which implementation is actually used. The TCK 1.0 deployed to MavenCentral/JCenter (or a copy in your local Maven repo) seems to be used regardless of implementation details. Even if another TCK version (like "1.0.1-SNAPSHOT" or similar) is available in the local Maven repo and "org.javamoney.tck.version" adjusted accordingly the TCK Usage example seems to ignore that and shows all tests pass, while running java org.javamoney.tck.TCKRunner against the same implementation produces different results.



 Comments   
Comment by keilw [ 29/Jul/15 ]

Adjusting dependencies to a version of Moneta with sub-modules, Maven dependencies look like the version is picked up correctly, and there all 233 TCK tests pass. Running TCKRunner from the TCK project directly causes 11 tests to fail when Moneta is not in a single JAR.
That discrepancy should be resolved, The test does in fact simply call

 TCKRunner.main(new String[0]);

so it looks like a difference in class-loading of relevant modules through Maven starting unit tests and a command line or batch calling TCKRunner. Even though at compile-time there is no error or missing dependency.

Another key difference to analyze is TCKTestSetup.getMonetaryOperators4Test() which only references 2 instead of 10 instances of MonetaryOperator. Tweaking that within the TCK should show, if this difference in test configuration affects the result or it's mainly the way TCKRunnner is called.

Comment by keilw [ 31/Jul/15 ]

Similar to https://github.com/unitsofmeasurement/uom-tools TCKRunner might implement javax.tools.Tool instead of the main method.

/* (non-Javadoc)
 * @see javax.tools.Tool#run(java.io.InputStream, java.io.OutputStream, java.io.OutputStream, java.lang.String[])
 */
@Override
public int run(InputStream in, OutputStream out, OutputStream err,
			String... arguments) {

Allowing it to be called like

Tool tckRunner = new TCKRunner();
int errorCode = tckRunner.run(System.in, System.out, System.err, args);
if (errorCode == 0) {
    System.out.println("Success.");
} else {
    System.err.println("Error.");
}




[JAVAMONEY-142] Define some tests as "integration-test" Created: 27/Jul/15  Updated: 23/Aug/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

Issue Links:
Related
is related to JAVAMONEY-125 Add missing tests Open
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






Make Moneta Modular (JAVAMONEY-137)

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

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.2

Type: Sub-task Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed 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... Open
Related
is related to JAVAMONEY-140 Convert Module Open
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





Ensure, RI-BP is in sync (JAVAMONEY-124)

[JAVAMONEY-135] Ensure Unit Test coverage and results are comparable Created: 22/Jun/15  Updated: 04/Jun/16

Status: Reopened
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.2

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

Issue Links:
Relates
relates to JAVAMONEY-104 Make coverage visible on all key arti... Open
Tags: test

 Description   

Currently there is a large difference between Moneta and Moneta-BP when it comes to test-coverage and results:
Moneta (#307: https://travis-ci.org/JavaMoney/jsr354-ri/builds/67812171)
Tests run: 601, Failures: 21, Errors: 0, Skipped: 0
Moneta-BP (#87: https://travis-ci.org/JavaMoney/jsr354-ri-bp/builds/67811489)
Tests run: 440, Failures: 19, Errors: 0, Skipped: 0

The total number of tests differs drastically. The number of failures less, but it should be 0 or close to 0 (or rather a few @Ignore should there be a good reason why it fails) in both cases.



 Comments   
Comment by keilw [ 22/Jun/15 ]

We do have some external dependencies, especially IMF or ECB conversion providers are Integration Tests not just simple "Unit Tests" in their nature, but ideally those should all be green till the 3rd party system changes or breaks something, too

Comment by otaviojava [ 22/Jun/15 ]

The solution to fix JAVA MONEY-131, has broke some tests.
The issue was reopened and the code rollbacked.

Comment by keilw [ 22/Jun/15 ]

I am sure it did not solve the 200 "missing" tests in Moneta-BP?

Comment by otaviojava [ 22/Jun/15 ]

this time you are wrong, I fixed on moneta-bp too.
https://github.com/JavaMoney/jsr354-ri-bp/pull/16

Comment by keilw [ 22/Jun/15 ]

Tests run: 440, Failures: 0
vs.
Tests run: 601, Failures: 2

is not comparable test coverage. Moneta-BP is not a second class citizen, in fact till Java EE 8 gets SE 8 Enterprise ready it is first class.

Comment by keilw [ 08/Feb/16 ]

This https://coveralls.io/github/JavaMoney/jsr354-ri does not even exist for jsr354-bp. It must be set up the same way it was for Moneta.





Ensure, RI-BP is in sync (JAVAMONEY-124)

[JAVAMONEY-134] Apply SigTest to ensure, Moneta and Moneta-BP match Created: 22/Jun/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

Status: Resolved
Project: javamoney
Component/s: Impl: RI, Test: TCK
Affects Version/s: None
Fix Version/s: 1.1

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

Tags: test

 Description   

Similar to JSR 107 (https://github.com/jsr107/jsr107tck/tree/master/sigtest)
we must apply SigTest, even more important since we got 2 RIs, not just 1 like 107 or most other JSRs

See https://sigtest.java.net/sigtest_docs.html on how to use SigTest.



 Comments   
Comment by otaviojava [ 22/Jun/15 ]

Agree with you, but It could be on version 1.0.2, we need to close the version 1.0.1 on Moneta.

Comment by keilw [ 22/Jun/15 ]

They are totally inconsistent right now, and unless we are pushed onto an obvious mismatch like this recent bug (where are tests in both Moneta and BP to demonstrate it was fixed?) nobody really knows if they match or not.

Comment by otaviojava [ 22/Jun/15 ]

In this case of bug about the over configuration, as I told on the issue, was on line that was removed one test there, does not make sense to me.

Comment by keilw [ 22/Jun/15 ]

That does not spare us the need to ensure both RIs are in sync from an API/signature point of view.

Comment by otaviojava [ 22/Jun/15 ]

Could you read again my first comment?
I agreed with you, but we could use the iterative and incremental development software.

Comment by keilw [ 22/Jun/15 ]

This JSR is special, there is no JSR I recall with 2 functionally identical parallel RIs. Hence we need to take extra care to preserve their integrity and consistency.

Comment by keilw [ 18/Jan/16 ]

Seems a duplicate of the "broken compatibility" issue family.





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

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

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

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

 Description   

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






[GLASSFISH-20855] move and mavenize major developer tests from glassfish v2 repository to trunk/appserver/tests Created: 15/Oct/13  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: build_system, test
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 weeks
Time Spent: Not Specified
Original Estimate: 2 weeks
Environment:

any


Tags: devtest, glassfish, maven, test

 Description   
  • Current developer test suite are documented here: https://wikis.oracle.com/display/glassfish/DeveloperTestDashboard
  • Those test suites are owned by particular developer, they are responsible for monitoring the test results.
  • They can take some time to run, hence they are not required for every checkin but depending on the changes (owner will likely request it)

The codeline comes from GlassFish 2.x, the test codebase is still located in the v2 svn repository: https://svn.java.net/svn/glassfish~v2/trunk/appserv-tests/devtests/

Those tests suite are still developed, and are used to test the current GlassFish codeline.

  • They are using the infrastructure that is provided by the old workspace
  • It is based on ant and is sometime platform dependent (i.e, can't work on windows).
  • It requires shell environment configuration to run (PATH and environment variables used by the tests)

This improvement is about mavenizing some of those devtests with as few changes as possible, in order to provide the following:

  • No change in the source code
  • Only maven / jdk required, everything else is downloaded and configured on the fly via maven
  • A pom.xml wrapping the tests scenario (e.g. with profiles)
  • Test workspace nested under appserver/tests, in order to be tagged be each release

Some things nice to have:

  • Windows / UNIX profiles to help sorting the suite that supports windows or not.
  • Generation of standard junit/testng report for easier CI
  • Test coverage infra (with cobertura)

Here are the in-scope test suites:

  • deployment
  • ejb
  • security
  • admin
  • webtier

Eventually, some documentation should be written under appserver/tests to guide developers.






[GLASSFISH-19654] Unable to specify a DataSource in an embedded EJB container Created: 08/Feb/13  Updated: 11/Feb/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: skwirking Assignee: marina vatkina
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: datasource, ejb-container, test, testing

 Description   

There is no way to programmatically specify the datasource for an EJB container. If a module is written to make use of a JTA datasource (by declaring the following in the module's persistence.xml):

<jta-data-source>jdbc/myDS</jta-data-source>

Then it seems impossible to load this module into an embedded EJB container, because the container cannot be configured to set up a datasource, and so the module cannot find one and deployment fails.

Being able to specify datasource details in an embedded EJB container is critical for testing, where we want to use a different datasource but be sure we are testing the same artifact/jar/war file that will eventually be released.

Other embedded EJB containers use properties to achieve this:

However, the only relevant property for glassfish is
org.glassfish.ejb.embedded.glassfish.configuration.file
which could in theory be used to specify a domain.xml file with a pre-configured test datasource. Unfortunately, this property is ignored unless the following property is set
org.glassfish.ejb.embedded.glassfish.installation.root
and to set this second property requires an existing glassfish installtion - thus ruining the project portability I was trying to achieve by using embedded glassfish in the first place.

See here for the forum post I made which describes other awkward and limited workarounds:
http://stackoverflow.com/questions/14748280/how-to-define-a-test-datasource-for-an-embedded-ejb-container



 Comments   
Comment by marina vatkina [ 08/Feb/13 ]

Embeddable EJB container is designed to work either with pre-installed GlassFish, where any resource can be added using CLI or UI, or by specifying the config file with the pre-defined resources.

Changing to RFE

Comment by skwirking [ 11/Feb/13 ]

I agree that the feature to configure a datasource via EJB Container properties should be a feature request.

However, specifying the config file (domain.xml) only works if the installation root is also specified. If the installation root is not specified, the config file option is ignored.

Thus, it appears to be impossible to set up a datasource inside an EJB Container without having an existing installation of GlassFish - and for this reason I respectfully request that the issue still be marked as a 'bug'.





[CHANNELFINDER-27] Add scripts for system authZ test setup Created: 05/Jan/12  Updated: 25/Jan/12

Status: Open
Project: channelfinder
Component/s: Service
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Ralph Lange Assignee: carcassi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours

Tags: pam, test

 Description   

Similar to the ldif database file provided to help set up the environment for the integration tests, there should be scripts to set up the necessary users and groups for using PAM based authorization.






Generated at Sun Jul 24 18:08:37 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.