Thanks to Andrew, Craig, and David for your responses.
I agree with Andrew that writing custom doclets sounds like a lot of
tricky work.
I like Craig's suggestion that we ship two sets of public javadoc, a
JDBC3 javadoc for users who run on jdk1.3-1.5 and a JDBC4 javadoc for
users who run
Hi Rick,
On May 8, 2006, at 6:43 AM, Rick Hillegas wrote:
Thanks to Andrew, Craig, and David for your responses.
I agree with Andrew that writing custom doclets sounds like a lot
of tricky work.
I like Craig's suggestion that we ship two sets of public javadoc,
a JDBC3 javadoc for users
Thanks to everyone who responded to this thread. It doesn't seem that
anyone has a solution to this problem. Does anyone have a preference for
which lie we tell: (1b) or (2d)? Barring a preference here, the default
would be (1b), our current behavior.
Thanks,
-Rick
Rick Hillegas wrote:
On 5/5/06, Rick Hillegas [EMAIL PROTECTED] wrote:
Thanks to everyone who responded to this thread. It doesn't seem that
anyone has a solution to this problem. Does anyone have a preference for
which lie we tell: (1b) or (2d)? Barring a preference here, the default
would be (1b), our current
Hi Rick,I'm intentionally cross-posting to derby-user just because lies in javadoc are supposed to affect users, not only developers.How about:3. Build two sets of javadoc, one using jdk 1.4 and another using 1.6. Distribute both sets of javadoc. Require the user to choose which javadoc to use
+1, I like this better than having inaccurate javadocs.
Craig L Russell wrote:
Hi Rick,
I'm intentionally cross-posting to derby-user just because lies in
javadoc are supposed to affect users, not only developers.
How about:
3. Build two sets of javadoc, one using jdk 1.4 and another using
Hi Andrew,
Thanks to your excellent work on derby-1078, it appears that we use the
1.6 javac when compiling in a shell window whose JAVA_HOME points at a
1.6 installation. Thanks to your changes, the build targets tell the 1.6
compiler to regard pre-JDBC4 source as down-rev and to generate
This is great news (for how we build with JDK 1.6, not the javadoc :( ),
I didn't know if this was completed. Thanks, Andrew!
Should those of working with JDK 1.6 start using the JAVA_HOME technique
rather than the ant.properties technique? Has BUILDING.txt been changed?
Thanks,
David
Right now the javadoc generated for jdk1.6 is telling a shocking lie. I
can fix this but only by inducing javadoc to tell a different lie. I
would like advice on how to get javadoc to tell the truth, the whole
truth, and nothing but the truth. If that's not possible, I'd like to
know which lie
It seems to me the real problem is that the way we compile source and
the way we compile javadoc are inconsistent.
With that in mind, I have two thoughts, with no backing in understanding
how things really work...
1) Fix javadoc compilation to be in line with source compilation: build
it
Thanks, David. I think that your suggestion (1) is pretty much what I
intend by item (2) in my email. Under this solution I don't see how we
coax javadoc into reporting that EmbeddedDataSource has a 1.6 subclass,
EmbeddedDataSource40. Sigh.
Regards,
-Rick
David W. Van Couvering wrote:
It
Well, I don't know that the Mac fans on this list would be very interested in
having everything built with the 1.6 JDK.
Many of us have had a hard time convincing our IT departments to upgrade to
Tiger so that we can even use the 1.5 JDK. (May 4th - counting the days).
-- Original
On 4/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Well, I don't know that the Mac fans on this list would be very interested in
having everything built with the 1.6 JDK.
To clarify, the recent changes that went in with DERBY-1078 mean that
you can build with 1.4, 1.5, or 1.6, and the
In suggesting it being built with the 1.6 JDK, I should have been
explicit in my assumption that this would only be done *if* the
resulting bytecodes were compatible with a 1.4 VM (except of course for
those classes that are 1.6-specific, but which you would not encounter
running under a 1.4
14 matches
Mail list logo
