Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <03c801c36bce$abb02a70$1600a8c0@hypernexinc.local>
From: "Roger I Martin PhD" <hypernexdev@hypernexinc.com>
To: <dev@cocoon.apache.org>
References: <LKENJPKDAIKAPKHEOCMMAEHKENAA.cziegeler@s-und-n.de>
Subject: Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore
 jtidy-04aug2000r7-dev.jar
Date: Tue, 26 Aug 2003 08:36:28 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Carsten,

Just a thought about something I've run into.  When a third party makes a
block or webapp that depends on the same lib but a different version, can
the jar indexing capability of jdk1.4 jar utility be employed to resolve the
issues?  It involves placing and maintaining a correct Class-Path: ... in
the jar's manifest and then running jar -i *.jar.
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/jar.html#i

Also does anyone know if the indexing really does or would affect the speed
of bringing up a wepapp and say Tomcat?

Roger
----- Original Message ----- 
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <dev@cocoon.apache.org>
Sent: Tuesday, August 26, 2003 8:10 AM
Subject: RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore
jtidy-04aug2000r7-dev.jar


> Vadim Gritsenko wrote:
> >
> > >>I noticed that jtidy has been moved out of html block and into
> > >>lib/optional. What will happen if I to remove jtidy from the
> > >>lib/optional? Will this break the build?
> > >>
> > >>
> > >Yepp, you can see it in the gump.xml dependency description.
> > >
> >
> > But that means that we are busting build even more instead of fixing it?
> >
> Vadim, this is a point a stressed several times in the last months, but
> noone was really interested. Yes, we have a problem with libs, e.g. we
> have the same lib (velocity) at different places!
>
> We are not "busting the build". Currently, if two blocks require the same
> lib, it has to be in lib/optional. When the blocks directory structure
> was built, someone moved the libs into the blocks directories making it
> impossible to use the same jar in several projects. Now, each time
> a second block needs the jar we have to move it :(
> As I pointed out several times, this can be solved with an updated build
> system where we have all jars in lib/optional. These jars are not copied
> automatically to WEB-INF/lib. They are only copied if a included block
> depends on them.
>
> Carsten