Giacomo Pati wrote: > > > On Mon, 17 Dec 2001, Morrison, John wrote: > > > > > > > > -----Original Message----- > > > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, 17 December 2001 11:13 am > > > To: Cocoon-Dev > > > Subject: Building and Classpath > > > > > > > > > There are many questions regarding the special ClassAvailable task > > > in our build system. So here is a short description of the purpose: > > > > > > The Ant Available Tasks looks up classes by a given classpath (for > > > example all jar files in the lib directory). If the class is not found > > > the standard jdk classes are searched, if they contain this class - in > > > addition you can also search in your own classpath. > > > > > > Now this class searching is used for compiling/adding optional > > > components to Cocoon. One example is LDAPTransformer which requires > > > the JNDI classes to compile. > > > > > > The problem with the Available task is that it searches for optional > > > components in places which might not be available when the Cocoon > > > webapp is deployed: For example, you build Cocoon with JDK 1.3 which > > > already includes the JNDI classes. This will result in a webapp > > > requiring the JNDI packages to run. If you now deploy this in a > > > environment running only JDK 1.2, your webapp will never run as > > > the required classes are missing. > > > > > > And here kicks the ClassAvailable task in. It checks only a given > > > classpath (in our case the jars in the lib directory), but neither > > > the user classpath nor the standard jdk classes. So, even if you > > > build Cocoon on JDK 1.3, you will not get the LDAPTransformer. > > > If you really want this, you have to add this optional component > > > to the lib directory (e.g. the downloadble JNDI addition). > > > > > > Putting something into the lib directory will result in a copy of > > > this jar file in the build/deployed webapp, so all required classes > > > are really available. > > > > > > So the ClassAvailable task helps in building runnable versions. > > > But, I think we should try to get rid of this Cocoon special task > > > and try to support the user classpath for building. So additional > > > components would also be recognized if they are not in the lib > > > directory, but in the user classpath. But this might then lead > > > to not runnable webapps. > > > > > > So how can we combine these two problems? > > > Solution A: We don't care about the problem and shift the > > > responsibility > > > to the user: The Ant Available task is used and the user > > > classpath > > > is searched, too. The environment running Cocoon > > > must be the > > > same > > > as the one in which it was build. > > > I think, we all agree, that we can skip this solution! > > > > > > Solution B: We leave it as it is. So, we have our own Ant > > > task (which is > > > not soo bad), but we also ignore user settings. > > > > > > Solution C: A combination. Standard behaviour is to search > > > only in the jars > > > of > > > the lib directory, but if the user insists, he > > > can use his own > > > classpath, but has then to take care that all classes are > > > available > > > when he deploys a Cocoon webapp. > > > So we would still use the ClassAvailable task, but add a > > > property > > > controlling the behaviour. > > > > Solution D: fix the ant Available task (which has been > rejected(?) by the > > ant team... > > What was rejected? The task itself or a fix? > I will reraise this issue on the ant list. Let's see if we can get some attention there.
Carsten > Giacomo > > > > > > Are there more (better) solutions? > > > > > > Carsten > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
