| Summary: | provide automated javadoc generation in doc plugin | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Nick Boldt <nboldt> |
| Component: | Dash Athena | Assignee: | Common Build Inbox <dash.commonbuilder-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | b.kolb, dash.commonbuilder-inbox, irbull, overholt, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 272037 | ||
| Bug Blocks: | 252401, 274170 | ||
Maybe we should investigate using the wikitext plugins from Mylyn for generating Eclipse Help (to wrap the javadoc?) in Athena? http://greensopinion.blogspot.com/2009/04/mylyn-wikitext-produces-pdf.html Looks like Andrew's got a solution here (bug 272037); we could look at how to roll this out in a more automated way, or at least document best practices. (In reply to comment #2) > Looks like Andrew's got a solution here (bug 272037); we could look at how to > roll this out in a more automated way, or at least document best practices. The thing I implemented was just to generate user-level documentation -- not javadoc. I am looking at this bug for Athena and Javadoc generation. A few things have me stumped. 1. In the custom build.xml, the doc plugin version is set to 3.2.0, but when Athena runs, the plugin has a proper 3.5 version number. Anybody know why this works? 2. What is the problem with windows? Are you saying that the <exec> calls in Ant don't work on Windows? (In reply to comment #4) > 1. In the custom build.xml, the doc plugin version is set to 3.2.0, but when > Athena runs, the plugin has a proper 3.5 version number. Anybody know why this > works? Is the build running with forceContextQualifier=true? > 2. What is the problem with windows? Are you saying that the <exec> calls in > Ant don't work on Windows? Your mileage with <exec> will vary across platforms. Staying in Ant (even using <java> is better than <exec>) improves cross-platform portability. (That said... I've been known to <exec> to use zip or unzip rather than <zip> because antzip != zip in all cases.) (In reply to comment #5) > (In reply to comment #4) > > 1. In the custom build.xml, the doc plugin version is set to 3.2.0, but when > > Athena runs, the plugin has a proper 3.5 version number. Anybody know why this > > works? > > Is the build running with forceContextQualifier=true? Nope, but after talking to Andrew N. this is how PDE Build works. There are still some hardcoded version numbers, but I can fix these -- if you actually look at our docs, it says 3.3 ;) > > > 2. What is the problem with windows? Are you saying that the <exec> calls in > > Ant don't work on Windows? > > Your mileage with <exec> will vary across platforms. Staying in Ant (even using > <java> is better than <exec>) improves cross-platform portability. > > (That said... I've been known to <exec> to use zip or unzip rather than <zip> > because antzip != zip in all cases.) > Yep, and I think I got the details sorted out for how to use the JavaDoc ant task. Nick, how do I get access to be able to run jobs on Hudson? Also, when run on Hudson, do the build artifacts get placed on the website automatically? (In reply to comment #6) > Nick, how do I get access to be able to run jobs on Hudson? You ask, usally by opening a bug in Community>Hudson. But because I saw this coming a mile away, I've already added irbull to the access list for the GEF 3.5 build. Log in and you can kick builds. https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-gef-3.5/ > Also, when run on Hudson, do the build artifacts get placed on the website > automatically? They're available in Hudson on build.eclipse.org, eg., here: https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-gef-3.5/lastSuccessfulBuild/artifact/**/*.zip To appear on www.eclipse.org/gef/downloads/, you have to publish them: http://wiki.eclipse.org/Common_Build_Infrastructure/Publishing For more, see: http://wiki.eclipse.org/Category:Athena_Common_Build (In reply to comment #7) > (In reply to comment #6) > > Nick, how do I get access to be able to run jobs on Hudson? > > You ask, usally by opening a bug in Community>Hudson. But because I saw this > coming a mile away, I've already added irbull to the access list for the GEF > 3.5 build. Log in and you can kick builds. Thanks, although the foundation is the only place that doesn't know me as irbull. I'm just ibull :-( (In reply to comment #8) > I'm just ibull :-( Fixed. WONTFIX; Athena is terminated. |
The current javadoc generation is a kludge and requires a custom build.xml for the doc plugin, which invariably breaks a build after the feature/plugin is incremented (because that same version is hardcoded in the build.xml). In addition, the process tends to fail due to various problems such as [build] [Fatal Error] :1:344: An invalid XML character (Unicode: 0x13) was found in the element content of the document. or [build] generateJavadoc: [build] [mkdir] Created dir: /tmp/build/N200903181724/eclipse/plugins/org.eclipse.draw2d.doc.isv/reference/api [build] [mkdir] Created dir: /tmp/build/N200903181724/eclipse/tmp/eclipse/plugins/org.eclipse.draw2d.doc.isv_3.4.1.200903181732 [build] [exec] Result: 1 [build] [copy] Copying 573 files to /tmp/build/N200903181724/eclipse/tmp/eclipse/plugins/org.eclipse.draw2d.doc.isv_3.4.1.200903181732 And, of course, it's ant calling shell, so it's doomed for use on Win/Mac.