Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 24188 invoked from network); 21 Mar 2002 11:49:08 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 21 Mar 2002 11:49:08 -0000 Received: (qmail 12453 invoked by uid 97); 21 Mar 2002 11:49:05 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 12417 invoked by uid 97); 21 Mar 2002 11:49:04 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 12399 invoked from network); 21 Mar 2002 11:49:04 -0000 Message-ID: <20020321114903.76696.qmail@web10803.mail.yahoo.com> Date: Thu, 21 Mar 2002 11:49:03 +0000 (GMT) From: =?iso-8859-1?q?Jose=20Alberto=20Fernandez?= Subject: Re: question about / To: Ant Developers List In-Reply-To: <3C99AF40.50503@cortexebusiness.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --- 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. > > adds files, not classes specifically, so > you can add resources in as > well. > It would be very nice if allowed a way to ask BCEL to use the .class files in there as roots for finding additional dependencies. (as an option) Maybe: ... > > > 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 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 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. > > 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 and say that it is ignored. My useful usage of would be for to check that given the jars in the stuff used from "srcdir" has all its dependencies covered. That would make a very powerful early error detection mechanism. > > > > > 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 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 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 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 '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? Couldn't you just filter any duplicates? If you are talking about something else I did not follow why that usage of 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 http://uk.my.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: