Community
Participate
Working Groups
To generate Javadoc for org.eclipse.jdt.annotation 2.0.0 (BREE: JavaSE-1.8), we have to use the Java 8 version of the javadoc tool. Currently, compilelogs/jdt.doc.isv.javadoc.txt starts with: --- ../../../eclipse.jdt.core/org.eclipse.jdt.annotation/src/org/eclipse/jdt/annotation/Nullable.java:14: error: cannot find symbol import static java.lang.annotation.ElementType.TYPE_USE; ^ symbol: static TYPE_USE location: class --- ElementType.TYPE_USE is only defined since Java 8. The ${javadoc} is set like this in buildDoc.xml: <available file="${java.home}/../bin/javadoc.exe" property="javadoc" value="${java.home}/../bin/javadoc.exe"/> <available file="${java.home}/../bin/javadoc" property="javadoc" value="${java.home}/../bin/javadoc" /> => We can either run the whole build with Java 8, or just set ${javadoc} to the Java 8 version.
I'd prefer to leave build on Java 7, and tweak ${javadoc} to point to write one. I'm kind of conservative about putting "the first release" of something on the critical path :) ... Nothing against Java 8 ... but, don't want out builds to serve as "early tester" of Java. Let me know if I'm off base, but that's direction I'd prefer.
(In reply to David Williams from comment #1) > I'd prefer to leave build on Java 7, and tweak ${javadoc} to point to write > one. No problem for me. Can you set the property somewhere in the aggregator? I don't think /org.eclipse.jdt.doc.isv/buildDoc.xml nor the pom.xml should refer to a fixed location in our build environment. Or is there already a property available that points to a JDK 8?
I don't know of any generic, general way to get access to "toolchains" variables. Adding Thanh to CC in case he knows of a way. But, otherwise, I propose adding something like the following to parent pom. That is, I don't mind providing "java 8 home", but not sure parent should "be aware of" JavaDoc tasks, specifically. (Be sure to read my wordy comment, and see if it makes sense). = = = = = = <!-- This special java.home-8 property is defined for those, in some sub-module (or, child) that need to use a specific version of java for some specialized task, such as from an ant task which is not "toolchain aware". Many "maven tasks", though, are tool chain aware, which when possible, should be the primary way of specifying specific versions of Java required. See https://maven.apache.org/guides/mini/guide-using-toolchains.html Anyone who uses this variable, should be sure to check that the tool exists, since some users may not have it installed, or installed in a different location. Users who do have it installed, can always override this value by using -Djava.home-8=<java-8-home> on the mvn command line. --> <java.home-8>/shared/common/jdk1.8.0_x64-latest</java.home-8> = = = = = = = = Thanh, can you think of a better way that ant tasks can "know about" specific versions of Java used in tool chain? Markus, you might try one run, say a nightly, or local build, and put <echoproperties /> in your ant ask and then you could see all variables you had available ... but, I've not seen any examples where ...toolchains... was used.
(In reply to David Williams from comment #3) > I don't know of any generic, general way to get access to "toolchains" > variables. > > Adding Thanh to CC in case he knows of a way. > > But, otherwise, I propose adding something like the following to parent pom. > That is, I don't mind providing "java 8 home", but not sure parent should > "be aware of" JavaDoc tasks, specifically. (Be sure to read my wordy > comment, and see if it makes sense). > Unfortunately I don't know. I always thought toolchains.xml was a one-way Tycho lookup, maybe a question for tycho-user mailing list? The proposed way seems a bit hacky to me to be honest but I can't think of a better way to do it other than to just build with Java 8.
(In reply to Thanh Ha from comment #4) > (In reply to David Williams from comment #3) > The proposed way seems a bit hacky to me ... Yeah, it's worse than hacky. I codes "environment specific" data into the POM, which should never happen. So, let's not do that. I spent quite a while googling and reading about the "toolchain" plugin, and it apparently "makes data available to other maven plugins (meaning, "the Java code that implements the plugin)" ... but, not antrun, and nothing "direct" in maven properties that I could find. In some early forum discussions I saw that requested and saw a response that would never happen (but, wasn't specific as to why). I wrote a minimal pom, to see if <echoproperties/> would give any hints and it did not ... nothing about "tool chain". I suspect someday someone will figure out how to use the maven "javadoc" plugin (which, might take advantage of tool chains? ) but coincidentally it's not perfect, yet (bug 431264). So, in the meantime, unless someone can figure out a better way, I think for production builds, I could add a "system property" to when I invoke Maven, such as -Djavadocjdk=/shared/commone1.8-latest/bin/javadoc (or what ever) and I'm thinkng the ant script could still use that. ${javadocjdk} variable. If we go this route, your condition logic should first check ${ant.java.runtim} to see if already running 1.8, if not check the variable, and if it's not defined, to simply continue with and build what you can (i.e. not "fail" the build). Let me know if you learn more or what to try this -Djavadocjdk route for now.
I happened to see bug 431264 go by this morning which sounds like there's a new tycho-document-bundle-plugin [1] in Tycho. I wonder if we can use this along with toolchains.xml to call the correct javadoc tool. [1] http://www.eclipse.org/tycho/sitedocs-extras/tycho-document-bundle-plugin/javadoc-mojo.html
Bug 431264 doesn't sound like tycho-document-bundle-plugin is ready, and I don't have time to convert all our Javadoc generation (which works fine otherwise). David, could you please add a system property? -Djava.home-8=<java-8-home> would be the most general solution, but if you fear this will be abused by others, you can also set a more specific -Declipse.javadoc=<path-to-javadoc-executable>.
(In reply to Markus Keller from comment #7) > Bug 431264 doesn't sound like tycho-document-bundle-plugin is ready, and I > don't have time to convert all our Javadoc generation (which works fine > otherwise). > > David, could you please add a system property? > > -Djava.home-8=<java-8-home> would be the most general solution, but if you > fear this will be abused by others, you can also set a more specific > -Declipse.javadoc=<path-to-javadoc-executable>. I would like to make it as specific as possible. so will add -Declipse.javadoc=/shared/common/jdk1.8.0_x64-latest/bin/javadoc and, just to be clear, it is the tool you need ... not merely the "classpath" used for Java 8? Mostly just curious ... but, just as I'm cautious about "first release VMs" I'm cautious about "first release tools". But, I'll start work on adding the parameter. (I'd like to add it as a "variable", and save its setting, as we do many of our other variables production build settings. But will can do this afternoon.
Here's the commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=8ac42b5f386ae068a016a27772f136f957d40072 Along with fixing a typo: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=2f4e64be953e699730f3c92e4f23b6b229239e23
Thanks, let's see how far we get with this: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=961e5c5520320687120f12aff55472b441dd7d60 (In reply to David Williams from comment #8) > and, just to be clear, it is the tool you need ... not merely the > "classpath" used for Java 8? Currently, we could get away with just setting the -bootclasspath to the Java 8 rt.jar, but we would get a bunch of syserr messages like this: warning: C:\java\jdk8\jre\lib\rt.jar(java/lang/Enum.class): major version 52 is newer than 51, the highest major version supported by this compiler. It is recommended that the compiler be upgraded. org.eclipse.jdt.annotation 2.0.0 doesn't use Java 8 language features, but it refers to ElementType.TYPE_USE, which is @since 1.8. But as soon as the first implementation bundle moves to Java 8, we will also need the Java 8 Javadoc tool.
(In reply to Markus Keller from comment #10) > Thanks, let's see how far we get with this: > http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/ > ?id=961e5c5520320687120f12aff55472b441dd7d60 > Was I supposed to put an '8' on variable name? Currently have -Declipse.javadoc=/shared/common/jdk1.8.0_x64-latest/bin/javadoc Or, are you thinking of some other future use case?
(In reply to David Williams from comment #11) > Was I supposed to put an '8' on variable name? No. I wasn't sure if there's some black magic that transfers Maven properties into Ant properties, so I used a different name for the Ant property, added <echoproperties>, and added code to test for both properties. Result: Properties are not automatically passed to Ant. The fix didn't work because of a horrible Ant bug: Apparently, the <available> task does not follow the Ant rule that a property is not re-written after it has been initialized. There's a warning about this in [1]. The message is crap, since it's ambiguous: DEPRECATED - <available> used to override an existing property. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=76e4deb92af4b7e489166dba2ecbc56cb30f9247 [1] http://build.eclipse.org/eclipse/builds/4N/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/buildDoc_log.xml (log not copied to the downloads page!)
Marking as fixed; jdt.doc.isv now uses the Java SE 8 Javadoc tool. Filed bug 431591 for HTML problems revealed by the new Javadoc tool.
