Jose Alberto Fernandez wrote:
--- Conor MacNeill <[EMAIL PROTECTED]><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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
