You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2001/12/18 10:07:31 UTC
Available Task and Classpath
Hi,
sorry, but I have to raise this issue again:
When you are building any target with ant which tests for optional
components,
you sooner or later face the problem where to search for the availability of
the components.
Usually the Available task is the thing to use. You can give this task a
classpath to search for and you can set the build.sysclasspath property to
either ignore the user classpath or not etc.
But, the Available task always finds the standard JDK classes (packages
java.
and javax.).
Now, looking at this behaviour, it seems alright - but unfortunately it can
cause problems:
For example, imagine an application which has optional LDAP components
requiring
the JNDI packages. You have your Available test in your build file and build
the application with JDK 1.3. As the Available task finds always the JNDI
package
from the JDK your optional LDAP component is included in the final build
application, but - of course - not the JNDI package.
And now the problem: you run your build application with JDK 1.2 which is
usually totally legal. But JDK 1.2 has not the JNDI package included...
Now, you can say, the build application must always run on a similar system
where it was build on, so it's not legal to run it on JDK 1.2. Hm, this is
not a good idea as for example a lot of the downloadable distributions (and
the nightly builds) from apache are build using JDK 1.3 - so everyone
downloading
a binary distribution needs JDK 1.3 (if such an optional component exists).
We have exactly this problem with Apache Cocoon!
So, I hope you can see from description, where my problems with the
Available
task are. I entered this months ago as a bug
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3989), but it was
rejected.
I think, the build.sysclasspath property is not correctly implemented for
the
Available task - or it has the wrong name as not the system classpath is
ignored
but the user classpath.
So, what do you think? Is this a self-made problem, or exists there another
solution?
Cheers
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: javac with different Java compilers.
Posted by Diane Holt <ho...@yahoo.com>.
--- detlef.brendle@canoo.com wrote:
> using the suggested fork parameter instead of 'true' doesnt do any good
> to me.
> if I specify a location where there is no javac such as
> fork="c:/develop/java/jdk1.3.1/imaginary/javac"
> it still uses 'some' other javac compiler instead.
> I need to find out where it gets the location from.
I don't think you'd need to fork and run a different 'javac' -- I think
all you need to do is what I suggested before, which is to get rid of all
the classpath that <javac> would ordinarily pass (except including your
"destdir") and supply your own classpath for the JDK version you need at
that point. For example, I run 'ant' with JDK1.3, but if I wanted to
compile against just the 1.1.8 classes, I'd use something like:
<target name="compile118">
<javac
includeJavaRuntime="no"
includeAntRuntime="no"
bootclasspath="${nowhere}"
srcdir="${basedir}"
destdir="${outdir}"
includes="Test.java">
<classpath>
<pathelement location="${jdk118}/classes.zip"/>
</classpath>
</javac>
</target>
Diane
=====
(holtdl@yahoo.com)
__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: javac with different Java compilers.
Posted by de...@canoo.com.
hi stefan ,
using the suggested fork parameter instead of 'true' doesnt do any good to me.
if I specify a location where there is no javac such as
fork="c:/develop/java/jdk1.3.1/imaginary/javac"
it still uses 'some' other javac compiler instead.
I need to find out where it gets the location from.
detlef,
btw: Im using ant 1.4.1 and the fork field still is boolean.
Quoting Stefan Bodewig <bo...@apache.org>:
> On Tue, 18 Dec 2001, detlef brendle <de...@canoo.com> wrote:
>
> > b. if I run it externally it still wont use the correct JAVA_HOME
> > environment.
>
> fork="your\path\to\javac" should work. The documentation needs an
> update, but if you use something different than
> on/off/yes/no/true/false,
> Ant will assume it is the full path to the compiler.
>
> Now you will want to set the include*runtime attributes to false and
> take complete control over your classpath.
>
> Stefan
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: javac with different Java compilers.
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 18 Dec 2001, detlef brendle <de...@canoo.com> wrote:
> b. if I run it externally it still wont use the correct JAVA_HOME
> environment.
fork="your\path\to\javac" should work. The documentation needs an
update, but if you use something different than on/off/yes/no/true/false,
Ant will assume it is the full path to the compiler.
Now you will want to set the include*runtime attributes to false and
take complete control over your classpath.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: javac with different Java compilers.
Posted by Diane Holt <ho...@yahoo.com>.
--- detlef.brendle@canoo.com wrote:
> no I dont think so as it only generates class files for major java
> versions. I need to use compilers with minor releases too / such as
> 1.2.2_01 or 1.3.0_02
You should be able to get rid of everything in <javac>'s default classpath
(except the dir pointed to by "destdir"), then just build up the classpath
you need for the releases you want to compile against.
P.S. This type of question should really go to ant-user instead of
ant-dev.
Diane
=====
(holtdl@yahoo.com)
__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: javac with different Java compilers.
Posted by de...@canoo.com.
no I dont think so as it only generates class files for major java versions.I
need to use compilers with minor releases too / such as 1.2.2_01 or 1.3.0_02
detlef
Quoting Erik Hatcher <ja...@ehatchersolutions.com>:
> Would <javac>'s 'target' attribute solve this problem?
>
>
> ----- Original Message -----
> From: <de...@canoo.com>
> To: "Ant Developers List" <an...@jakarta.apache.org>
> Sent: Tuesday, December 18, 2001 4:16 AM
> Subject: javac with different Java compilers.
>
>
> > hi all,
> >
> > I got a bit stuck during a proces automation and would appreciate your
> help.
> > heres the picture.
> >
> > I run ant todo all the java compile and many other things as well.
> > but the java compile is what worries me the most right now.
> >
> > I run <javac ..> with noFork (in the same VM than the ant process)
> > I do that mainly because of some classpath calculations.
> > I now need to compile various java code with a different JavaVM
> (1.2.2)
> > So I thought I will set JAVA_HOME to the right directory where my
> java1.2.2 is
> > installed and run the script again.
> > now the trouble starts -
> > a. since IM in the same VM I cant change my javac compiler during
> runtime.
> > b. if I run it externally it still wont use the correct JAVA_HOME
> environment.
> >
> >
> > the idea was now to use <exec..> somehow to compile with different
> javac
> > locations. but I also skipped this as I dont think thats the way to
> solve
> this.
> >
> > Has anybody got a solution for this problem ?
> >
> > regards,
> > detlef
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: javac with different Java compilers.
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Would <javac>'s 'target' attribute solve this problem?
----- Original Message -----
From: <de...@canoo.com>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Tuesday, December 18, 2001 4:16 AM
Subject: javac with different Java compilers.
> hi all,
>
> I got a bit stuck during a proces automation and would appreciate your
help.
> heres the picture.
>
> I run ant todo all the java compile and many other things as well.
> but the java compile is what worries me the most right now.
>
> I run <javac ..> with noFork (in the same VM than the ant process)
> I do that mainly because of some classpath calculations.
> I now need to compile various java code with a different JavaVM (1.2.2)
> So I thought I will set JAVA_HOME to the right directory where my
java1.2.2 is
> installed and run the script again.
> now the trouble starts -
> a. since IM in the same VM I cant change my javac compiler during runtime.
> b. if I run it externally it still wont use the correct JAVA_HOME
environment.
>
>
> the idea was now to use <exec..> somehow to compile with different javac
> locations. but I also skipped this as I dont think thats the way to solve
this.
>
> Has anybody got a solution for this problem ?
>
> regards,
> detlef
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
javac with different Java compilers.
Posted by de...@canoo.com.
hi all,
I got a bit stuck during a proces automation and would appreciate your help.
heres the picture.
I run ant todo all the java compile and many other things as well.
but the java compile is what worries me the most right now.
I run <javac ..> with noFork (in the same VM than the ant process)
I do that mainly because of some classpath calculations.
I now need to compile various java code with a different JavaVM (1.2.2)
So I thought I will set JAVA_HOME to the right directory where my java1.2.2 is
installed and run the script again.
now the trouble starts -
a. since IM in the same VM I cant change my javac compiler during runtime.
b. if I run it externally it still wont use the correct JAVA_HOME environment.
the idea was now to use <exec..> somehow to compile with different javac
locations. but I also skipped this as I dont think thats the way to solve this.
Has anybody got a solution for this problem ?
regards,
detlef
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Available Task and Classpath
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 19 Dec 2001, Carsten Ziegeler <cz...@s-und-n.de> wrote:
> The main problem still exists, that you would need the same
> environment to run the build application as the environment for
> building it.
There always seems to be a problem domain where this is true. If you
write a JDBC driver you'll need to build on JDK 1.1 to support JDBC
1.0 and 1.4 to support JDBC 3.0 (you have the choice of 1.2 or 1.3
when you want to support JDBC 2.1).
I'm not sure what Ant's distribution will look like when JDK 1.4 gets
its final release. We'll probably have to tell people how to replace
their buggy XML parser with the newer Crimson we provide.
> I think, this is a common problem. Aren't there others having this
> problem? How did you solve it?
I am involved in the development of a JDBC driver (only JDBC 1.0 and
2.1) and the only solution we've found is to compile in two passes,
one using JDK 1.1 and one using 1.3 - and fall back to reflection to
pick up the "correct" classes at runtime. But we still need to build
with a JDK 1.1 to support a JDK 1.1 at the users side.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Available Task and Classpath
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefan Bodewig wrote:
>
> On Tue, 18 Dec 2001, Carsten Ziegeler <cz...@s-und-n.de> wrote:
>
> > I think, the build.sysclasspath property is not correctly
> > implemented for the Available task - or it has the wrong name as not
> > the system classpath is ignored but the user classpath.
>
> Depends on what you call "system". It can be used to ignore the
> equivalent of the CLASSPATH environment variable, which is the
> system's CLASSPATH, isn't it? 8-)
>
Hmmm, ok.
> > So, what do you think? Is this a self-made problem, or exists there
> > another solution?
>
> It is part of a Sun made problem IMHO. If you include JNDI for JDK
> 1.2, you may run into problems when you try to use the distribution on
> a later JDK with a different version of these classes - all the JAXP
> incompatibility problems Ant could come in a different area but for
> the same reasons.
>
> I think the only solution is to tell people that they'll also need the
> JNDI classes when using JDK 1.2 or provide two different
> distributions.
>
I'm not satisfied with this. The main problem still exists, that you
would need the same environment to run the build application as the
environment for building it.
If the requirements for your application are JDK 1.2 and you have
optional components which are only build when you have JDK 1.3 and you
now build using JDK 1.3 this results in a build which is only runnable
with JDK 1.3 - you don't have any choice to build a version for JDK 1.2
using JDK 1.3.
I think, this is a common problem. Aren't there others having this
problem? How did you solve it?
Carsten
> Stefan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Available Task and Classpath
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 18 Dec 2001, Carsten Ziegeler <cz...@s-und-n.de> wrote:
> I think, the build.sysclasspath property is not correctly
> implemented for the Available task - or it has the wrong name as not
> the system classpath is ignored but the user classpath.
Depends on what you call "system". It can be used to ignore the
equivalent of the CLASSPATH environment variable, which is the
system's CLASSPATH, isn't it? 8-)
> So, what do you think? Is this a self-made problem, or exists there
> another solution?
It is part of a Sun made problem IMHO. If you include JNDI for JDK
1.2, you may run into problems when you try to use the distribution on
a later JDK with a different version of these classes - all the JAXP
incompatibility problems Ant could come in a different area but for
the same reasons.
I think the only solution is to tell people that they'll also need the
JNDI classes when using JDK 1.2 or provide two different
distributions.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>