cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject RE: Building and Classpath
Date Tue, 18 Dec 2001 06:11:55 GMT
On Mon, 17 Dec 2001, Morrison, John wrote:

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

What was rejected? The task itself or a fix?

Giacomo

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


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


Mime
View raw message