cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett McLaughlin" <>
Subject Re: FESI.jslib.* imports
Date Tue, 07 Dec 1999 00:25:32 GMT
> Brett McLaughlin wrote:
> >
> > In building Cocoon, it gripes about this package.  Where can I get the
> > for this? (FESI.jslib.*)
> > BTW, once I'm done, I'll add this information into the build.xml and
send in
> > a diff.  That way if you want to update the build file you can.
> I'm working to make a better build file, but I'm not sure _how_ to allow
> Cocoon to be built without throwing errors if the required packages are
> not in the classpath.
> Well, I do have a solution, but it requires reflection which is not the
> cleanest/fastest thing to do...

I think you give users two options.  The first is the typical build.  Take a
look at how we build Turbine/EJBoss (Jon wrote the one for Turbine, me for
EJBoss).  Both specifically set environment vars to the location of each
required jar.  This requires you to be a real idiot to miss getting all the
required jar files.  Then that long env. string is passed in to -cp of java
as the classpath.
However, that is more developer-centric.  Cocoon is an interesting problem
because it is not an "all-good-developer" place to work in.  Lots of content
authors and such are here.  So I might add in the reflection classes as a
"production" or some such option to give Ant.  This is useful for
distributing as part of a larger set of components; in those cases people
either want everything to work or it all to fail, not to work some, change
some files, work some more, etc.  You also can look at actually distributing
more jar files with Cocoon.  In both EJBoss and Turbine, we distribute
ant.jar, javac.jar, and projectx_tr2.jar, which everyone seems to really
like, despite the initial and infrequent pain to download through CVS.

Let me know your thoughts, I think Ant has a lot of promise, but needs work
(we seem to be in agreement on that).


View raw message