ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject Re: <ejbjar> question about <weblogic>/<classpath>
Date Thu, 21 Mar 2002 11:49:03 GMT
 --- Conor MacNeill <>
wrote: > Jose Alberto Fernandez wrote:
> I don't think 1.1 support will inhibit 2.0 support.
> You asked for the situation
> and I gave you the history of how it comes to be
> that way. Besides, there are
> still many users in production using EJB 1.1 and
> they need to be supported.
Agreed. I was just saying I am not commenting on 1.1.

> <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)

  <support dependencies="full">

> <ejbjar> does not enforce Class-Path relationships.
> The issue is where to add
> the classes and files an EJB uses. Should they be in
> the EJB jar or in a
> separate support jar. In Ant 1.4 the super classes
> and <support> files get added
> to the jar. It may be more appropriate to add them
> to another jar. Many people
> would prefer that they are not added to the jar.

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

> In Ant 1.5, ejbjar does not use reflection and
> therefore does not need to
> "resolve" classes if that is what you mean by
> resolve. It analyzes the classes
> in the srcdir directory and does not need the
> classpath. This is why it seems
> unused.

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? That is what I was thinking
the classpath was all about. If BCEL does not need it
then you should probably deprecate <classpath>
and say that it is ignored.

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
That would make a very powerful early error detection

>  >
>  > I think you are over designing a bit. I would
> argue that you are already 90% 
> there
>  > and this options just complicate instead of help.
> Let me tell you how I see it
>  > since I am now using your stuff regularly.
>  >
>  > "srcdir": while constructing the jar only put
> classes found here.
> 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.

>  >
>  > ejbjar/classpath: used by BCEL for any classes
> not in "srcdir" but
>  > do not add classes from here.
> BCEL does not need the classpath. This was only
> needed for reflection based
> analysis which is being replaced.

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.

>  >
>  > ejbjar/support: try to put things in here on the
> jar (and use BCEL
>  > with the same rules as for classpath). Is this
> smart enough as to
>  > understand the difference between .class files
> and other resources
>  > one may want added in the jar?
> These are just files and are not analyzed for
> dependencies. BTW, In Ant 1.4,
> some people are using <support> to add the non-super
> class dependencies. It is
> not a great solution, when building multiple jars at
> once.

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.

> 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
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.

Ups, yahoo truncated the reply. Will continue later.

Jose Alberto

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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

View raw message