On Aug 16, 2005, at 6:55 PM, Mark Womack wrote:
I will see if I can play with this tonight. It would be nice if these
settings could be controlled from our build.properties file instead of
setting property values in the command line.
Placing it in build.properties should the same effect as specifying
on the command line. We provide build.properties.sample, but the
current one in the v1_2branch uses pretty archaic versions of JAF,
etc, so I doubt that it is consistent with the build environment that
you are actually using to produce the "official" build.
As a potential consumer of the "official" build, there are a lot of
things of the build "machine" that are invisible: the platform, the
compiler, the version of Ant , the JDK, the specific versions of JAF,
JMS, JAXP, JNDI, Javamail, Javadoc, etc. Whether the compiler was
selected by the release manager specifying it on a command line or by
the release manager editing a build.properties that I never get to
see is just one of them.
On Aug 16, 2005, at 7:00 PM, Jacob Kjome wrote:
Quoting Ceki Gülcü <[EMAIL PROTECTED]>:
As far as log4j 1.2.x is concerned, I believe that JDK 1.2
compatibility was real. I can attest that for all log4j versions
prior
to 1.2.9, the log4j core was verified to compile under JDK 1.2. The
same holds true for log4j 1.3beta.
I think "log4j core" is a key part of that statement. For example,
the perfectly legal code in
o.a.l.chainsaw.receivers.LoggingReceiver.java that the JDK 1.2
compiler fails to compile had not been changed since 2002/05/29 and
appears to have had the issue since its introduction in 2002/03/23.
So I think it is highly unlikely that a distribution of log4j has
been prepared using JDK 1.1 or JDK 1.2 since at least mid-2002.
On Aug 16, 2005, at 7:00 PM, Jacob Kjome wrote:
Quoting Ceki Gülcü <[EMAIL PROTECTED]>:
Then we should verify that and figure out what changed to make it
so annoyingly
difficult to build source later than 1.2.9.
I have not attempted to confirm whether the issue occurs in earlier
log4j releases. Mark's build environment was most likely created
independently from Ceki's and likely differ in significant ways (OS,
JDK version, versions of dependencies, etc).
BTW, what JDK have the releases
been made under? I'd hasten to bet not JDK1.2 (without taking the
time to
verify).
See previous statement. Though it would be nice to get a description
of the build environments for earlier releases from Ceki.
It's been relatively recently that we set target and source
attributes in the build.
That became necessary with the introduction of JDK 1.5 which changed
the default value for target (I think from 1.1 to 1.2).
Yes, the source may have been compatible with JDK1.2,
but have the official releases actually been compatible? Something
to test, I
guess.
There is astonishing little documentation of the issue. Doing a
search shows it popping up in other projects, but there was nothing
in the Sun Java bug database similar other than a 1999-era bug. My
supposition is that sometime between JDK 1.2 and 1.4, the Sun JDK
compilers started emitting what is likely valid 1.1 bytecode per the
spec but which fails to be properly handled by the JIT's in the
earlier JVMs. My guess, but unsubstantiated, is that JDK 1.3's javac
is probably okay.
The same issue affects Ant's distributions at least since Ant 1.5.4
and to a much greater degree. No hints in the Ant mailing lists came
up when I did a search, but I didn't try to drill into the Ant
mailing list or post a message there.
Ideally we'd get the build environment nailed and the frozen into a
VM image or a bootable CD, so the process would be reproducible and
controlled. However, due to the mass of components that would have
some limitation on license transfer or distribution, I don't think we
could ever get to the point of being able to pass the build VM around.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
