ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
Subject Re: <ejbjar> question about <weblogic>/<classpath>
Date Thu, 21 Mar 2002 13:43:46 GMT
Jose Alberto Fernandez wrote:

>  --- Conor MacNeill <conor@cortexebusiness.com.au>
>><support> adds files, not classes specifically, so
>>you can add resources in as
>>well.
> 
> It would be very nice if <support> allowed a way to
> ask BCEL to use the .class files in there as roots
> for finding additional dependencies. (as an option)
> Maybe:
> 
>   <support dependencies="full">
>    ...
>   <support>
> 


OK, I'll have a look at what is involved unless you want to submit a patch.


> 
> The way I see it, if the supper classes (and any other
> dependencies) are in 'srcdir' then you add them
> if instead they are in <classpath> then you do not.
> 
> The point is you put in 'srcdir' only those classes
> you are willing to put in the ejbjar. Then if you want
> to put other stuff in a separate jar that is up to
> you.
> 


It isn't that simple. When you are building multiple jars which share some 
common classes you may not want those common classes to appear in each jar. 
There may be associated loader issues.


 
> Ok I think I did not explain myself properly.
> By "resolve" I meant adding dependencies into the jar,
> just what we want BCEL to do, I was not talking about 
> resolving the class by the classloader.
> 
> What does BCEL when some dependency is not found
> in the "srcdir"? Does it need to be able to find
> those classes somewhere?


No. It just analyzes each class file in isolation.

> That is what I was thinking
> the classpath was all about. 


It used to be that in 1.4.1 but isn't needed anymore

> If BCEL does not need it
> then you should probably deprecate <classpath>
> and say that it is ignored.


I think I'll retain the current behaviour (used if no wlclasspath is specified) 
and also pass it in -classpath to ejbc.


> 
> My useful usage of <classpath> would be for
> <ejbjar> to check that given the jars in <classpath>
> the stuff used from "srcdir" has all its dependencies
> covered.
> That would make a very powerful early error detection
> mechanism.


OK, maybe it could be provided. I'll work on other issues first, though.


>>This is what already happens. The question is which
>>classes from here to put
>>into the jar. Some users want to add in everything.
>>Some are concerned about
>>duplicating classes in separate jars and only want
>>the bean classes in the jar.
>>This is the choice I am trying to support.
>>
>>
> 
> I say, the user can solve this by just putting in
> "srcdir" those classes that it is willing to put on
> the ejbjar. This is what I do today.
> 
> Maybe I am naive.


Some people build multiple jars out of a single compile tree and don't want 
additional files added. I think I can cater for both.


> As I said above, what would be nice is if BCEL or
> something else were able to check that any class
> it cannot find in "srcdir" is there in <classpath>
> so that we can be alerted of missing things.
> 


OK


> Yes, I rejected that in my buildfiles. 
> What I finish doing was running
> <ejbjar> for each ejbjar independently, so I can say
> exactly what is needed for each of them.


That gets a bit tedious when you have many beans.


> 
>>Anyway, I need to continue to support such usage
>>which is why <ejbjar>'s default
>>behaviour of only adding super classes and super
>>interfaces will be restored.
>>
>>
> 
> So, is it your problem that classes are being added
> twice?


No. Since it goes into a hashtable, only one would end up in the jar anyway. The 
issue is more about sharing classes across beans and associated loader issues.


> Couldn't you just filter any duplicates?
> If you are talking about something else I did not
> follow why that usage of <support> caused additional
> backward compatibility issues.
> 


I would like to retain same default behaviour as 1.4.1 and allow you to either 
ask for additional dependencies to be added or just a minimal set of classes.

Conor



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message