Cocoon2, War files, Xerces and beyond

[ru...@us.ibm.com]

Let me start with a provocative question: why does Cocoon 2, a product not
quite in alpha stage just yet, depend on experimental SAX APIs which are
not part of the standard and only present in xerces 1.0.3?

I agree that Cocoon 1, a stable mature product that people depend on,
should be rather conservative in what versions of dependent projects it is
certified to run against, but Cocoon 2 at this stage should be more forward
looking IMHO.

A few more reasons to look forward:

   Did you know that the next version of Tomcat will work with the next
   version of Xerces?  In other words, there exists the possibility of
   being able to run a complete system with only *one* XML parser?

   Did you know that Mike Pogue, Scott Boag, myself and others are working
   together to set things up so that compatibility between the various
   projects in general, and Xerces and Xalan is verified at a minimum on a
   daily basis?  In fact, I just checked and the current versions of Xerces
   and Xalan will compile cleanly from CVS and together.  Note: I can
   successfully include cocoon-1 in this, but I would much rather include
   cocoon 2...

   I'm pleased to see the evolution of Cocoon as a WAR file, and I see the
   discussion about what to add to the installation instructions in order
   to run with Tomcat.  I will gladly go one step further and commit the
   necessary changes to the startup.bat and sh files to the Tomcat CVS
   tree.  At a minimum, it could include the necessary changes commented
   out.  Better yet, if the commands are of the form:
     if exist %TOMCAT_HOME%\lib\foo.jar set CLASSPATH=...
   then this could be committed in an executable form.

By the way, in the bottom of my previous post concerning the dependency on
Xerces 1.0.3, I included a question: would anybody mind if I started
changing both the build process and the code (if necessary) for Cocoon so
that external packages such as rhino were optional?  If I don't hear any
objections, I may get started on this this weekend.

- Sam Ruby

Re: Cocoon2, War files, Xerces and beyond

[Stefano Mazzocchi <st...@apache.org>]

rubys@us.ibm.com wrote:
> 
> Let me start with a provocative question: why does Cocoon 2, a product not
> quite in alpha stage just yet, depend on experimental SAX APIs which are
> not part of the standard and only present in xerces 1.0.3?

Because Pier wrote that and he was not around to fix it.

Good enough as an answer? :)

No, seriously, you are right, we should move to final SAX 2.0 ASAP but
if Xalan doesn't support that we might miss one leg and walking could be
difficult.

> I agree that Cocoon 1, a stable mature product that people depend on,
> should be rather conservative in what versions of dependent projects it is
> certified to run against, but Cocoon 2 at this stage should be more forward
> looking IMHO.

As soon as we have an XSLT processor that works with that, I'm all +1 on
following the specs as close as possible.
 
> A few more reasons to look forward:
> 
>    Did you know that the next version of Tomcat will work with the next
>    version of Xerces?  In other words, there exists the possibility of
>    being able to run a complete system with only *one* XML parser?

No, didn't know that :)
 
>    Did you know that Mike Pogue, Scott Boag, myself and others are working
>    together to set things up so that compatibility between the various
>    projects in general, and Xerces and Xalan is verified at a minimum on a
>    daily basis?  In fact, I just checked and the current versions of Xerces
>    and Xalan will compile cleanly from CVS and together.  Note: I can
>    successfully include cocoon-1 in this, but I would much rather include
>    cocoon 2...

Yes, you told me: if Xalan-cvs compiles on Xerces-cvs we have no
problems then.
 
>    I'm pleased to see the evolution of Cocoon as a WAR file, and I see the
>    discussion about what to add to the installation instructions in order
>    to run with Tomcat.  I will gladly go one step further and commit the
>    necessary changes to the startup.bat and sh files to the Tomcat CVS
>    tree.  At a minimum, it could include the necessary changes commented
>    out.  Better yet, if the commands are of the form:
>      if exist %TOMCAT_HOME%\lib\foo.jar set CLASSPATH=...
>    then this could be committed in an executable form.

I would love this.
 
> By the way, in the bottom of my previous post concerning the dependency on
> Xerces 1.0.3, I included a question: would anybody mind if I started
> changing both the build process and the code (if necessary) for Cocoon so
> that external packages such as rhino were optional?  If I don't hear any
> objections, I may get started on this this weekend.

Not at all.

If you can do it without breaking anything, I can't see why we should
wait for it.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

Re: Cocoon2, War files, Xerces and beyond

[Mike Pogue <mp...@apache.org>]

Just one quick comment on your provocative question:

I'm assuming that the API's you're talking about are the SAX 2 API's?

I believe that SAX 2 has gone Final at this point.  So, although I wouldn't
call the implementation "bug-free" (it hasn't been long enough in existence
to shake out all the bugs yet), it's probably safe to no longer call the SAX 2 API 
"experimental".  

By the way, Sam, keep up the good work to get us closer together,
and reach the goal of total harmony!!  :-)

Mike

rubys@us.ibm.com wrote:
> 
> Let me start with a provocative question: why does Cocoon 2, a product not
> quite in alpha stage just yet, depend on experimental SAX APIs which are
> not part of the standard and only present in xerces 1.0.3?
> 
> I agree that Cocoon 1, a stable mature product that people depend on,
> should be rather conservative in what versions of dependent projects it is
> certified to run against, but Cocoon 2 at this stage should be more forward
> looking IMHO.
> 
> A few more reasons to look forward:
> 
>    Did you know that the next version of Tomcat will work with the next
>    version of Xerces?  In other words, there exists the possibility of
>    being able to run a complete system with only *one* XML parser?
> 
>    Did you know that Mike Pogue, Scott Boag, myself and others are working
>    together to set things up so that compatibility between the various
>    projects in general, and Xerces and Xalan is verified at a minimum on a
>    daily basis?  In fact, I just checked and the current versions of Xerces
>    and Xalan will compile cleanly from CVS and together.  Note: I can
>    successfully include cocoon-1 in this, but I would much rather include
>    cocoon 2...
> 
>    I'm pleased to see the evolution of Cocoon as a WAR file, and I see the
>    discussion about what to add to the installation instructions in order
>    to run with Tomcat.  I will gladly go one step further and commit the
>    necessary changes to the startup.bat and sh files to the Tomcat CVS
>    tree.  At a minimum, it could include the necessary changes commented
>    out.  Better yet, if the commands are of the form:
>      if exist %TOMCAT_HOME%\lib\foo.jar set CLASSPATH=...
>    then this could be committed in an executable form.
> 
> By the way, in the bottom of my previous post concerning the dependency on
> Xerces 1.0.3, I included a question: would anybody mind if I started
> changing both the build process and the code (if necessary) for Cocoon so
> that external packages such as rhino were optional?  If I don't hear any
> objections, I may get started on this this weekend.
> 
> - Sam Ruby