ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From espinha <>
Subject Re: Problem with the classpath
Date Tue, 11 Aug 2009 17:34:15 GMT

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:

View raw message