forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: JX in forrest
Date Wed, 14 Sep 2005 01:02:19 GMT
On Wed, 2005-09-14 at 10:41 +1000, David Crossley wrote:
> Thorsten Scherler wrote:
> > Juan Jose Pablos wrote:
> > > I did not enable the template block.
> > > 
> > > do we need jx support for forrest?
> > 
> > I tried but I do not get it working. :(
> > Then I found that in build.xml:
> > 
> >   <target name="copy-core-libs" depends="init">
> >   <!-- ===============================================================
> >        Copy all the libraries that belong to cocoon core.
> >        FIXME:  use sync task so you can ensure that removed libs from
> > cocoon
> >                are removed within forrest
> >        ===============================================================
> > -->
> >     <copy todir="${forrest.home}/lib/core">
> >       <fileset dir="${cocoon.home}/lib/core" defaultexcludes="yes">
> >         <!-- FIXME: The jxpath upgrade cannot be done.
> >           See issues FOR-405 and FOR-303 and dev mail list.
> >           commons-jxpath-1.2 causes errors with "site:" links
> >         -->
> >         <exclude name="commons-jxpath-*.jar"/>
> >         <!-- servlet.jar goes under tools/jetty -->
> >         <exclude name="servlet-*.jar"/>
> >       </fileset>
> >     </copy>
> >   </target>
> > 
> > Has somebody some hints how I can fix it, because we really need jxpath
> > and jx in general if we are want to move views into core. Some things in
> > the re-factored version of views has to be based on jx too slim the
> > processing down.
> 
> So when you say "its not working", is that referring to
> this "site:" problem? 

I did not came to the point because the generator component declaration
throwed exceptions.

> I have never tried to "fix" it,
> just rolled back to the old version of jxpath. So somebody
> needs to do some serious investigation of either jxpath
> or Cocoon/Forrest use of it.
> 

I should do this as well, but it is not really a solution for the core,
or?

> Apart from that issue, every time we update a Cocoon block,
> we should be looking at Cocoon to see if there are any
> relevant configuration changes, e.g. cocoon.xconf and
> sitemaps etc.

One more good reason more for my RT. ;-)

Why do we have our own xconf that we need to keep in sync with the
cocoon one? 

Why not just patching the cocoon one and using the original cocoon
version of xconf, sitemaps, etc.?

That will be more efficient IMO.
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message