cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett McLaughlin" <bmcla...@algx.net>
Subject Re: FESI.jslib.* imports
Date Tue, 07 Dec 1999 17:39:34 GMT
>
> > > > 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...

Well, I sort of disagree on this, but I think it's minor.  Either (a) people
_today_ using Cocoon are smart enough to get it or (b) by the time it is an
issue, Ant is "standard" and easily obtainable.  So I can get over this...

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

That would be a solution.

>
> > >
> > > > 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/SunXMLParser.java" .../>
> > >  </if>
> > >
> > > or
> > >
> > >  <if class="com.sun.xml.parser.Parser">
> > >   <javac src="${src}/org/apache/cocoon/parser/SunXMLParser.java" .../>
> > >  </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.

Well, it can be done... it may not be the best though, see below...

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

Wait a sec... you were the one that wanted this behavior :-)  I am merely
proposing alternatives to modifying Ant code.  Maybe for no other reason
than to demonstrate that ANt is a better solution...

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

Right, because it shouldn't be XML handling this, it should be code.  XML
needs to stay dat-centric, which is why I suggested either requiring the
files, or providing them.  It seems that either Ant needs to grow
significantly, or we all pay a price of carrying heavy distros around.

>
> > > 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 :)

-Brett


Mime
View raw message