Hi Andrew,
I don't think I understand your proposal. Do you want 10.2 to contain
two bundles of documentation with a high level html page that switches
between the two:
1) A bundle of user guides and javadoc for JDBC3 and
2) A separate bundle of user guides and javadoc for JDBC4?
Right now, when I unpack the 10.1.2.0 distribution, I see the following
directories:
demo
docs
html
pdf
frameworks
javadoc
lib
Are you proposing to change this layout? Looking forward to more detail...
Thanks,
-Rick
Andrew McIntyre (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1079?page=comments#action_12378564 ]
Andrew McIntyre commented on DERBY-1079:
----------------------------------------
- <antcall target="public-jdbc4-api"/>
+ <antcall target="public-jdbc4-api" if="jdk16"/>
Please don't break the top-level publishedapi target for JVMs < 1.6.
Instead of a publishedapi_index.html how about we create a top-level index.html
for the bin distribution that also has pointers to the manuals? I can take care
of the doc section of the file if you like.
Build javadoc under jdk 1.6
----------------------------
Key: DERBY-1079
URL: http://issues.apache.org/jira/browse/DERBY-1079
Project: Derby
Type: Bug
Components: Build tools
Versions: 10.2.0.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas
Fix For: 10.2.0.0
Attachments: bug1079_clientPublicAPI.diff, bug1079_deprecated.diff,
bug1079_embeddedPublicAPI.diff, bug1079_rev1.diff, bug1079_split.diff
We would like to build the javadoc under 1.6 so that all of the classes
(including the JDBC 3 and JDBC 4 support) end up in the same directory tree.
This is particularly important for the published API which we expose to
end-users.
Right now you can do the following:
1) Build the whole codeline using the 1.4 compiler for most classes and the 1.6
compiler for the JDBC4 support.
2) Build javadoc in a 1.4 environment (with JAVA_HOME set to 1.4). This runs
step (1) if it has not already happened. This javadoc excludes the JDBC4
support because generics-laden JDBC4 signatures choke the 1.4 compiler.
3) Build the javadoc in a 1.6 environment (with JAVA_HOME set to 1.6). This will fail if
you have not run step (1); this is because you can't build Derby in a 1.6 environment
yet. This also generates a number of warnings because the 1.6 javadoc tool objects to
code generated by the JAVACC grammar tool; JAVACC turns out code with loop variables
distastefully named "enum". In addition, today, the 1.6 javadoc excludes the
JDBC4 support.
We would like to end up with the following situation:
a) If your ant.properties points at a 1.6 installation, then the javadoc
targets will use the 1.6 javadoc tool and will include Derby's JDBC4 support.
This will work regardless of whether you have already built the class tree. If
you have not already built the class tree, then we will compile it under
scenario (1) above.
b) If, however, your ant.properties does not point at a 1.6 installation, then
the javadocs target will continue to use the 1.4 javadoc tool to build only the
classes built today. The JDBC4 support will be excluded from this javadoc.
c) As part of releasing 10.2, we will build the javadoc under scenario (a).
d) Once 1.6 exits beta and becomes a production vm, the community can debate
when we want to fix DERBY-1078 and require 1.6 in the build environment.
