Hi Ludmila,

actually this isn't really a Gump issue as I tested things outside of
Gump - but my investigation was triggered by your initial emails on the
Gump list so I copy it there.

So far I've played with the Java OSS projects I spend most of my current
time on: Ant, XMLUnit, Commons Compress and the Compress Antlib.

For all four of them javadoc is now failing because of too many errors.
Many of those errors don't even cause warnings in Java7 - like
unexpected closing tags.

javadoc used to create the output directory even when it didn't create
any output (e.g. when there were no sources to document) - it no longer
does, which probably is fine but breaks Ant 1.9.2's javadoc task in such
cases.  A fix is in Ant's trunk.

java.util.zip.ZipEntry's setTime or getTime now rounds up to the next
even second while it used to round down.  This broke some tests in Ant -
fix is in trunk - and likely in Commons Compress but the fix has been
applied before the latest release already.  Subtle changes like this are
going to cause debugging headaches for people so you better document
them somewhere.

I'm still investigating one issue with pack200 and I may even be tempted
to open a bug ticket for it - TBH the last time I tried to report an
issue with JDK7 it's been my worst bug-tracker experience ever.  If it
hasn't changed I'll likely skip it altogether.

The problem is pack200 seems to modify the timestamp of jar entries.
When pack-ing a jar and unpacking it again on a machine not running in
GMT the timestamp is modified - it looks as if pack200 was translating
the timestamp from GMT to the time in my timezone when creating the pack
file but not reverting that change when unpacking it.

The pack200 issue should be the only one still causing failures for the
compress antlib by now.


To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Reply via email to