Is that what we want?
No, but since there is no public maven-friendly JDK 1.4 runtime jar
that I am aware of, and since I bet that Apache wouldn't want us to
commit it to the repository, I don't think there is any solution that
wouldn't require the developer to perform a manual installation of
JDK 1.4 in some pre-determined location. And I'm personally loathe to
add any environmental requirements that hinders new developers from
being able to build OpenJPA.
On Jun 13, 2007, at 10:50 PM, Craig L Russell wrote:
Hi Marc,
Ah, you are right. I looked at the projects and didn't see the
project.properties where the compile.source and target properties
are. They are also in the pom.xml though in the build plugins.
But why should this be a choice of developers? I'd think that
either we would want to enforce this restriction for the project or
not. If we leave it up to developers' choice then someone will
eventually have to come around and fix up the 1.5 dependencies. Is
that what we want?
Craig
On Jun 13, 2007, at 7:35 AM, Marc Prud'hommeaux wrote:
Craig-
We were already setting the "source" and "target" flags to "1.4"
for the 1.4 modules, but that only enforces language-level
restrictions (e.g., it would raise an error if you tried to use
generics or autoboxing), it doesn't check to make sure you didn't
use an API method that doesn't exist in 1.4. In order to validate
that, say, you didn't call String.contains() (which is new in
1.5), you need to use the bootclasspath argument to provide the
1.4 runtime jar so that that level of verification can take place.
On Jun 13, 2007, at 10:21 PM, Craig L Russell wrote:
There is a maven flag that you can put into maven's
project.properties that specifies the level of jdk to use for
that project.
maven.compile.source = 1.4
maven.compile.target = 1.4
This can be dropped into those projects that we want to compile
with 1.4. This will enforce the dependency at compile time.
Craig
On Jun 13, 2007, at 12:55 AM, Marc Prud'hommeaux wrote:
We recently had some problems where JDK 1.5-specific methods
(e.g., String.contains(String)) were slipping into JDK 1.4-
specific modules. This isn't a problem for stand-alone OpenJPA
(whose only implementation is JPA, which is JDK 1.5-dependent),
but other products built on OpenJPA may still support JDK 1.4.
To that end, I've added a 'java14.jar' property to the pom.xml
files that can be used to specify the location of the JDK 1.4
runtime jar, against which we will compile the JDK 1.4-specific
modules. Since the location of the JDK 1.4 runtime jar is
platform- and installation- dependent, we can't just rely on a
single location (nor is there any maven-friendly JDK 1.4 runtime
jar that I am aware of), the flag needs to be specified manually.
Note that the flag will be silently ignored when it is
unspecified, which I expect will be the common case for most
OpenJPA developers. You only need to use it if you are
interested in ensuring that any code you add to JDK 1.4 modules
won't break 1.4 compatibility.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/
products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
