cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: FESI.jslib.* imports
Date Tue, 07 Dec 1999 00:59:08 GMT
Brett McLaughlin wrote:
> > Brett McLaughlin wrote:
> > >
> > > In building Cocoon, it gripes about this package.  Where can I get the
> dist
> > > 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...
> <0.02>
> 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.

I'll take a look at them.

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

No, you didn't get it: the reflection code must be inside Cocoon, not
Ant. Ant already uses reflection to avoid all the components to be
present at build time.

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

People should be able to modify stuff and recompile. That's the goal.

> You also can look at actually distributing
> more jar files with Cocoon. 

No, I'm done with that. People will manage their components by

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

I like good docs instead of fat distributions.

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

Ant rocks but it needs some enhancing (many todo items are mine). I
would like to be able to have a <javac> task that doesn't fail is simple
dependency linking is missing, but this unfortunately requires a new
compiler, not a simple Ant Task.

Or, something like this

 <if file="${jars}/project-x.jar">
  <javac src="${src}/org/apache/cocoon/parser/" .../>


 <if class="com.sun.xml.parser.Parser">
  <javac src="${src}/org/apache/cocoon/parser/" .../>

which is even better since it uses reflection directly and doesn't care
about different jar naming.

I think the current design limitation of having just single empty
elements is simple too restrictive.

What do you think? 

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message