Dear Fop-Devs,
I hope this commit does not break gump - if so I'll revert it.
What this does: If you set properties to point to a java 1.4
installation, it will try to verify if fop uses only the classes
available there and output a warning.
The retroweaving process is currently done but
On 20.08.2008 15:40:08 Max Berger wrote:
Dear Fop-Devs,
I hope this commit does not break gump - if so I'll revert it.
No, we'll try to fix the Gump run first! This is useful after all. I'll
look into the Gump descriptor right away to avoid any problems I can fix
before the next run.
What
I don't think it is Max... looks like @since 1.4.
/**
* Returns a ttBoolean/tt instance representing the specified
* ttboolean/tt value. If the specified ttboolean/tt value
* is tttrue/tt, this method returns ttBoolean.TRUE/tt;
* if it is ttfalse/tt, this method returns
Adrian,
Adrian Cumiskey schrieb:
I don't think it is Max... looks like @since 1.4.
you're right - looks like the other valueOf methods (for integer, etc.)
where introduced in 1.5, and this one was indeed introduced in 1.4.
I've reverted that change.
Apparently retroweaver still modifies calls
Dear Fop-Devs,
further insight on retroweaver:
I've downloaded and patched retroweaver not to modify Boolean.valueOf,
which is now correctly verified against 1.4. I could add the (patched)
artifact to fops lib/build. I will try and discuss with the retroweaver
maintainer about options to
Hi Max,
Personally I'm fine with it until we take a future retroweaver release containing your patch. So +1
from me.
Adrian.
Max Berger wrote:
Dear Fop-Devs,
further insight on retroweaver:
I've downloaded and patched retroweaver not to modify Boolean.valueOf,
which is now correctly
As long as we don't distribute the unreleased package in one of our own
releases, it's fine. We need to apply the same policy as we do for other
libraries. If the source distribution doesn't contain those build
dependencies, it's ok to keep the unreleased package.
On 20.08.2008 18:31:46 Max
