You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <de...@db.apache.org> on 2006/04/12 19:26:20 UTC

[jira] Assigned: (DERBY-1079) Build javadoc under jdk 1.6

     [ http://issues.apache.org/jira/browse/DERBY-1079?page=all ]

Rick Hillegas reassigned DERBY-1079:
------------------------------------

    Assign To: Rick Hillegas

> 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

>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Re: [jira] Assigned: (DERBY-1079) Build javadoc under jdk 1.6

Posted by Rick Hillegas <Ri...@Sun.COM>.
Andrew McIntyre wrote:

>
>ships in the release.
>
>For the engine docs, I'd suggest a similar setup. If you don't exclude
>the jdbc40 classes, I'm pretty sure that javadoc will still find them
>in the source and complain if it can't find the corresponding compiled
>classfile.
>  
>
Ah, I think you're right. Thanks.

Re: [jira] Assigned: (DERBY-1079) Build javadoc under jdk 1.6

Posted by Andrew McIntyre <mc...@gmail.com>.
On 4/12/06, Rick Hillegas <Ri...@sun.com> wrote:
>
> o Use the jdk16 javadoc if ant.properties points to a 1.6 installation

Yep, I think that's what I was suggesting. :-)

> o Don't exclude the jdbc40 classes from the javadoc at all. If
> ant.properties doesn't point at a 1.6 intallation, then they won't be
> built anyway.

Now we're talking about the engine docs, not the publishedapi javadoc
that ships in the release.

For the engine docs, I'd suggest a similar setup. If you don't exclude
the jdbc40 classes, I'm pretty sure that javadoc will still find them
in the source and complain if it can't find the corresponding compiled
classfile.

andrew

Re: [jira] Assigned: (DERBY-1079) Build javadoc under jdk 1.6

Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks, Andrew. I will play around with this. I may try something more 
elaborate too:

o Use the jdk16 javadoc if ant.properties points to a 1.6 installation
o Don't exclude the jdbc40 classes from the javadoc at all. If 
ant.properties doesn't point at a 1.6 intallation, then they won't be 
built anyway.

Cheers,
-Rick

Andrew McIntyre wrote:

>On 4/12/06, Rick Hillegas (JIRA) <de...@db.apache.org> wrote:
>  
>
>>     [ http://issues.apache.org/jira/browse/DERBY-1079?page=all ]
>>
>>Rick Hillegas reassigned DERBY-1079:
>>------------------------------------
>>
>>    Assign To: Rick Hillegas
>>    
>>
>
>Thought about this the other day. One way to go would be to add an
>executable attribute to the publishedapi's <javadoc> task, and
>parameterize the includesfile part. Then, create a new includesfile
>that contains the jdk16 classes, and then have a couple of new
>targets:
>
><target="publishedapi" depends="publishedapi.jdk14,publishedapi.jdk16"/>
>
><target="publishedapi.jdk14">
>  <antcall target="do.publishedapi" unless="jdk16">
>    <param name="publishedapi.executable" value="${java.home}/bin/javadoc"/>
>    <param name="publishedapi.includesfile"
>value="${javadoctools.dir}/publishedapi.ant"/>
>  </antcall>
></target>
>
><target="publishedapi.jdk16" if="jdk16">
>  <antcall target="do.publishedapi" unless="jdk16">
>    <param name="publishedapi.executable" value="${jdk16}/bin/javadoc"/>
>    <param name="publishedapi.includesfile"
>value="${javadoctools.dir}/publishedapi16.ant"/>
>  </antcall>
></target>
>
><target name="do.publishedapi">
>  ... old target, paramterized, goes here ...
></target>
>
>andrew
>  
>


Re: [jira] Assigned: (DERBY-1079) Build javadoc under jdk 1.6

Posted by Andrew McIntyre <mc...@gmail.com>.
On 4/12/06, Rick Hillegas (JIRA) <de...@db.apache.org> wrote:
>      [ http://issues.apache.org/jira/browse/DERBY-1079?page=all ]
>
> Rick Hillegas reassigned DERBY-1079:
> ------------------------------------
>
>     Assign To: Rick Hillegas

Thought about this the other day. One way to go would be to add an
executable attribute to the publishedapi's <javadoc> task, and
parameterize the includesfile part. Then, create a new includesfile
that contains the jdk16 classes, and then have a couple of new
targets:

<target="publishedapi" depends="publishedapi.jdk14,publishedapi.jdk16"/>

<target="publishedapi.jdk14">
  <antcall target="do.publishedapi" unless="jdk16">
    <param name="publishedapi.executable" value="${java.home}/bin/javadoc"/>
    <param name="publishedapi.includesfile"
value="${javadoctools.dir}/publishedapi.ant"/>
  </antcall>
</target>

<target="publishedapi.jdk16" if="jdk16">
  <antcall target="do.publishedapi" unless="jdk16">
    <param name="publishedapi.executable" value="${jdk16}/bin/javadoc"/>
    <param name="publishedapi.includesfile"
value="${javadoctools.dir}/publishedapi16.ant"/>
  </antcall>
</target>

<target name="do.publishedapi">
  ... old target, paramterized, goes here ...
</target>

andrew