ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: Problem with the classpath
Date Tue, 11 Aug 2009 23:05:18 GMT
I was definitely referring to removing the env variable. The issue you  
are encountering is that java tends to favor the env. variable. I  
would suggest telling all your developers to remove the variable as  
well as editing the ant script to clear out the variable prior to  
invoking ant. Something like

     export CLASSPATH=


     set CLASSPATH=

This will help with situations where developers still have the  
variable set.

Sent from my iPhone

On Aug 11, 2009, at 11:34 AM, espinha <> wrote:

> Hello Brian,
> The problem is exactly that: we don't want to use the environment  
> variable.
> In fact, we want it to be ignored by Ant, which is proving to be  
> difficult.
> What I'm trying to achieve is that Ant always picks up the jars  
> defined in
> the classpath **attribute** on the build.xml rather than picking up  
> the jars
> in the env. classpath.
> If, however, you were referring to not using the classpath attribute  
> on Ant,
> then I fail to see how can we possibly point a task to classes in a  
> specific
> set of jars. Our task has some code along the following lines:
> String bundleName = "org.apache.derby.loc.m" + index;
>        ResourceBundle bundle =
>            ResourceBundle.getBundle(bundleName, Locale.ENGLISH);
> So how could we possibly load the classes dynamically, based on their
> fully-qualified class name, without having some sort of classpath  
> attribute
> defined in Ant?
> Best Regards,
> Tiago Espinha
> Brian Pontarelli wrote:
>> I would definitely avoid the environment variable if possible. In 12
>> years of Java work, I've never used that variable. Try to be very
>> explicit about the classpath for each thing you are doing and very
>> very specific about versions of all the JARs on the classpath. Once
>> you have removed the environment variable, I would suggest always
>> using a <classpath> element to define classpaths and then using
>> reference IDs. I'd also suggest that you eventually switch to using
>> Savant or Ivy for managing you classpaths and all of the  
>> dependencies.
>> Savant's integration build system handles a lot of these types of
>> things nicely.
>> -bp
>> On Aug 6, 2009, at 4:27 PM, Tiago Espinha wrote:
>>> Hello everyone,
>>> We at Apache Derby are using Ant to manage our build process but I
>>> have just run into an annoying problem that is being hard to  
>>> overcome.
>>> Having tried pretty much everything we could think of, I decided to
>>> ask for help with the more knowledgeable crew.
>>> The symptoms are very simple: if we build our main target  
>>> **without**
>>> the classpath environment variable set, everything compiles just  
>>> fine
>>> and we find no issues at all. The problem occurs when we are  
>>> trying to
>>> compile a specific code tree and our classpath (again, the env.
>>> variable) is set to a different version's code tree. This raises a
>>> failure in an ant task that we believe to be classpath-related.
>>> The task in question runs the following code to dynamically load
>>> classes:
>>> --------------8<-----------------
>>> String bundleName = "org.apache.derby.loc.m" + index;
>>> ResourceBundle bundle = ResourceBundle.getBundle(bundleName,
>>> Locale.ENGLISH);
>>> --------------8<-----------------
>>> The problem ends up being that this task is seeing the environment
>>> classpath and we were hoping to avoid this, because otherwise it  
>>> will
>>> attempt to load classes that it shouldn't.
>>> Our target looks like the following:
>>> <target name="runmessagecheck">
>>>   <taskdef
>>>     name="runMessageBundleTest"
>>>     classname="org.apache.derbyBuild.MessageBundleTest"
>>>     classpath="/Users/tiago/Desktop/Derby/CodeTenFive/classes"
>>>   />
>>>   <runMessageBundleTest/>
>>> </target>
>>> I have manually changed the classpath to an absolute path to avoid
>>> running into any problems with variables, but clearly that classpath
>>> isn't reaching the task. To confirm this, I printed the
>>> 'java.class.path' property inside the task and alas: the classpath I
>>> get in there is the one contained in the environment variable and  
>>> not
>>> the one defined in the task definition.
>>> I have also tried the build.sysclasspath property (defining it to
>>> ignore). I tried defining it project-wide, as a property using -D  
>>> and
>>> even on, all with no luck.
>>> Finally, we also attempted to use
>>>    <classpath>
>>>        <path refid="compile.classpath"/>
>>>        <pathelement location="/Users/tiago/Desktop/Derby/ 
>>> CodeTenFive/
>>> classes"/>
>>>    </classpath>
>>> inside the above target, at the same level of the taskdef, but also
>>> with no luck.
>>> Do you have any idea at all of what we might be doing wrong, or  
>>> simply
>>> how to overcome this issue? Any suggestions are appreciated.
>>> Thank you.
>>> Tiago Espinha
>>> --- 
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> -- 
> View this message in context:
> Sent from the Ant - Users mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message