You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2005/09/10 01:04:39 UTC

JX in forrest

Hi all,

how can I activate JX again in forrest? 

TIA

salu2
-- 
thorsten

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


Re: JX in forrest

Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Sun, 2005-09-11 at 16:23 +0200, Thorsten Scherler wrote:
> 
>>On Sat, 2005-09-10 at 01:04 +0100, Ross Gardler wrote:
>>
>>>Thorsten Scherler wrote:
>>>
>>>>Hi all,
>>>>
>>>>how can I activate JX again in forrest? 
>>>
>>>The first thing to try is to just drop the template block into our lib 
>>>folder.
> 
> 
> Did that. I checked it as well in. For now I added it to the
> internal.view lib.
> 
> 
>> You should also enable the block in 
>>
>>>etc/cocoon-upgrade/local.block.properties (so it gets upgraded with Cocoon.
>>>
> 
> 
> Did that.
> 
> 
>>>If the above doesn't work you will need to upgrade cocoon using te 
>>>scripts in etc/cocoon-upgrade
>>>
> 
> 
> Hmm, cheche just did that, right? I guess I do not have to do it again,
> or?

Did he do it with the block enabled in local.block.properties? Some 
blocks have other config to do at build time.

> Anyway it is not working. :( I commented the jx stuff for now so more
> people can have a look. 
> 
> If you uncomment the generator part you get a component not found
> exception but in the template.jar you can find the class :(
> 
> I do not know why the lib is not picked up. Has somebody an idea what
> might be wrong?

[NOTE] These are quick guesses as I walk out the door, no time to look 
into it now

It may be that it can't configure the class rather than not find it. The 
Cocoon classloaders sometimes give misleading errors. Is there any more 
info in the logs?

It may also be something to do with the fact the lib is in the plugin, I 
don't see why, but I have never tried it that way around when enabling 
blocks before.

Ross

Re: JX in forrest

Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> Ross Gardler wrote:
> > David Crossley wrote:
> > 
> > > It really is time to work more on our
> > > forrest.zones.apache.org so that it can send
> > > email when something breaks.
> > 
> > +1 (hmmm. another +1 and I haven't even found the time to log into our
> > zone yet - sorry)
> 
> I figure it's about time I learn about this zone thing.  Do I need to
> do something special in order to log in?  My normal user/pw combo
> isn't working for it.

That is correct, committers need to ask for
an account. I will set up each one when they ask.
Doing yours today Tim.

-David

Re: JX in forrest

Posted by Tim Williams <wi...@gmail.com>.
On 9/15/05, Ross Gardler <rg...@apache.org> wrote:
> David Crossley wrote:
> > Thorsten Scherler wrote:
> >
> >>David Crossley wrote:
> >>
> >>>Thorsten Scherler wrote:
> >>>
> >>>>Nicola Ken Barozzi wrote:
> >>>>
> >>>>>Thorsten Scherler wrote:
> >>>>>...
> >>>>>
> >>>>>>Why do we have our own xconf that we need to keep in sync with the
> >>>>>>cocoon one?
> >>>>>
> >>>>>Because we tweak it as needed.
> >>>>
> >>>>That should be done via xpatch and not by hand. Tweaking makes
> >>>>maintainment hard.
> >>>
> >>>Cocoon is moving away from using xpatch. In fact lots of that
> >>>is already implemented in Cocoon trunk. We need to change
> >>>our way of handling xconf and sitemap snippets.
> >>
> >>Yeah they do not use xpath but include a dir with conf-snippets which is
> >>even better.
> 
> 
> Note I already added the ability for Forrest to do the same. All you
> need to is add your xconf to our xconf directoru and add a line to load
> it in cocoon.xconf.
> 
> 
> > It really is time to work more on our
> > forrest.zones.apache.org so that it can send
> > email when something breaks.
> 
> +1 (hmmm. another +1 and I haven't even found the time to log into our
> zone yet - sorry)
> 
> Ross

I figure it's about time I learn about this zone thing.  Do I need to
do something special in order to log in?  My normal user/pw combo
isn't working for it.
--tim

Re: JX in forrest

Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Thorsten Scherler wrote:
> 
>>David Crossley wrote:
>>
>>>Thorsten Scherler wrote:
>>>
>>>>Nicola Ken Barozzi wrote:
>>>>
>>>>>Thorsten Scherler wrote:
>>>>>...
>>>>>
>>>>>>Why do we have our own xconf that we need to keep in sync with the
>>>>>>cocoon one? 
>>>>>
>>>>>Because we tweak it as needed.
>>>>
>>>>That should be done via xpatch and not by hand. Tweaking makes
>>>>maintainment hard. 
>>>
>>>Cocoon is moving away from using xpatch. In fact lots of that
>>>is already implemented in Cocoon trunk. We need to change
>>>our way of handling xconf and sitemap snippets.
>>
>>Yeah they do not use xpath but include a dir with conf-snippets which is
>>even better.


Note I already added the ability for Forrest to do the same. All you 
need to is add your xconf to our xconf directoru and add a line to load 
it in cocoon.xconf.


> It really is time to work more on our 
> forrest.zones.apache.org so that it can send
> email when something breaks.

+1 (hmmm. another +1 and I haven't even found the time to log into our 
zone yet - sorry)

Ross

Re: JX in forrest

Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-09-16 at 01:45 +1000, David Crossley wrote:
> Thorsten Scherler wrote:

> > Yeah they do not use xpath but include a dir with conf-snippets which is
> > even better.
> 
> This would be a good time for us to review all
> of our cocoon configuration. Yes it will be easier now.
> 
> I wonder if that is why we suddenly had problems
> with 'forrest site' taking three times as long
> following the previous Cocoon upgrade. Maybe there 
> is some configuration change that we have missed.

Yeah and to find that is not easy because we have tweaked ours so a
simple compare between the new cocoon.xconf of cocoon and ours is not an
option.

> > > > BTW I finally got it working after a chat with Antonio. He brought me on
> > > > the right track. Thx Antonio.
> > > 
> > > It would be better to talk on the list. Antonio is subscribed.
> > > Then we might all be able to assist.
> > 
> > In general you are right, but not in this case.
> > 
> > I do not see the point in having *private* conversions with Antonio,
> > which is a friend, here on the list. We did *not* talked about this
> > issue, it was covered only in one sentence, it was a *private* chat. 
> 
> Not what i meant. If you think that you solved
> something that has plauged us for such a long time,
> then it would be good to hear the answer. Obviously
> it is not quite working, and perhaps other people
> can help.
> 
> Sorry that my comment came across badly.

Yeah, no worries, I am having a thick skin. ;-)

> > > Anyway, not so. Did you run 'build test' after making
> > > such a drastic change?
> > 
> > No sorry, I only tested the dynamic mode. Will be more careful in the
> > future.
> 
> Thanks. We decided a while ago to try to not
> bust the trunk and agreed to do 'build test'.
> 
> It really is time to work more on our 
> forrest.zones.apache.org so that it can send
> email when something breaks.

Yeah, that would be nice.

> > I removed the offending lib again. BTW you have write access as well,
> > right? 
> 
> That would make the fourth time that i have
> needed to roll back that commit.
> 
> Anyway i regret reacting. Sorry about that.

No worries. I am sorry not having done a build test.

salu2
-- 
thorsten

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


Re: JX in forrest

Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley wrote:
> > Thorsten Scherler wrote:
> > > Nicola Ken Barozzi wrote:
> > > > Thorsten Scherler wrote:
> > > > ...
> > > > > Why do we have our own xconf that we need to keep in sync with the
> > > > > cocoon one? 
> > > > 
> > > > Because we tweak it as needed.
> > > 
> > > That should be done via xpatch and not by hand. Tweaking makes
> > > maintainment hard. 
> > 
> > Cocoon is moving away from using xpatch. In fact lots of that
> > is already implemented in Cocoon trunk. We need to change
> > our way of handling xconf and sitemap snippets.
> 
> Yeah they do not use xpath but include a dir with conf-snippets which is
> even better.

This would be a good time for us to review all
of our cocoon configuration. Yes it will be easier now.

I wonder if that is why we suddenly had problems
with 'forrest site' taking three times as long
following the previous Cocoon upgrade. Maybe there 
is some configuration change that we have missed.

> > > > > Why not just patching the cocoon one and using the original cocoon
> > > > > version of xconf, sitemaps, etc.?
> > > > 
> > > > Because the Cocoon ones are an example/template for Cocoon, not to be
> > > > used in production.
> > > 
> > > The xconf as well?
> > 
> > Yes.
> 
> We are as well using this. We made our own xconf based on this example
> but still...
> 
> > > BTW I finally got it working after a chat with Antonio. He brought me on
> > > the right track. Thx Antonio.
> > 
> > It would be better to talk on the list. Antonio is subscribed.
> > Then we might all be able to assist.
> 
> In general you are right, but not in this case.
> 
> I do not see the point in having *private* conversions with Antonio,
> which is a friend, here on the list. We did *not* talked about this
> issue, it was covered only in one sentence, it was a *private* chat. 

Not what i meant. If you think that you solved
something that has plauged us for such a long time,
then it would be good to hear the answer. Obviously
it is not quite working, and perhaps other people
can help.

Sorry that my comment came across badly.

> > Anyway, not so. Did you run 'build test' after making
> > such a drastic change?
> 
> No sorry, I only tested the dynamic mode. Will be more careful in the
> future.

Thanks. We decided a while ago to try to not
bust the trunk and agreed to do 'build test'.

It really is time to work more on our 
forrest.zones.apache.org so that it can send
email when something breaks.

> I removed the offending lib again. BTW you have write access as well,
> right? 

That would make the fourth time that i have
needed to roll back that commit.

Anyway i regret reacting. Sorry about that.

-David

Re: JX in forrest

Posted by Juan Jose Pablos <ch...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2005-09-15 at 10:06 +1000, David Crossley wrote:
>>Anyway, not so. Did you run 'build test' after making
>>such a drastic change?
> 
> 
> No sorry, I only tested the dynamic mode. Will be more careful in the
> future.
> 
> I removed the offending lib again. BTW you have write access as well,
> right? 
> 

Hey come on guys, There is not big dealt!. I made the same mistake a 
while ago. It is very normal to break something without intention and 
reversed this change is so easy sith SVN :-)


Peace man! :-)




Re: JX in forrest

Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-09-15 at 10:06 +1000, David Crossley wrote:
> Thorsten Scherler wrote:
> > Nicola Ken Barozzi wrote:
> > > Thorsten Scherler wrote:
> > > ...
> > > > Why do we have our own xconf that we need to keep in sync with the
> > > > cocoon one? 
> > > 
> > > Because we tweak it as needed.
> > 
> > That should be done via xpatch and not by hand. Tweaking makes
> > maintainment hard. 
> 
> Cocoon is moving away from using xpatch. In fact lots of that
> is already implemented in Cocoon trunk. We need to change
> our way of handling xconf and sitemap snippets.

Yeah they do not use xpath but include a dir with conf-snippets which is
even better.

> 
> > > > Why not just patching the cocoon one and using the original cocoon
> > > > version of xconf, sitemaps, etc.?
> > > 
> > > Because the Cocoon ones are an example/template for Cocoon, not to be
> > > used in production.
> > 
> > The xconf as well?
> 
> Yes.

We are as well using this. We made our own xconf based on this example
but still...

> > BTW I finally got it working after a chat with Antonio. He brought me on
> > the right track. Thx Antonio.
> 
> It would be better to talk on the list. Antonio is subscribed.
> Then we might all be able to assist.

In general you are right, but not in this case.

I do not see the point in having *private* conversions with Antonio,
which is a friend, here on the list. We did *not* talked about this
issue, it was covered only in one sentence, it was a *private* chat. 

> Anyway, not so. Did you run 'build test' after making
> such a drastic change?

No sorry, I only tested the dynamic mode. Will be more careful in the
future.

I removed the offending lib again. BTW you have write access as well,
right? 

salu2
-- 
thorsten

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


Re: JX in forrest

Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> Nicola Ken Barozzi wrote:
> > Thorsten Scherler wrote:
> > ...
> > > Why do we have our own xconf that we need to keep in sync with the
> > > cocoon one? 
> > 
> > Because we tweak it as needed.
> 
> That should be done via xpatch and not by hand. Tweaking makes
> maintainment hard. 

Cocoon is moving away from using xpatch. In fact lots of that
is already implemented in Cocoon trunk. We need to change
our way of handling xconf and sitemap snippets.

> > > Why not just patching the cocoon one and using the original cocoon
> > > version of xconf, sitemaps, etc.?
> > 
> > Because the Cocoon ones are an example/template for Cocoon, not to be
> > used in production.
> 
> The xconf as well?

Yes.

> BTW I finally got it working after a chat with Antonio. He brought me on
> the right track. Thx Antonio.

It would be better to talk on the list. Antonio is subscribed.
Then we might all be able to assist.

Anyway, not so. Did you run 'build test' after making
such a drastic change?

-David

Re: JX in forrest

Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-09-14 at 09:00 +0200, Nicola Ken Barozzi wrote:
> Thorsten Scherler wrote:
> ...
> > Why do we have our own xconf that we need to keep in sync with the
> > cocoon one? 
> 
> Because we tweak it as needed.

That should be done via xpatch and not by hand. Tweaking makes
maintainment hard. 

> 
> > Why not just patching the cocoon one and using the original cocoon
> > version of xconf, sitemaps, etc.?
> 
> Because the Cocoon ones are an example/template for Cocoon, not to be
> used in production.

The xconf as well?

BTW I finally got it working after a chat with Antonio. He brought me on
the right track. Thx Antonio.

salu2
-- 
thorsten

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


Re: JX in forrest

Posted by Nicola Ken Barozzi <ni...@apache.org>.
Thorsten Scherler wrote:
...
> Why do we have our own xconf that we need to keep in sync with the
> cocoon one? 

Because we tweak it as needed.

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

Because the Cocoon ones are an example/template for Cocoon, not to be
used in production.

> That will be more efficient IMO.

Convenient for some developer perhaps, not efficient.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Re: JX in forrest

Posted by Thorsten Scherler <th...@apache.org>.
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)


Re: JX in forrest

Posted by David Crossley <cr...@apache.org>.
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 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.

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.

-David

Re: JX in forrest

Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2005-09-12 at 14:05 +0200, 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.

I am playing around with *.navigation.xml and use this as businessHelper
for the menu like:
<forrest:contract name="nav-main">
    <forrest:properties contract="nav-main">
      <forrest:property name="nav-main" nugget="get.navigation">
        <!--We need to use here jx-->
        <url>index.navigation.xml</url>
      </forrest:property>
    </forrest:properties>
</forrest:contract>

Now that:
<!--We need to use here jx-->
<url>index.navigation.xml</url>

Should be relativ to the request if you use it in a directory or source
type way. Like:
<url>${request}.navigation.xml</url>

That is only one example where jx comes in handy. All that I now said, I
can do by writing yass (yet another stylesheet). You are right I could
do so, but jx offers more than this and provide sometimes heaps cleaner
solution then xsl.

Any help really welcome. TIA

salu2
-- 
thorsten

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


Re: JX in forrest

Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2005-09-12 at 14:05 +0200, Juan Jose Pablos wrote:
> Thorsten Scherler wrote:
> > On Sun, 2005-09-11 at 16:23 +0200, Thorsten Scherler wrote:
> > 
> >>On Sat, 2005-09-10 at 01:04 +0100, Ross Gardler wrote:
> >> You should also enable the block in 
> >>
> >>>etc/cocoon-upgrade/local.block.properties (so it gets upgraded with Cocoon.
> >>>
> > 
> > 
> > Did that.
> > 
> > 
> >>>If the above doesn't work you will need to upgrade cocoon using te 
> >>>scripts in etc/cocoon-upgrade
> >>>
> > 
> > 
> > Hmm, cheche just did that, right? I guess I do not have to do it again,
> > or?
> > 
> 
> I did not enable the template block.
> 
> do we need jx support for forrest?

Yes, we need it for views. Let's say I would like to base views on
jxtemplates.

I am trying, but do not have fully understood the README.txt of the
updating cocoon. If you could enable it that would be awesome. I will
try tonight.

salu2
-- 
thorsten

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


Re: JX in forrest

Posted by Juan Jose Pablos <ch...@apache.org>.
Thorsten Scherler wrote:
> On Sun, 2005-09-11 at 16:23 +0200, Thorsten Scherler wrote:
> 
>>On Sat, 2005-09-10 at 01:04 +0100, Ross Gardler wrote:
>> You should also enable the block in 
>>
>>>etc/cocoon-upgrade/local.block.properties (so it gets upgraded with Cocoon.
>>>
> 
> 
> Did that.
> 
> 
>>>If the above doesn't work you will need to upgrade cocoon using te 
>>>scripts in etc/cocoon-upgrade
>>>
> 
> 
> Hmm, cheche just did that, right? I guess I do not have to do it again,
> or?
> 

I did not enable the template block.

do we need jx support for forrest?


Re: JX in forrest

Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2005-09-11 at 16:23 +0200, Thorsten Scherler wrote:
> On Sat, 2005-09-10 at 01:04 +0100, Ross Gardler wrote:
> > Thorsten Scherler wrote:
> > > Hi all,
> > > 
> > > how can I activate JX again in forrest? 
> > 
> > The first thing to try is to just drop the template block into our lib 
> > folder.

Did that. I checked it as well in. For now I added it to the
internal.view lib.

>  You should also enable the block in 
> > etc/cocoon-upgrade/local.block.properties (so it gets upgraded with Cocoon.
> > 

Did that.

> > If the above doesn't work you will need to upgrade cocoon using te 
> > scripts in etc/cocoon-upgrade
> > 

Hmm, cheche just did that, right? I guess I do not have to do it again,
or?

Anyway it is not working. :( I commented the jx stuff for now so more
people can have a look. 

If you uncomment the generator part you get a component not found
exception but in the template.jar you can find the class :(

I do not know why the lib is not picked up. Has somebody an idea what
might be wrong?

salu2
-- 
thorsten

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


Re: JX in forrest

Posted by Thorsten Scherler <th...@apache.org>.
On Sat, 2005-09-10 at 01:04 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > Hi all,
> > 
> > how can I activate JX again in forrest? 
> 
> The first thing to try is to just drop the template block into our lib 
> folder. You should also enable the block in 
> etc/cocoon-upgrade/local.block.properties (so it gets upgraded with Cocoon.
> 
> If the above doesn't work you will need to upgrade cocoon using te 
> scripts in etc/cocoon-upgrade
> 
> Ross

cheers Ross.
-- 
thorsten

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


Re: JX in forrest

Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> Hi all,
> 
> how can I activate JX again in forrest? 

The first thing to try is to just drop the template block into our lib 
folder. You should also enable the block in 
etc/cocoon-upgrade/local.block.properties (so it gets upgraded with Cocoon.

If the above doesn't work you will need to upgrade cocoon using te 
scripts in etc/cocoon-upgrade

Ross