cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Building and Classpath
Date Tue, 18 Dec 2001 08:06:47 GMT
Giacomo Pati wrote:
>
>
> 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?
>
I will reraise this issue on the ant list. Let's see if we can get some
attention there.

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


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


Mime
View raw message