You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@apache.org> on 2007/01/25 03:56:32 UTC

upgrade strategies for our packaged Cocoon

For a long time now we have not been able to upgrade
our packaged Cocoon.

This is an undesirable situation for the Forrest
community and we need to fix it. Forrest developers
need to be able to make changes to Cocoon and have
those abilities available in their Forrest, as was
always intended.

I have spent a huge amount of behind-the-scenes effort
on this and now need to tell you what i know. Perhaps
someone else can help to break this deadlock.

Way back, Nicola Ken added the "pass-through" sitemap
ability to Cocoon, which enabled us to do wonderful
stuff with Forrest: split up our core sitemaps, add
plugins with their own sitemaps, etc.

This ability went into trunk, i.e. 2.2 and not into the
2.1 branch. Also Forrest at the time was being a good
test of the Cocoon trunk. It was also great for community
building via Apache Gump which gave notifications when
something busted, so we could fix our code, fix Cocoon code,
fix Excalibur code, etc.

Using trunk was a good decision.

Then we came to a standstill, partly due to Cocoon trunk
enhancement which we needed to keep up with, partly due
to mavenisation, and partly due to Gump ceasing to build
Cocoon trunk due to lack of Maven2 support. 

svn log lib/core/cocoon-2.2.0-dev.jar shows that it has
been over 12 months:
r355366 ... Upgrade Cocoon to r351990 2005-12-08

I tried to persist for a long time to get Cocoon trunk
integrated again into Forrest. Around r453411 2006-10-06
i got a Maven build of Cocoon happening and had partial
success with using that in Forrest.

Now Cocoon has put jars into the Maven repository and
developed some documentation for 2.2 at cocoon.zones.a.o
it should be easier. We should be able to use Ivy or Maven
to grab what we need. I don't have time, so perhaps someone
else can try.

All this while i was also trying the alternative of
"upgrade" to Cocoon-2.1 branch. I wondered if perhaps
the "pass-through sitemap" ability had been ported from
the trunk.

Recently i finally had success with 2.1 Cocoon.
Not everything works, but there is enough to give hope.
Forrest's PDF plugin does work, which makes me think
that the sitemaps work properly. I have not yet tried the
Dispatcher plugins.

I will add my test changes regarding 2.1 to a Jira issue
so that someone else has a head-start.

-David

Re: upgrade strategies for our packaged Cocoon

Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> 
> I will add my test changes regarding 2.1 to a Jira issue
> so that someone else has a head-start.

See https://issues.apache.org/jira/browse/FOR-955

-David

Re: upgrade strategies for our packaged Cocoon

Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> 
> >I will add my test changes regarding 2.1 to a Jira issue
> >so that someone else has a head-start.
> 
> Thanks for doing this David. It is certainly something we need to 
> address ASAP. Unfortunately, I doubt I will be the one to address it 
> anytime soon. Although I will be tackling our dependency management 
> stuff which links with this.
> 
> What we need is for someone to create a build target for Cocoon using 
> the new Maven build process they use. We used to be able to do this with 
> the old Ant build system, but I have no idea how the Maven build has 
> changed things.

I don't understand this reply to the "2.1" part of my message.
Are you getting mixed up between Cocoon-2.1 (still
Ant-based build) and Cocoon-2.2 (Maven-based build)?

> Once we have a way of creating the Cocoon snapshot we need I can use 
> that snapshot in our dependency management system, whatever it turns out 
> to be.

Recent artefacts are available for Cocoon-2.2 as Carsten described.
So Ivy can grab them.

If we decide to go back to Cocoon-2.1, then i gather that we
will need to continue to deal with Cocoon as we do now:
a committer builds and adds the relevant core and block jars
to our SVN. See forrest/trunk/etc/cocoon_upgrade/

Unless i am missing it and Cocoon already has 2.1 jars
manually added to the maven repository.

I hope that we go the Cocoon-2.2 route.

-David

Re: upgrade strategies for our packaged Cocoon

Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:

> I will add my test changes regarding 2.1 to a Jira issue
> so that someone else has a head-start.

Thanks for doing this David. It is certainly something we need to 
address ASAP. Unfortunately, I doubt I will be the one to address it 
anytime soon. Although I will be tackling our dependency management 
stuff which links with this.

What we need is for someone to create a build target for Cocoon using 
the new Maven build process they use. We used to be able to do this with 
the old Ant build system, but I have no idea how the Maven build has 
changed things.

Once we have a way of creating the Cocoon snapshot we need I can use 
that snapshot in our dependency management system, whatever it turns out 
to be.

Ross

Re: upgrade strategies for our packaged Cocoon

Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2007-02-15 at 20:14 +0100, Thorsten Scherler wrote:
>> I opened up an Apache Labs for writing a small crawler that can serve as
>> CLI replacement. On my local hard drive I have a version that is half
>> finished, will check this into 
>> http://svn.apache.org/repos/asf/labs/droids/
>> pretty soon.
>>
>> All Apache committer have write access there so fell all free to enhance
>> the upcoming code. 
> 
> I have finished a first version of droids and checked it in. 

Cool bannanas. When I get the time I'll replace my really crude crawler 
in Forrest 2 with Droids.

> Please test and report feedback to labs@labs.apache.org. I will happily
> answer all mails there.

See you there (eventually ;-)

Ross

Re: upgrade strategies for our packaged Cocoon

Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2007-02-15 at 20:14 +0100, Thorsten Scherler wrote:
> I opened up an Apache Labs for writing a small crawler that can serve as
> CLI replacement. On my local hard drive I have a version that is half
> finished, will check this into 
> http://svn.apache.org/repos/asf/labs/droids/
> pretty soon.
> 
> All Apache committer have write access there so fell all free to enhance
> the upcoming code. 

I have finished a first version of droids and checked it in. 

Please see http://svn.apache.org/repos/asf/labs/droids/README.TXT to get
started.

Please test and report feedback to labs@labs.apache.org. I will happily
answer all mails there.

See
http://mail-archives.apache.org/mod_mbox/labs-labs/200702.mbox/browser
for background information.

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java & XML                consulting, training and solutions


Re: upgrade strategies for our packaged Cocoon

Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2007-01-26 at 09:29 +0100, Carsten Ziegeler wrote:
> Thorsten Scherler wrote:
> > 
> > Thanks for the summary.
> > 
> > http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g2/1258.html 
> > Are this the docs you refer to?
> > 
> Yes; some of the basic for Spring configuration are described in the
> subprojects section under the cocoon-spring-configurator.
> 

Yeah, I need to play around with Spring for a course I give about J2EE.
I may try to use cocoon as an example. 

> >> Please note that the current trunk does not have a CLI anymore!
> > 
> > Hmm, meaning we would break forrest with the update, since we heavily
> > depend on the cli. The whole "site" target depends on it. 
> > 

Meaning before we can think on updating to current cocoon trunk we need
a cli replacement.

> > Carsten, cocoon trunk is running now in Spring, right? I do not know
> > many about spring myself. Does Spring provide a cli? Does cocoon plan to
> > implement one?
> > 
> Yes, Cocoon trunk is running in Spring; we have a bridge for Avalon
> components which means that they are defined as Spring beans as well.
> 
> Spring does not provide a CLI and *currently* Cocoon does not plan to
> implement one. The main reason for this is that we are moving away from
> our own request/response abstraction and plan to use the servlet api
> directly instead.
> 
> I think this topic has been discusses a while ago. Forrest could either
> fire up a jetty and let Forrest/Cocoon run inside a local servlet
> container and use a wget like approach or the CLI needs to be
> reimplemented which shouldn't be too hard as you only have to mock the
> servlet api.
> 

I opened up an Apache Labs for writing a small crawler that can serve as
CLI replacement. On my local hard drive I have a version that is half
finished, will check this into 
http://svn.apache.org/repos/asf/labs/droids/
pretty soon.

All Apache committer have write access there so fell all free to enhance
the upcoming code. 

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java & XML                consulting, training and solutions


Re: upgrade strategies for our packaged Cocoon

Posted by Carsten Ziegeler <cz...@apache.org>.
Thorsten Scherler wrote:
> 
> Thanks for the summary.
> 
> http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g2/1258.html 
> Are this the docs you refer to?
> 
Yes; some of the basic for Spring configuration are described in the
subprojects section under the cocoon-spring-configurator.

>> Please note that the current trunk does not have a CLI anymore!
> 
> Hmm, meaning we would break forrest with the update, since we heavily
> depend on the cli. The whole "site" target depends on it. 
> 
> Carsten, cocoon trunk is running now in Spring, right? I do not know
> many about spring myself. Does Spring provide a cli? Does cocoon plan to
> implement one?
> 
Yes, Cocoon trunk is running in Spring; we have a bridge for Avalon
components which means that they are defined as Spring beans as well.

Spring does not provide a CLI and *currently* Cocoon does not plan to
implement one. The main reason for this is that we are moving away from
our own request/response abstraction and plan to use the servlet api
directly instead.

I think this topic has been discusses a while ago. Forrest could either
fire up a jetty and let Forrest/Cocoon run inside a local servlet
container and use a wget like approach or the CLI needs to be
reimplemented which shouldn't be too hard as you only have to mock the
servlet api.

Carsten
-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/

Re: upgrade strategies for our packaged Cocoon

Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2007-01-25 at 10:15 +0100, Carsten Ziegeler wrote:
> Upgrading to Cocoon trunk (2.2) should be much easier now.
> There are some blocks that might not work currently (but will need only
> minimal configuration changes to get them working).
> All you have to do is putting the jars from Cocoon into your
> application. You can use Maven or Ivy for this, but you can also just
> download all jars and put them in your repository if you want.
> And then you have to define your web.xml and the Spring
> applicationContext.xml as described (briefly) in our new docs.
> 

Thanks for the summary.

http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g2/1258.html 
Are this the docs you refer to?

> Please note that the current trunk does not have a CLI anymore!

Hmm, meaning we would break forrest with the update, since we heavily
depend on the cli. The whole "site" target depends on it. 

Carsten, cocoon trunk is running now in Spring, right? I do not know
many about spring myself. Does Spring provide a cli? Does cocoon plan to
implement one?

> HTH

Yes, many thanks.

salu2

> Carsten
> 
> David Crossley wrote:
> > For a long time now we have not been able to upgrade
> > our packaged Cocoon.
> > 
> > This is an undesirable situation for the Forrest
> > community and we need to fix it. Forrest developers
> > need to be able to make changes to Cocoon and have
> > those abilities available in their Forrest, as was
> > always intended.
> > 
> > I have spent a huge amount of behind-the-scenes effort
> > on this and now need to tell you what i know. Perhaps
> > someone else can help to break this deadlock.
> > 
> > Way back, Nicola Ken added the "pass-through" sitemap
> > ability to Cocoon, which enabled us to do wonderful
> > stuff with Forrest: split up our core sitemaps, add
> > plugins with their own sitemaps, etc.
> > 
> > This ability went into trunk, i.e. 2.2 and not into the
> > 2.1 branch. Also Forrest at the time was being a good
> > test of the Cocoon trunk. It was also great for community
> > building via Apache Gump which gave notifications when
> > something busted, so we could fix our code, fix Cocoon code,
> > fix Excalibur code, etc.
> > 
> > Using trunk was a good decision.
> > 
> > Then we came to a standstill, partly due to Cocoon trunk
> > enhancement which we needed to keep up with, partly due
> > to mavenisation, and partly due to Gump ceasing to build
> > Cocoon trunk due to lack of Maven2 support. 
> > 
> > svn log lib/core/cocoon-2.2.0-dev.jar shows that it has
> > been over 12 months:
> > r355366 ... Upgrade Cocoon to r351990 2005-12-08
> > 
> > I tried to persist for a long time to get Cocoon trunk
> > integrated again into Forrest. Around r453411 2006-10-06
> > i got a Maven build of Cocoon happening and had partial
> > success with using that in Forrest.
> > 
> > Now Cocoon has put jars into the Maven repository and
> > developed some documentation for 2.2 at cocoon.zones.a.o
> > it should be easier. We should be able to use Ivy or Maven
> > to grab what we need. I don't have time, so perhaps someone
> > else can try.
> > 
> > All this while i was also trying the alternative of
> > "upgrade" to Cocoon-2.1 branch. I wondered if perhaps
> > the "pass-through sitemap" ability had been ported from
> > the trunk.
> > 
> > Recently i finally had success with 2.1 Cocoon.
> > Not everything works, but there is enough to give hope.
> > Forrest's PDF plugin does work, which makes me think
> > that the sitemaps work properly. I have not yet tried the
> > Dispatcher plugins.
> > 
> > I will add my test changes regarding 2.1 to a Jira issue
> > so that someone else has a head-start.
> > 
> > -David
> > 
> 
> 
-- 
thorsten

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



Re: upgrade strategies for our packaged Cocoon

Posted by Carsten Ziegeler <cz...@apache.org>.
Upgrading to Cocoon trunk (2.2) should be much easier now.
There are some blocks that might not work currently (but will need only
minimal configuration changes to get them working).
All you have to do is putting the jars from Cocoon into your
application. You can use Maven or Ivy for this, but you can also just
download all jars and put them in your repository if you want.
And then you have to define your web.xml and the Spring
applicationContext.xml as described (briefly) in our new docs.

Please note that the current trunk does not have a CLI anymore!

HTH
Carsten

David Crossley wrote:
> For a long time now we have not been able to upgrade
> our packaged Cocoon.
> 
> This is an undesirable situation for the Forrest
> community and we need to fix it. Forrest developers
> need to be able to make changes to Cocoon and have
> those abilities available in their Forrest, as was
> always intended.
> 
> I have spent a huge amount of behind-the-scenes effort
> on this and now need to tell you what i know. Perhaps
> someone else can help to break this deadlock.
> 
> Way back, Nicola Ken added the "pass-through" sitemap
> ability to Cocoon, which enabled us to do wonderful
> stuff with Forrest: split up our core sitemaps, add
> plugins with their own sitemaps, etc.
> 
> This ability went into trunk, i.e. 2.2 and not into the
> 2.1 branch. Also Forrest at the time was being a good
> test of the Cocoon trunk. It was also great for community
> building via Apache Gump which gave notifications when
> something busted, so we could fix our code, fix Cocoon code,
> fix Excalibur code, etc.
> 
> Using trunk was a good decision.
> 
> Then we came to a standstill, partly due to Cocoon trunk
> enhancement which we needed to keep up with, partly due
> to mavenisation, and partly due to Gump ceasing to build
> Cocoon trunk due to lack of Maven2 support. 
> 
> svn log lib/core/cocoon-2.2.0-dev.jar shows that it has
> been over 12 months:
> r355366 ... Upgrade Cocoon to r351990 2005-12-08
> 
> I tried to persist for a long time to get Cocoon trunk
> integrated again into Forrest. Around r453411 2006-10-06
> i got a Maven build of Cocoon happening and had partial
> success with using that in Forrest.
> 
> Now Cocoon has put jars into the Maven repository and
> developed some documentation for 2.2 at cocoon.zones.a.o
> it should be easier. We should be able to use Ivy or Maven
> to grab what we need. I don't have time, so perhaps someone
> else can try.
> 
> All this while i was also trying the alternative of
> "upgrade" to Cocoon-2.1 branch. I wondered if perhaps
> the "pass-through sitemap" ability had been ported from
> the trunk.
> 
> Recently i finally had success with 2.1 Cocoon.
> Not everything works, but there is enough to give hope.
> Forrest's PDF plugin does work, which makes me think
> that the sitemaps work properly. I have not yet tried the
> Dispatcher plugins.
> 
> I will add my test changes regarding 2.1 to a Jira issue
> so that someone else has a head-start.
> 
> -David
> 


-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/