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 03:03:48 GMT
Brett McLaughlin wrote:

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

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

Ok, I see.
> > > 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.

:) don't get me wrong, I'm all for making life as easy as possible, but
this should not impact on the ability to move the project forward with
an increased rate.
> > > 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.  

well, javac.jar is already in your JDK. Ant will soon have it's own
project with mail list, distribution, etc...

> That is pushing it in my
> mind.  Also, have you pulled down jakarta-* modules lately?  They are
> freaking huge!

Right, then we split them.

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

No way.

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

So you would need yet another DTD to teah your pre-preocessor how to do
things. What do you gain?

> 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 don't like this.
> > 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_ ?

Right there :)

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

View raw message