Style of JavaDoc is Broken

[marchof]

Since release 0.6.3 the formatting of the JavaDoc shipped with the documentation is broken.

[Godin]

@marchof FYI this happens, when JDK 7 is used for build, but I don't know exact reason.

I'm pretty sure that release of 0.6.3 was done with JDK 6 (we have troubles with signing artifacts using tool from JDK 7), however I rechecked zip-distribution and it looks correct.

I changed configuration in Cloudbees, so that style of Javadoc in snapshot and so on site will be correct.

I suppose that next step should be - to make a deeper look on this issue with javadoc tool from JDK 7.

[Godin]

For the record - similar issue: http://stackoverflow.com/questions/13111512/javadoc-formatting-broken-since-upgrading-to-java-7

[marchof]

@Godin

So for now we use JDK < 7 for builds and we can close this issue?

[Godin]

@marchof If we are fine to stay on JDK 6 , then indeed - we can close this ticket. However in this case it would be better to update POMs and make it explicit that release can not and should not be done with JDK >= 7 to prevent any mistakes.

[marchof]

@Godin Maybe I'm mixing things here, but from my understanding the release should only be done against 1.5 to ensure compatibility with our minimum target requirement. The same applies for snapshot builds.

[Godin]

@marchof We can't deploy snapshots with JKD 5, because it is not available in CloudBees (I suppose because it reached EOL long time ago). Of course I can do releases with JDK 5 and this can be enforced in POMs ( and in this case in fact should be enforced, because it's so easy to forget to switch JDK ), but what the point if we compile with source=5 and target=5 ?

[marchof]

@Godin What we have to ensure for releases is:

1. JaCoCo is compiled against JRE 1.5 APIs
2. JaCoCo class files are version 1.5
3. JaCoCo tests are executed with JRE 1.5

The same would be nice for continuos and snapshot builds, to detect regressions early. But if our CI infrastructure does not provide 1.5 any more I can live with my local test runs.

What I do anyways on a regular base is to run JaCoCo tests with 1.5, 1.6 and 1.7. If this could be automated on cloudbeed this would be awesome.

[Godin]

@marchof Unfortunately Java 5 not available nor in CloudBees, nor in Travis CI. And since we deploy snapshots using CloudBees - they are compiled with JDK 6, but for Java 5, i.e. produced class files are for Java 5. And during releases we already do verification that we use only Java 1.5 APIs - see configuration for animal-sniffer-maven-plugin. But maybe such check should be always enabled and not only during releases, or at least for snapshots? Also I'll add verification to enforce releases with Java 5, because it's so easy to forget to do so. And I'll try to get in touch with CloudBees guys and ask for Java 5 for testing.

[marchof]

@Godin If there's not too much overhead with the animal-sniffer-maven-plugin we should run this with every build. So we know that the SNAPSHOT builds and all pull requests conform to Java 5.

[Godin]

And BTW indeed - we must do releases with Java 5 to avoid things like http://mail.openjdk.java.net/pipermail/nio-dev/2012-July/001788.html !

[marchof]

Enhancement request for Java 5: https://cloudbees.zendesk.com/entries/21970769-Support-for-Java-5

[marchof]

@Godin As we have Java 5 now on ClaudBees: Can we close this issue?

[Godin]

@marchof no, anyway we must update POMs to forbid releases without Java 5.