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