[JAVAMONEY-124] Ensure, RI-BP is in sync Created: 18/May/15  Updated: 29/May/15

Status: In Progress
Project: javamoney
Component/s: Impl: RI, Library: JavaMoney Extensions
Affects Version/s: 1.1
Fix Version/s: 1.1

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVAMONEY-126 Remove MonetaryRoundedFactory unless ... Sub-task Closed  
JAVAMONEY-127 Remove HistoricConversionQueryBuilder... Sub-task Resolved  
JAVAMONEY-129 Add ofMinor to all affected *Money c... Sub-task Resolved otaviojava  
JAVAMONEY-130 Remove ExchangeRateException Sub-task Resolved keilw  
JAVAMONEY-133 Align naming of RI and RI-BP elements Sub-task Resolved otaviojava  
JAVAMONEY-134 Apply SigTest to ensure, Moneta and M... Sub-task Resolved keilw  
JAVAMONEY-135 Ensure Unit Test coverage and results... Sub-task Reopened otaviojava  
JAVAMONEY-145 TCK Tests fail in Moneta which pass M... Sub-task Resolved otaviojava  
JAVAMONEY-158 Ensure JApiCmp reports are comparable... Sub-task Open  
Tags: backport, design

 Description   

There's a significant number of elements like
HistoricConversionQueryBuilder, MonetaryRoundedFactory, etc. all recently added to Moneta without a proper BP equivalent.

Nothing should be in the (Java SE 8) RI that does not exist in the BP either. Especially some "API like" elements along the lines of MonetaryRoundedFactory should probably best go to a module of javamoney-lib instead.






[JAVAMONEY-159] API-BP 1.0 built with Java 8 Created: 07/Feb/16  Updated: 08/Feb/16

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

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

Tags: compiler, java7, java8

 Description   

Testing the proposed Moneta-BP 1.1 against a genuine Java 7 setup, it turned out, Money-API-BP 1.0 JAR deployed to MavenCentral is incompatible with Java 7 or before as it was compiled with Java 8, too.

Manifest-Version: 1.0
Bnd-LastModified: 1431977045490
Build-Jdk: 1.8.0
Built-By: Anatole
...

Causing a Java SE 7 console app to fail:

Exception in thread "main" java.lang.UnsupportedClassVersionError: javax/money/MonetaryAmount : Unsupported major.minor version 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2625)
	at java.lang.Class.getMethod0(Class.java:2866)
	at java.lang.Class.getMethod(Class.java:1676)
	at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486)


 Comments   
Comment by keilw [ 07/Feb/16 ]

Seems there's a way to get the console app working in SE 7, but two different JARs exist for Moneta-BP, one (on JCenter/Bintray) compiled with Java 7, the other one against Java 8. That alone should be cleaned up as soon as possible.

Comment by otaviojava [ 08/Feb/16 ]

Werner, just compile the new version with Java 7,

Comment by keilw [ 08/Feb/16 ]

That does not solve above problem. The Binary JARs were built with different JDKs, something that can only be solved with a whole new delivery of the API to (one of) those repositories.





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

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

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

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.





Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-148] Analyze Dependencies Created: 27/Aug/15  Updated: 27/Aug/15

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

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

Tags: dependencies, dependency

 Description   

To verify progress of the modularized code and compare it to the monolithic version, one or several dependency analysis tools shall be applied like:






[JAVAMONEY-146] RoundedMoney not immutable Created: 27/Aug/15  Updated: 28/Aug/15

Status: Reopened
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1, 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?





[JAVAMONEY-155] make ConvertNumberValue public Created: 25/Sep/15  Updated: 27/Sep/15

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

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


 Description   

When extending NumberValue, implementing numberValue(Class<T> numberType) and numberValueExact(Class<T> numberType) is non-trivial.

For those willing to add a dependency on the RI, it would be nice to be able to use the ConvertNumberValue enum. Can it be made public?



 Comments   
Comment by otaviojava [ 27/Sep/15 ]

I don't think it's the good idea:

  • This class is not the goal of the API
  • Once this class public we need to take care any refactoring, in other words, any improvements or change in this class it will slower.
  • To remove this class one day if public it will spend more time, one to deprecated it and then to finally remove it.
Comment by keilw [ 27/Sep/15 ]

Well the same goes for other RI elements like MonetaryUtil which was public and has to be restored, or if it was to stay in a similar form MonetaryOperators and other RI level public elements. I don't see if we add all sorts of stuff in a function package why this should not be available the same way.

Comment by msgilligan [ 27/Sep/15 ]

The problem is that any class implementing NumberValue is required to implement

<T extends Number> T numberValue(Class<T> numberType)

which is essentially a requirement to convert to any of the built-in number types. So every implementation is being forced to implement this functionality.

Perhaps making ConvertNumberValue isn't the best API or implementation to make public. But something should be provided by the RI and possibly even specified in a future version of the API. In fact, I'd go so far as to say that an arbitrary Number to Number conversion should be included in the JDK itself.

Comment by msgilligan [ 27/Sep/15 ]

The ideal solution might be something like this:

1. NumberValue (or a provided subclass) would require a no-parameters numberValue() method that would return a Number of the same type that getNumberType() returns. This would be the default or preferred representation of the internal type.

abstract public Number numberValue();

I'm not sure whether there would need to be a no-parameters version of numberValueExact or if we could safely assume that the preferred conversion would always be exact.

2. This provided abstract base class would provide an implementation of numberValue(Class<T> numberType) similar to:

public <T extends Number> T numberValue(Class<T> numberType) {
        return ConvertNumberValue.of(numberType, numberValue());
}

Summary

Implementing classes would provide a method to convert to the optimal standard Number type. The framework itself would provide the method that converts to any of the standard subtypes. This would make creating an implementation of NumberValue much easier as only a conversion to a single type would be required. In most cases I would imagine that type would be Long, BigInteger, or BigDecimal.





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

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

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

Tags: bootstrap, spi

 Description   

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






[JAVAMONEY-136] Broken compatibility with 1.0 Created: 23/Jun/15  Updated: 02/Dec/15

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

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

Issue Links:
Blocks
is blocked by JAVAMONEY-152 Explore API consistency tools like Re... Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-417 javadoc since annotations missing Closed

 Description   

I did a clirr report comparing with 1.0 of the RI: The findings are as follows:

Method 'public javax.money.MonetaryQuery majorUnits()' was removed from org.javamoney.moneta.function.MonetaryOperators
Method 'public javax.money.MonetaryQuery minorUnits()' was removed from org.javamoney.moneta.function.MonetaryOperators

These two methods must be readded (we can deprecate them with links to the new locations on MonetaryQueries).

Maybe acceptable are:

org.javamoney.moneta.internal.convert.AbstractECBRateProvider isnt anymore a superclass of	org.javamoney.moneta.internal.convert.ECBCurrentRateProvider	
org.javamoney.moneta.internal.convert.AbstractECBRateProvider isnt anymore a superclass of		org.javamoney.moneta.internal.convert.ECBHistoric90RateProvider	
org.javamoney.moneta.internal.convert.AbstractECBRateProvider isnt anymore a superclass of	org.javamoney.moneta.internal.convert.ECBHistoricRateProvider


 Comments   
Comment by keilw [ 23/Jun/15 ]

As this was only run against Moneta-BP (SE 8 breaks the tool ) please ensure, to keep both in sync when fixing.

Comment by otaviojava [ 06/Jul/15 ]

Resolved on:
https://github.com/JavaMoney/jsr354-ri/pull/117
https://github.com/JavaMoney/jsr354-ri-bp/pull/18

Comment by keilw [ 06/Jul/15 ]

Was the clirr report run again where possible?

Comment by keilw [ 11/Sep/15 ]

Entire MonetaryUtil was deleted without warning or deprecation. It breaks compatibility with Moneta 1.0, so we have to bring it back even if @deprecated.

Comment by keilw [ 11/Sep/15 ]

Refers to Clirr or JDiff, too.

Comment by otaviojava [ 04/Nov/15 ]

`MonetaryUtil` returned as @deprecated.

Comment by keilw [ 04/Nov/15 ]

It's OK to deprecate one class as long as it remains there for some time (see Oracle's plans for deprecation in Java 9, we might use that at a later point like "supercedes", etc. )

Comment by keilw [ 02/Dec/15 ]

As of now, revapi Maven plugin looks like it may have issues prior to Java 8. Hence both builds are broken.
Aside from configuration and customization of revapi to gracefully ignore some of its errors, we may have to look into Travis-CI build-triggers: https://docs.travis-ci.com/user/triggering-builds/
As the only way to run revapi after a Java 7 based build job could be via such trigger.





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

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

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-137] Make Moneta Modular Created: 16/Jul/15  Updated: 18/Jan/16

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVAMONEY-138 Core Module Sub-task Open keilw  
JAVAMONEY-139 Format Module Sub-task Resolved  
JAVAMONEY-140 Convert Module Sub-task Open keilw  
JAVAMONEY-141 Pass TCK Sub-task Resolved keilw  
JAVAMONEY-148 Analyze Dependencies Sub-task Open keilw  
Tags: modules

 Description   

Anticipating future Java versions beyond 9 (Jigsaw) Moneta (and Moneta BP which will be required as "standalone" RI even if some day one could be added to platform umbrella) we plan to break Moneta into smaller modules.

Especially the "convert" package, likely "format" and at least a "core" module underneath. Some of these modules may have companion modules, e.g. "convert" with default providers for ECB and IMF.






Make Moneta Modular (JAVAMONEY-137)

[JAVAMONEY-140] Convert Module Created: 16/Jul/15  Updated: 18/Jan/16

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

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

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

 Comments   
Comment by keilw [ 28/Jul/15 ]

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

Comment by otaviojava [ 28/Jul/15 ]

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

Comment by keilw [ 28/Jul/15 ]

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

Comment by keilw [ 28/Jul/15 ]

The mailing list was clear about

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

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

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

Comment by otaviojava [ 28/Jul/15 ]

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

Comment by keilw [ 28/Jul/15 ]

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

Comment by otaviojava [ 28/Jul/15 ]

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

Comment by keilw [ 28/Jul/15 ]

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

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

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

Comment by otaviojava [ 28/Jul/15 ]

Thanks, but don't worry I did it.

Comment by keilw [ 28/Jul/15 ]

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

Comment by keilw [ 28/Jul/15 ]

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

Comment by otaviojava [ 28/Jul/15 ]

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

Comment by keilw [ 28/Jul/15 ]

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

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

Comment by otaviojava [ 28/Jul/15 ]

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

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

long done

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

Comment by keilw [ 01/Aug/15 ]

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

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

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

Comment by otaviojava [ 01/Aug/15 ]

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

Comment by otaviojava [ 01/Aug/15 ]

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

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

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

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

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

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

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

Referencies:

Comment by keilw [ 01/Aug/15 ]

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

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

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

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

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

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

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

Comment by otaviojava [ 01/Aug/15 ]

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

Comment by keilw [ 01/Aug/15 ]

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

Comment by otaviojava [ 01/Aug/15 ]

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

Comment by keilw [ 01/Aug/15 ]

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

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

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

Comment by keilw [ 01/Aug/15 ]

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

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

Comment by otaviojava [ 01/Aug/15 ]

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

Comment by keilw [ 01/Aug/15 ]

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

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

Comment by otaviojava [ 01/Aug/15 ]

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





Make Moneta Modular (JAVAMONEY-137)

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

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

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





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

[JAVAMONEY-158] Ensure JApiCmp reports are comparable for Moneta and Moneta-BP Created: 18/Jan/16  Updated: 18/Jan/16

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

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

Tags: design

 Description   

Using JApiCmp we have to ensure, the reports (including non-critical info or warning e.g. for added methods, etc.) are comparable or identical for Moneta and Moneta-BP.






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

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

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

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

 Description   

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

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

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






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

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

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

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

 Description   

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






[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






[JAVAMONEY-153] Language and clarity improvements Created: 23/Sep/15  Updated: 23/Sep/15

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

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

Attachments: PDF File JavaMoney_Specification_1.0-final-jeff-edits.pdf    
Tags: specissue

 Description   

Language corrections and specification clarity improvements. The improvement comments are visible through activation of the "Comments" window in Adobe PDF Reader.



 Comments   
Comment by keilw [ 23/Sep/15 ]

Since this is a change request to the spec, however minor found typos or other proposed changes may be, it can't be published without an official MR (thus target version 1.x which means a MR like 1.1, etc.)





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

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

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


 Description   

See PR #52 on Github

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

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

instead of

public abstract Class<?> getNumberType();


 Comments   
Comment by otaviojava [ 27/Sep/15 ]

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

Comment by keilw [ 27/Sep/15 ]

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

Comment by otaviojava [ 27/Sep/15 ]

Werner, do you mind explain more what is MR?

Comment by keilw [ 27/Sep/15 ]

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

Comment by otaviojava [ 27/Sep/15 ]

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

Comment by msgilligan [ 28/Sep/15 ]

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

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

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

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





[JAVAMONEY-104] Make coverage visible on all key artifacts Created: 13/May/15  Updated: 08/Feb/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.1

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

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

 Description   

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






[JAVAMONEY-106] Clarify and document RI on JavaMoney page Created: 13/May/15  Updated: 08/Feb/16

Status: In Progress
Project: javamoney
Component/s: General: Build and quality management, Impl: RI
Affects Version/s: 1.0
Fix Version/s: 1.1

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

Tags: documentation, website

 Description   

While jcp.org will provide download links to official releases, many people likely will either use Maven settings or visit JavaMoney.org.

There http://javamoney.github.io/ri.html RI/Moneta is still presented as "1.0-RC1" and there's no clarification about 2 flavors of the RI for Java SE 8 or above and the still more widely expected one running SE 6/7, Android or Java ME.

This should be clarified and explained in the Readme.



 Comments   
Comment by keilw [ 08/Feb/16 ]

There's a need to update this page whenever 1.(0.)1 goes live.





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

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

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

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

 Description   

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



 Comments   
Comment by keilw [ 09/Feb/16 ]

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





Generated at Sun Feb 14 06:42:01 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.