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? 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]
