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 01:10:31 GMT
> >
> > <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
> > 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
> > required jar files.  Then that long env. string is passed in to -cp of
> > as the classpath.
> I'll take a look at them.
> > However, that is more developer-centric.
> Yep
> > Cocoon is an interesting problem
> > because it is not an "all-good-developer" place to work in.  Lots of
> > authors and such are here.  So I might add in the reflection classes as
> > "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.

Ah, I see.  This is not so good, because a minority gets a benefit while a
majority pays the price.

> >  This is useful for
> > distributing as part of a larger set of components; in those cases
> > either want everything to work or it all to fail, not to work some,
> > some files, work some more, etc.
> People should be able to modify stuff and recompile. That's the goal.

No, I mean if I assemble a complete application, say including Cocoon,
Tomcat, EJBoss, some JNDI classes, and my custom classes, but need to
distribute on different platforms, I may need to run Ant type tasks as part
of an overall install.  In this case, Ant breaking in the middle is not
acceptable.  However, particularly with the reflection having to be in
Cocoon, I am not so sure that it isn't safe to assume anyone who would do
this would need to be responsible to build an idiot-proof install suite.  So
strike that comment. ;-)

> > You also can look at actually distributing
> > more jar files with Cocoon.
> No, I'm done with that. People will manage their components by
> themselves.

;-)  We see eye to eye on lots of things.

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

Yes, but sometimes you get out of balance.  Requiring someone to get IBM
XML4J is reasonable; it is on a website.  Requiring someone to log into CVS
and get ant.jar and javac.jar... I don't know.  That is pushing it in my
mind.  Also, have you pulled down jakarta-* modules lately?  They are
freaking huge!

> > Let me know your thoughts, I think Ant has a lot of promise, but needs
> > (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>
> or
>  <if class="com.sun.xml.parser.Parser">
>   <javac src="${src}/org/apache/cocoon/parser/" .../>
>  </if>
> which is even better since it uses reflection directly and doesn't care
> about different jar naming.

I think this could actually be done with XML pre-processing.  It is not
unfeasible to think that an XML aware application could make some decisions
about files and then use this knowledge with the XML file to generate a new
XML file, and feed that into Ant.  Sort of like using a bean to lead a bean,
you know?  I might be interesting to see how thin a piece you could build to
do this pre-processing.  It would only have to read a file name, check for
the file's existence, and either print the contents of the if in the
resulting XML file, or skip it.  Hmmm...

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

Yup, what's the point of XML when it's not _extensible_ ?


View raw message