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.
Are there more (better) solutions?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
