You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Tiago Espinha <ti...@espinhas.net> on 2009/08/07 00:27:04 UTC

Problem with the classpath

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 ant.properties, 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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Re: Problem with the classpath

Posted by Brian Pontarelli <br...@pontarelli.com>.
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=

Or

     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 <ti...@espinhas.net> 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 ant.properties, 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: user-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: user-help@ant.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>> For additional commands, e-mail: user-help@ant.apache.org
>>
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/Problem-with-the-classpath-tp24884299p24922237.html
> Sent from the Ant - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Re: Problem with the classpath

Posted by espinha <ti...@espinhas.net>.
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 ant.properties, 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: user-unsubscribe@ant.apache.org
>> For additional commands, e-mail: user-help@ant.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Problem-with-the-classpath-tp24884299p24922237.html
Sent from the Ant - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Re: Problem with the classpath

Posted by Brian Pontarelli <br...@pontarelli.com>.
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 ant.properties, 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: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org