cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
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.*)
> >
> > http://home.worldcom.ch/jmlugrin/fesi/index.html
> >
> > > 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.  

Yep

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

> 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/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 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.
<stefano@apache.org>                             Friedrich Nietzsche


Mime
View raw message