Community
Participate
Working Groups
This is an off-shoot of bug 487044, where there are a few more details. But in short, if we start a job from Hudson, the "JavaDoc task" does not work correctly. It results in messages such as javadoc: warning - Error fetching URL: https://docs.oracle.com/javase/8/docs/api/ javadoc: warning - Error fetching URL: https://osgi.org/javadoc/r6/core/ javadoc: warning - Error fetching URL: https://osgi.org/javadoc/r5/enterprise/ javadoc: warning - Error reading file: ../org.eclipse.platform.doc.isv/reference/api/package-list 4 warnings This smells like it can not get through the proxy server. If true, we could "hard code" them, of course, but on Hudson they are "passed in" via the ANT_OPTS environmental property. Another options might be to "copy to the right place" the "net.prefs" file, that p2 needs. But, I suspect p2 is not involved in this case.
While we need to be careful of master, in case of a rebuild, I've added the following 3 lines (in 2 commits) to init method of buildDoc.xml in org.eclipse.jdt.doc.isv. That should tell us if "ANT_OPTS" with proper values is getting at least that far. If so, then we need to figure out how to propigate them "deeper" But, if not even getting that far, we will have to figure out why not. <property environment="env" /> <echo message="== DEBUG ANT_OPTS ==" /> <echoproperties />
For some reason <echoproperties /> did not echo properties like it usually does. So, for "debugging" I've added a more explicit <echo message="env.ANT_OPTS: ${env.ANT_OPTS}" /> BUT, while reading about JavaDoc and proxies I see that you can not add -D arguments to the JavaDoc command, but must add them with a -J option preceeding it, While this could be done programaticlaly, I have simply added a new variable to our "boot strap" scripts: export JAVA_DOC_PROXIES="-J-Dhttps.proxyHost=proxy.eclipse.org -J-Dhttps.proxyPort=9898 -J-Dhttps.nonProxyHosts=\"172.30.206.*\"" And another echo in the buildDoc.xml file, so see if it is getting "passed through" to it. <echo message="env.JAVA_DOC_PROXIES: ${env.JAVA_DOC_PROXIES}" /> If all that works, Then I think we just need to add ${env.JAVA_DOC_PROXIES} to the line that executes "javadocexecutable".
In a test build, it was "passed though". So, I modified just one of the buildDoc.xml files (so far) the one for org.eclipse.jdt.doc.isv So it now looks like this <exec dir="." executable="${javadocExecutable}" output="target/doc.bin.log" timeout="600000"> <arg line="@${basedir}/${optionsFile} -J-Xmx500M ${env.JAVA_DOC_PROXIES}" /> </exec> Where env.JAVA_DOC_PROXIES should evaluate to -J-Dhttps.proxyHost=proxy.eclipse.org -J-Dhttps.proxyPort=9898 -J-Dhttps.nonProxyHosts=\"172.30.206.*\"
Added Markus to CC. I still can not explain why "running the scripts from Hudson" has trouble with proxies, and "running them from a cron job" does not, but am hoping this will solve the issue of "running the scripts from Hudson". We'll see in tonight's N-build. = = = = = The other thing to check, is if running a "local build" when that variable has not been defined still works ok. In most cases I know of, if such a variable is not defined it works ok and especially think it will since we use <arg line If we ever changed to use several <arg value (which isn't a bad idea in general :) then we might have to be smarter about it. But, first step, we'll see how tonight's N-build goes.
It appears this solution worked for the build on Hudson. Tonight's N-build no longer had the same messages about "https" for jdt.isv. http://download.eclipse.org/eclipse/downloads/drops4/N20160609-2000/compilelogs/jdt.doc.isv.javadoc.txt But, it does say javadoc: warning - Error reading file: ../org.eclipse.platform.doc.isv/reference/api/package-list I am assuming that is because I put the fix only in jdt.doc.isv. So, I have now put it in both the "isv" bundles. = = = = I also learned from a local build, that having an undefined variable did not evaluate so in a local build, having ${env.JAVA_DOC_PROXIES} in exec's <arg line results in an error message of "Package not found: ${env.JAVA_DOC_PROXIES} [I forgot, this is Ant, not bash :) ] So, I not have put in, right before the call to javadocexecutable <property name="env.JAVA_DOC_PROXIES" value="" /> That has worked for me before (in other contexts) so assume it will work here. I am sure there are more elegant solutions than this one I have implemented, but this should "get us by" and allow having the "cronjobs" on Hudson, instead of "e4Build" id, which is a big advantage, since then many people could "start a new build" when needed, and not depend on timezone (or, me being on line all the time :)
(In reply to David Williams from comment #5) > I also learned from a local build, that having an undefined variable did not > evaluate so in a local build, having ${env.JAVA_DOC_PROXIES} in exec's <arg > line > results in an error message of > "Package not found: ${env.JAVA_DOC_PROXIES} The message was actually "Illegal package name: ...." > So, I not have put in, right before the call to javadocexecutable > <property name="env.JAVA_DOC_PROXIES" value="" /> I've verified this works in a local build. That is, there is no error message. I assume "docs" are still built normally.
/org.eclipse.pde.doc.user/buildDoc.xml will need the same update. Setting target to 4.7, since it's not possible to fix anything for 4.6.1 right now.
(In reply to Markus Keller from comment #7) > /org.eclipse.pde.doc.user/buildDoc.xml will need the same update. > Setting target to 4.7, since it's not possible to fix anything for 4.6.1 > right now. Yep. As demonstrated by this test build. :/ http://build.eclipse.org/eclipse/builds/4N/siteDir/eclipse/downloads/drops4/N20160610-0824/logs.php#javadoc
Moving back to "fixed" after making the change to /org.eclipse.pde.doc.user/buildDoc.xml. A test build now shows all the "Java Doc error files" are clean: http://build.eclipse.org/eclipse/builds/4N/siteDir/eclipse/downloads/drops4/N20160610-1001/logs.php#javadoc Assuming the associated "UA unit tests" are clean in tonight's build, perhaps sometime soon someone who knows exactly what the JavaDoc should look like could take a look at an N-build and confirm they all look ok.
As an aside, Markus, you've mentioned a few times about the "right way" to put changes from master into the Java 9 patch stream. Would that apply here, as well? Perhaps you could enhance our Git Workflow Wiki at https://wiki.eclipse.org/Platform-releng/Git_Workflows with what you know -- since I know my "first instinct" would be to use "cherry-pick" and I am not sure I understand the difference or significance. Or, maybe the Java 9 branch is special and is not a general case? Thanks for your help!
Javadocs look good in N20160610-1001. Verified by following the links to supertypes of org.eclipse.pde.launching.JUnitLaunchConfigurationDelegate, which takes us from pde via jdt to platform docs, and at the end to https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html (In reply to David Williams from comment #10) > As an aside, Markus, you've mentioned a few times about the "right way" to > put changes from master into the Java 9 patch stream. I've added that at the end of https://wiki.eclipse.org/Java9#Development The strategy is to periodically merge master into BETA_JAVA9 and avoid individual cherry-picks. The general strategy in the Eclipse Platform project is to avoid long-running feature branches. The Java 9 effort is a special situation, since the EF legal team doesn't want us to develop code that falls under Oracle's "EA Spec License" in the master branch. As long as BETA_JAVA9 is the only feature branch, I wouldn't add this to the general platform workflow documentation. > Would that apply here, as well? We currently don't have a BETA_JAVA9 branch of eclipse.platform.common. Once we create one, the above strategy will include these changes for free.
