cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morrison, John" <John.Morri...@uk.experian.com>
Subject RE: Building and Classpath
Date Mon, 17 Dec 2001 11:17:18 GMT


> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message