Discussion:
Daisy is down
Ross Gardler
2008-11-21 00:14:11 UTC
Permalink
Can someone please kick the Daisy server on the Zone.

Ross
Grzegorz Kossakowski
2008-11-21 00:24:16 UTC
Permalink
Post by Ross Gardler
Can someone please kick the Daisy server on the Zone.
Done.

A side-note: We badly need to upgrade Daisy to 2.x version and we badly need to take care of backups
of Daisy installation.

Another side-note: I observe that we have a number of "badly needed to-be-done" tasks but there is a
constantly decreasing number of people willing to take care of them. This leads me personally to a
question about the future of this community.
--
(worried)
Grzegorz Kossakowski
Jasha Joachimsthal
2008-11-21 08:28:08 UTC
Permalink
Grzegorz,

is there an overview of "badly needed-to-be-done" tasks (Jira?)? Maybe others can take over some of them (if they are documented or otherwise with the help of someone with the knowledge).

Jasha

________________________________

Van: Grzegorz Kossakowski [mailto:***@tuffmail.com]
Verzonden: vr 21-11-2008 01:24
Aan: ***@cocoon.apache.org
Onderwerp: Re: Daisy is down
Post by Ross Gardler
Can someone please kick the Daisy server on the Zone.
Done.

A side-note: We badly need to upgrade Daisy to 2.x version and we badly need to take care of backups
of Daisy installation.

Another side-note: I observe that we have a number of "badly needed to-be-done" tasks but there is a
constantly decreasing number of people willing to take care of them. This leads me personally to a
question about the future of this community.

--
(worried)
Grzegorz Kossakowski
David Crossley
2008-11-25 00:05:06 UTC
Permalink
Post by Jasha Joachimsthal
Grzegorz,
is there an overview of "badly needed-to-be-done" tasks (Jira?)? Maybe others can take over some of them (if they are documented or otherwise with the help of someone with the knowledge).
Grek listed two "badlies" below. Another is to ensure that the
zone configuration is all safe in our SVN.

See some details at
https://svn.apache.org/repos/private/pmc/cocoon/cocoon.zones.apache.org/

Also a simple search of our mailing list shows various info about
the Daisy backup issue. Here are some only:
http://cocoon.zones.apache.org/daisy/documentation/1346.html
http://markmail.org/message/jojhpmlqwoqlz4l6
https://issues.apache.org/jira/browse/COCOON-1925

We also need to ensure that all contributors have a CLA on file
at ASF. I started to do that but got busy and put it on hold.

More below ...
Post by Jasha Joachimsthal
Post by Ross Gardler
Can someone please kick the Daisy server on the Zone.
Done.
A side-note: We badly need to upgrade Daisy to 2.x version and we badly need to take care of backups
of Daisy installation.
Another side-note: I observe that we have a number of "badly needed to-be-done" tasks but there is a
constantly decreasing number of people willing to take care of them. This leads me personally to a
question about the future of this community.
--
(worried)
Grzegorz Kossakowski
One thing that we need to do, is to continually refresh
the base of committers/PMC members. Please each committer
look around to see new people who should be committers.
Propose them on the private@ mail list, because we don't talk
about people in public.

-David
Grzegorz Kossakowski
2008-11-25 11:40:13 UTC
Permalink
Post by Jasha Joachimsthal
Grzegorz,
is there an overview of "badly needed-to-be-done" tasks (Jira?)? Maybe others can take over
some of them (if they are documented or otherwise with the help of someone with the knowledge).
Grek listed two "badlies" below. Another is to ensure that the zone configuration is all safe in
our SVN.
See some details at https://svn.apache.org/repos/private/pmc/cocoon/cocoon.zones.apache.org/
Also a simple search of our mailing list shows various info about the Daisy backup issue. Here
are some only: http://cocoon.zones.apache.org/daisy/documentation/1346.html
http://markmail.org/message/jojhpmlqwoqlz4l6 https://issues.apache.org/jira/browse/COCOON-1925
We also need to ensure that all contributors have a CLA on file at ASF. I started to do that but
got busy and put it on hold.
More below ...
Yep, generally speaking our zone really requires some love.
Post by Jasha Joachimsthal
Post by Ross Gardler
Can someone please kick the Daisy server on the Zone.
Done.
A side-note: We badly need to upgrade Daisy to 2.x version and we badly need to take care of
backups of Daisy installation.
Another side-note: I observe that we have a number of "badly needed to-be-done" tasks but there
is a constantly decreasing number of people willing to take care of them. This leads me
personally to a question about the future of this community.
-- (worried) Grzegorz Kossakowski
One thing that we need to do, is to continually refresh the base of committers/PMC members.
Please each committer look around to see new people who should be committers. Propose them on the
Maybe it's only me who sees it and continuously complain about it but I don't think that the root
cause is in lack of active committers/PMC members. I think this is just a result of the fact that we
seem to lost any vision on how to run and develop this project.

Cocoon 3.0 started by Reinhard looked promising to me but now I realize that the main idea of its
existence is to more or less rewrite C2.2 and add some RESTful features.

It's not my intention to criticize anyone but I really think it's not enough to make others excited
and willing to contribute. At least it looks that way...

Has anyone here thoughts on this topic or it's only me who has a problem?
--
Best regards,
Grzegorz Kossakowski
Reinhard Pötz
2008-11-25 14:24:37 UTC
Permalink
Post by Grzegorz Kossakowski
Cocoon 3.0 started by Reinhard looked promising to me but now I
realize that the main idea of its existence is to more or less
rewrite C2.2 and add some RESTful features.
Yes, that's explained by the first paragraph of the Cocoon 3 website.
Post by Grzegorz Kossakowski
It's not my intention to criticize anyone but I really think it's not
enough to make others excited and willing to contribute. At least it
looks that way...
You probably have missed it but with Simone we actually have one very
active committer and I know that many other people are fond of the
Cocoon 3 pipeline module.
Currently the main problem is that most developers don't know that there
is such a simple thing as the Cocoon 3 pipeline library. I've already
started to provide documentation but haven't got very far yet. But be
assured that it has a very high priority on my opensource todo list.
Post by Grzegorz Kossakowski
Has anyone here thoughts on this topic or it's only me who has a problem?
When I started Cocoon 3 my main goal was to solve two problems: 1)
provide a plain and simple pipeline API that is easily usable from
within any Java environment 2) make Cocoon a simple platform for RESTful
services.
This made *me* excited about it and solves *my* problems. I haven't done
any market research about what would have excited others.

Anyway, I don't think that it makes much sense to talk about what an
anonymous mass of people might want. So Grzegorz and all others reading
this, what would make *you* excited about Cocoon 3 so that *you* would
be willing to contribute?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member ***@apache.org
________________________________________________________________________
Peter Hunsberger
2008-11-25 16:10:12 UTC
Permalink
Post by Reinhard Pötz
Post by Grzegorz Kossakowski
Cocoon 3.0 started by Reinhard looked promising to me but now I
realize that the main idea of its existence is to more or less
rewrite C2.2 and add some RESTful features.
Yes, that's explained by the first paragraph of the Cocoon 3 website.
Post by Grzegorz Kossakowski
It's not my intention to criticize anyone but I really think it's not
enough to make others excited and willing to contribute. At least it
looks that way...
You probably have missed it but with Simone we actually have one very
active committer and I know that many other people are fond of the
Cocoon 3 pipeline module.
Currently the main problem is that most developers don't know that there
is such a simple thing as the Cocoon 3 pipeline library. I've already
started to provide documentation but haven't got very far yet. But be
assured that it has a very high priority on my opensource todo list.
Post by Grzegorz Kossakowski
Has anyone here thoughts on this topic or it's only me who has a problem?
When I started Cocoon 3 my main goal was to solve two problems: 1)
provide a plain and simple pipeline API that is easily usable from
within any Java environment 2) make Cocoon a simple platform for RESTful
services.
This made *me* excited about it and solves *my* problems. I haven't done
any market research about what would have excited others.
Anyway, I don't think that it makes much sense to talk about what an
anonymous mass of people might want. So Grzegorz and all others reading
this, what would make *you* excited about Cocoon 3 so that *you* would
be willing to contribute?
FWIW, we'll be taking a hard look at moving to Cocoon 3 vs. 2.2 as we
look at migrating off of 2.1. Our main requirement really is for XML
and XSL pipelines and we don't use most of the existing Cocoon
infrastructure, the big thing currently lacking is 3 that we really
need is caching...
--
Peter Hunsberger
Reinhard Pötz
2008-11-25 16:17:33 UTC
Permalink
Post by Peter Hunsberger
Post by Reinhard Pötz
Post by Grzegorz Kossakowski
Cocoon 3.0 started by Reinhard looked promising to me but now I
realize that the main idea of its existence is to more or less
rewrite C2.2 and add some RESTful features.
Yes, that's explained by the first paragraph of the Cocoon 3 website.
Post by Grzegorz Kossakowski
It's not my intention to criticize anyone but I really think it's not
enough to make others excited and willing to contribute. At least it
looks that way...
You probably have missed it but with Simone we actually have one very
active committer and I know that many other people are fond of the
Cocoon 3 pipeline module.
Currently the main problem is that most developers don't know that there
is such a simple thing as the Cocoon 3 pipeline library. I've already
started to provide documentation but haven't got very far yet. But be
assured that it has a very high priority on my opensource todo list.
Post by Grzegorz Kossakowski
Has anyone here thoughts on this topic or it's only me who has a problem?
When I started Cocoon 3 my main goal was to solve two problems: 1)
provide a plain and simple pipeline API that is easily usable from
within any Java environment 2) make Cocoon a simple platform for RESTful
services.
This made *me* excited about it and solves *my* problems. I haven't done
any market research about what would have excited others.
Anyway, I don't think that it makes much sense to talk about what an
anonymous mass of people might want. So Grzegorz and all others reading
this, what would make *you* excited about Cocoon 3 so that *you* would
be willing to contribute?
FWIW, we'll be taking a hard look at moving to Cocoon 3 vs. 2.2 as we
look at migrating off of 2.1. Our main requirement really is for XML
and XSL pipelines and we don't use most of the existing Cocoon
infrastructure, the big thing currently lacking is 3 that we really
need is caching...
Could you elaborate on your caching requirements?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member ***@apache.org
________________________________________________________________________
Peter Hunsberger
2008-11-25 16:57:29 UTC
Permalink
Post by Reinhard Pötz
Could you elaborate on your caching requirements?
We run an Intranet web app, (not a web site) with very complex
dynamically assembled screens. We have fairly long pipelines, with a
lot of aggregated components. There is almost always one component
that cannot be cached at all (or makes little sense to cache) and the
others have varying cache lifetimes. So currently we need to be able
to pull cached SAX streams from the nonchanging components and run the
results through XSLT as per standard Cocoon aggregated validity type
checking.

Any next gen version of our app will likely attempt to move this to a
more granular approach using AJAX on the front end so it should be
possible to eliminate most of, if not all of, the requirement for
aggregated SAX via XSLT. However, even then, for a large chunk of our
data we don't know exactly what can be shared until we examine
security policies that are determined dynamically (eg, based on
previous data requests) so we know we cannot move everything to http /
web server type caching. Similarly, our cache invalidation policies
are complex with hierarchies of dependencies so again you can't set
simple http type cache expiiry policies, you've got to have something
more like the current cocoon validity checking, where we can trigger a
cascade of cache invalidation when some fundamental resource is
updated.

If that raises more questions than it answers I can attempt to elaborate...
--
Peter Hunsberger
Reinhard Pötz
2008-11-26 00:19:40 UTC
Permalink
Post by Peter Hunsberger
Post by Reinhard Pötz
Could you elaborate on your caching requirements?
We run an Intranet web app, (not a web site) with very complex
dynamically assembled screens. We have fairly long pipelines, with a
lot of aggregated components. There is almost always one component
that cannot be cached at all (or makes little sense to cache) and the
others have varying cache lifetimes. So currently we need to be able
to pull cached SAX streams from the nonchanging components and run the
results through XSLT as per standard Cocoon aggregated validity type
checking.
Any next gen version of our app will likely attempt to move this to a
more granular approach using AJAX on the front end so it should be
possible to eliminate most of, if not all of, the requirement for
aggregated SAX via XSLT. However, even then, for a large chunk of our
data we don't know exactly what can be shared until we examine
security policies that are determined dynamically (eg, based on
previous data requests) so we know we cannot move everything to http /
web server type caching. Similarly, our cache invalidation policies
are complex with hierarchies of dependencies so again you can't set
simple http type cache expiiry policies, you've got to have something
more like the current cocoon validity checking, where we can trigger a
cascade of cache invalidation when some fundamental resource is
updated.
If that raises more questions than it answers I can attempt to elaborate...
IMO it would be best to discuss your needs based on what Cocoon 3
already offers (see org.apache.cocoon.pipeline.CachingPipeline) and what
exactly you are missing. And additionally (or alternatively if you
prefer) you could also provide us with a concrete example. I think that
would make many things much clearer.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member ***@apache.org
________________________________________________________________________
Peter Hunsberger
2008-11-26 02:12:02 UTC
Permalink
Post by Reinhard Pötz
IMO it would be best to discuss your needs based on what Cocoon 3
already offers (see org.apache.cocoon.pipeline.CachingPipeline) and what
exactly you are missing. And additionally (or alternatively if you
prefer) you could also provide us with a concrete example. I think that
would make many things much clearer.
We're not at that point yet. Although I've brought the Cocoon 3 code
up that's about all I've done with it.

As I said, our needs are complex; we'll almost certainly extend
whatever get's implemented so it would be good if things were
constructed with that in mind: reasonable interfaces, abstract parent
classes with the housekeeping methods already implemented, no final
methods, etc. Pluggable components maybe?

Which reminds me, how much thought has been given to a component based
architecture?
--
Peter Hunsberger
Simone Tripodi
2008-11-25 17:35:08 UTC
Permalink
Hi All,
just to notify you that Steven ad I already started working on a
caching system in cocoon3 more that 3 weeks ago, maybe the jira's
issue can provide you more infos.
Best regards!!!
Simone
Post by Reinhard Pötz
Post by Peter Hunsberger
Post by Reinhard Pötz
Post by Grzegorz Kossakowski
Cocoon 3.0 started by Reinhard looked promising to me but now I
realize that the main idea of its existence is to more or less
rewrite C2.2 and add some RESTful features.
Yes, that's explained by the first paragraph of the Cocoon 3 website.
Post by Grzegorz Kossakowski
It's not my intention to criticize anyone but I really think it's not
enough to make others excited and willing to contribute. At least it
looks that way...
You probably have missed it but with Simone we actually have one very
active committer and I know that many other people are fond of the
Cocoon 3 pipeline module.
Currently the main problem is that most developers don't know that there
is such a simple thing as the Cocoon 3 pipeline library. I've already
started to provide documentation but haven't got very far yet. But be
assured that it has a very high priority on my opensource todo list.
Post by Grzegorz Kossakowski
Has anyone here thoughts on this topic or it's only me who has a problem?
When I started Cocoon 3 my main goal was to solve two problems: 1)
provide a plain and simple pipeline API that is easily usable from
within any Java environment 2) make Cocoon a simple platform for RESTful
services.
This made *me* excited about it and solves *my* problems. I haven't done
any market research about what would have excited others.
Anyway, I don't think that it makes much sense to talk about what an
anonymous mass of people might want. So Grzegorz and all others reading
this, what would make *you* excited about Cocoon 3 so that *you* would
be willing to contribute?
FWIW, we'll be taking a hard look at moving to Cocoon 3 vs. 2.2 as we
look at migrating off of 2.1. Our main requirement really is for XML
and XSL pipelines and we don't use most of the existing Cocoon
infrastructure, the big thing currently lacking is 3 that we really
need is caching...
Could you elaborate on your caching requirements?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
________________________________________________________________________
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
Reinhard Pötz
2008-11-25 18:16:57 UTC
Permalink
Post by Simone Tripodi
Hi All,
just to notify you that Steven ad I already started working on a
caching system in cocoon3 more that 3 weeks ago, maybe the jira's
issue can provide you more infos.
Simone, is there more information available than
https://issues.apache.org/jira/browse/COCOON3-6? If yes, could you
please give us pointers or otherwise provide us with a summary
explaining what you both are working on?

Many thanks in advance!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member ***@apache.org
________________________________________________________________________
Grzegorz Kossakowski
2008-11-25 22:19:32 UTC
Permalink
Post by Reinhard Pötz
Post by Simone Tripodi
Hi All,
just to notify you that Steven ad I already started working on a
caching system in cocoon3 more that 3 weeks ago, maybe the jira's
issue can provide you more infos.
Simone, is there more information available than
https://issues.apache.org/jira/browse/COCOON3-6? If yes, could you
please give us pointers or otherwise provide us with a summary
explaining what you both are working on?
Many thanks in advance!
I second this ask. Bombing us with patches that are not discussed here is what we all want to avoid.
--
Best regards,
Grzegorz Kossakowski
Steven Dolg
2008-11-25 23:17:44 UTC
Permalink
Post by Grzegorz Kossakowski
Post by Reinhard Pötz
Post by Simone Tripodi
Hi All,
just to notify you that Steven ad I already started working on a
caching system in cocoon3 more that 3 weeks ago, maybe the jira's
issue can provide you more infos.
Simone, is there more information available than
https://issues.apache.org/jira/browse/COCOON3-6? If yes, could you
please give us pointers or otherwise provide us with a summary
explaining what you both are working on?
Many thanks in advance!
I second this ask. Bombing us with patches that are not discussed here is what we all want to avoid.
The number of patches from Simone hardly qualifies for being called
"bombing". Actually the issue mentioned has exactly one patch.

Furthermore I doubt every single change needs to be discussed here
before it is made.
Something as straightforward as "cache the XSLT to avoid parsing it
every single time the pipeline is executed" is IMO one of those things
that should be obvious to everyone.
Especially since - as Sylvain pointed out - "this feature has been
available in Cocoon for ages".

Not everyone is fond of reading long emails that sketch a vague picture.
A clear description of the problem, a suggested solution and a patch
that provides a working implementation is IMO sometimes preferable.
Everyone is able to have a look at the jira issues and the posted
patch(es) and comment on them just like Sylvain did.
Grzegorz Kossakowski
2008-11-25 23:51:42 UTC
Permalink
Post by Steven Dolg
Post by Grzegorz Kossakowski
I second this ask. Bombing us with patches that are not discussed here
is what we all want to avoid.
The number of patches from Simone hardly qualifies for being called
"bombing". Actually the issue mentioned has exactly one patch.
Furthermore I doubt every single change needs to be discussed here
before it is made.
Something as straightforward as "cache the XSLT to avoid parsing it
every single time the pipeline is executed" is IMO one of those things
that should be obvious to everyone.
The idea is obvious, the implementation details as we can see are not so obvious.
Post by Steven Dolg
Especially since - as Sylvain pointed out - "this feature has been
available in Cocoon for ages".
Yep, but if the sequence of events had been a little bit different then the patch wouldn't have to
be rewritten. The idea is not to write detailed plan that is almost comparable with final
implementation but simple saying "I'm going to implement this and this, using this and this. If
someone wants to comment. Go ahead."

A few sentences, right?
Post by Steven Dolg
Not everyone is fond of reading long emails that sketch a vague picture.
A clear description of the problem, a suggested solution and a patch
that provides a working implementation is IMO sometimes preferable.
Everyone is able to have a look at the jira issues and the posted
patch(es) and comment on them just like Sylvain did.
After studying recent issues on COCOON3 I have to admit that level of discussions has increased
which makes me happy. There are several reasons why things should be discussed here.

One of them is that one can grasp what has happened during his offline period.

As for now let's move on more specific things. I'd like to hear your opinion on functional sitemap,
Steven!
--
Grzegorz
Steven Dolg
2008-11-26 17:06:58 UTC
Permalink
Post by Grzegorz Kossakowski
Post by Steven Dolg
Post by Grzegorz Kossakowski
I second this ask. Bombing us with patches that are not discussed here
is what we all want to avoid.
The number of patches from Simone hardly qualifies for being called
"bombing". Actually the issue mentioned has exactly one patch.
Furthermore I doubt every single change needs to be discussed here
before it is made.
Something as straightforward as "cache the XSLT to avoid parsing it
every single time the pipeline is executed" is IMO one of those things
that should be obvious to everyone.
The idea is obvious, the implementation details as we can see are not so obvious.
I really don't think so and I don't understand where the "as we can see"
comes from.
But maybe I'm missing something.
Post by Grzegorz Kossakowski
Post by Steven Dolg
Especially since - as Sylvain pointed out - "this feature has been
available in Cocoon for ages".
Yep, but if the sequence of events had been a little bit different then the patch wouldn't have to
be rewritten. The idea is not to write detailed plan that is almost comparable with final
implementation but simple saying "I'm going to implement this and this, using this and this. If
someone wants to comment. Go ahead."
A few sentences, right?
Post by Steven Dolg
Not everyone is fond of reading long emails that sketch a vague picture.
A clear description of the problem, a suggested solution and a patch
that provides a working implementation is IMO sometimes preferable.
Everyone is able to have a look at the jira issues and the posted
patch(es) and comment on them just like Sylvain did.
After studying recent issues on COCOON3 I have to admit that level of discussions has increased
which makes me happy. There are several reasons why things should be discussed here.
One of them is that one can grasp what has happened during his offline period.
As for now let's move on more specific things. I'd like to hear your opinion on functional sitemap,
Steven!
Honestly I have no opinion on an implementation of the sitemap engine in
a functional language.
Perhaps it's just me, but I fail to see the reason to do so.
I can image that this could be an interesting exercise - but for me this
alone is not sufficient.
There certainly are a lot of things that would be extremely cool to do,
but I usually don't create software without a specific need.

But maybe that's just me.
If you want to do this - just go ahead. I might even take a look at it.
But I seriously doubt that I can make any qualified statement with my
current knowledge and experience in using functional languages.
And TBH those two things are not going to change in the near future...
Torsten Curdt
2008-11-26 17:49:17 UTC
Permalink
Honestly I have no opinion on an implementation of the sitemap engine in a
functional language.
Perhaps it's just me, but I fail to see the reason to do so.
I didn't bother to search the archives ... and this might also been
beer talk during GetTogethers where this came up before ...but IMO the
point is not use necessarily a "functional language" but a language
that is more suited for the job.

Using XML for the sitemap IMO turned out to be a very bad idea in
retrospect. (Well, everything is XML - right) On the other hand
writing a sitemap in a common language (javascript or something
similar) will lead to terrible abuses (as you would only need a subset
of whatever you pick). Coming up with your own DSL has become so
simple that this would be my choice now these days.

I have already seen so many people adopt the sitemap concept in other
projects. (I wish httpd would adopt it!) But everyone came up with
their own implementation. "I just need a little sitemap engine". Let's
face it the component re-use in that aspect is a bit of a myth. (Poll:
how many people re-use cocoon components in other projects as is?)

Maybe it's time to learn from the Cocoon strengths and turn parts of
it into APIs. The pipeline API is a good example. I guess this is the
only way to revive Cocoon's future.

My 2 cents

cheers
--
Torsten
Grzegorz Kossakowski
2008-11-26 22:30:51 UTC
Permalink
Post by Torsten Curdt
Honestly I have no opinion on an implementation of the sitemap engine in a
functional language.
Perhaps it's just me, but I fail to see the reason to do so.
I didn't bother to search the archives ... and this might also been
beer talk during GetTogethers where this came up before ...but IMO the
point is not use necessarily a "functional language" but a language
that is more suited for the job.
You probably have in mind thread started by Ugo Cei "[RT] A Groovy Kind of Sitemap"[1]. I'm still in
process of reading all replies.

Yep, the real point is to use something better than our current sitemap language. I have chosen
functional language (namely Scala) because it's my current field of interest and because I can see
benefits coming from using it.

To point out just a few:
1. More concise and natural syntax. What about pipeline looking like:

FileGenerator("a/template.xml") | XSLTTransformer("b/sth.xslt") | MyTransformer | HTMLSerializer

This is a plain Scala with a few things defined correctly. Scala has a nice support for creation
of DLSs, see[2]

2. Ad-hoc defintions of simple transformers.

3. Debugging support for sitemap.

4. Strong typing for sitemap.
Post by Torsten Curdt
Using XML for the sitemap IMO turned out to be a very bad idea in
retrospect. (Well, everything is XML - right) On the other hand
writing a sitemap in a common language (javascript or something
similar) will lead to terrible abuses (as you would only need a subset
of whatever you pick). Coming up with your own DSL has become so
simple that this would be my choice now these days.
Actually I don't believe that we can stop people making stupid things simply by designing a good
software. Definitively we should encourage people to use our software the proper way but working
hard on obstacles is more questionable.

Anyway, DSL-like syntax is possible in Scala.
Post by Torsten Curdt
I have already seen so many people adopt the sitemap concept in other
projects. (I wish httpd would adopt it!) But everyone came up with
their own implementation. "I just need a little sitemap engine". Let's
how many people re-use cocoon components in other projects as is?)
Maybe it's time to learn from the Cocoon strengths and turn parts of
it into APIs. The pipeline API is a good example. I guess this is the
only way to revive Cocoon's future.
+1 for that.

I guess we all agree that we want to create something more than just a pipeline API and its
implementation, right?

Anyway, it's good that this work has started. Rewriting from scratch but based on our expierience
brings some new opportunities.

[1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/39351
[2] http://www.scala-lang.org/node/104 (Scala is extensible section)
--
Best regards,
Grzegorz Kossakowski
David Crossley
2008-12-02 01:55:04 UTC
Permalink
Post by Grzegorz Kossakowski
Post by Steven Dolg
Post by Grzegorz Kossakowski
I second this ask. Bombing us with patches that are not discussed here
is what we all want to avoid.
The number of patches from Simone hardly qualifies for being called
"bombing". Actually the issue mentioned has exactly one patch.
Furthermore I doubt every single change needs to be discussed here
before it is made.
Something as straightforward as "cache the XSLT to avoid parsing it
every single time the pipeline is executed" is IMO one of those things
that should be obvious to everyone.
The idea is obvious, the implementation details as we can see are not so obvious.
Post by Steven Dolg
Especially since - as Sylvain pointed out - "this feature has been
available in Cocoon for ages".
Yep, but if the sequence of events had been a little bit different then the patch wouldn't have to
be rewritten. The idea is not to write detailed plan that is almost comparable with final
implementation but simple saying "I'm going to implement this and this, using this and this. If
someone wants to comment. Go ahead."
A few sentences, right?
I too was concerned when i saw new patches to re-implement
something that Cocoon has already spent years developing.

A little bit of discussion is a good thing. It enables the rest
of the community to feel that they are still in touch with
the direction of the project.

-David
Post by Grzegorz Kossakowski
Post by Steven Dolg
Not everyone is fond of reading long emails that sketch a vague picture.
A clear description of the problem, a suggested solution and a patch
that provides a working implementation is IMO sometimes preferable.
Everyone is able to have a look at the jira issues and the posted
patch(es) and comment on them just like Sylvain did.
After studying recent issues on COCOON3 I have to admit that level of discussions has increased
which makes me happy. There are several reasons why things should be discussed here.
One of them is that one can grasp what has happened during his offline period.
As for now let's move on more specific things. I'd like to hear your opinion on functional sitemap,
Steven!
--
Grzegorz
Reinhard Pötz
2008-11-26 00:07:45 UTC
Permalink
Post by Grzegorz Kossakowski
Post by Reinhard Pötz
Post by Simone Tripodi
Hi All,
just to notify you that Steven ad I already started working on a
caching system in cocoon3 more that 3 weeks ago, maybe the jira's
issue can provide you more infos.
Simone, is there more information available than
https://issues.apache.org/jira/browse/COCOON3-6? If yes, could you
please give us pointers or otherwise provide us with a summary
explaining what you both are working on?
Many thanks in advance!
I second this ask. Bombing us with patches that are not discussed here is what we all want to avoid.
Simone has created 9 patches so far. Although not all of them have been
applied yet, I don't think that we suffer from an overload. So Simone,
keep on bombing us ;-)

I also want to mention that all in all I'm satisfied with the
information that is added to each Jira issue. It was only the XSLT
caching issue which deserves further discussions IMO because, as Sylvain
pointed out, we should learn from the 2.x implementation and I'm sure
that some of the 'oldies' around here would be happy to share their
knowledge.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member ***@apache.org
________________________________________________________________________
Grzegorz Kossakowski
2008-11-25 22:15:55 UTC
Permalink
Post by Reinhard Pötz
Post by Grzegorz Kossakowski
Cocoon 3.0 started by Reinhard looked promising to me but now I
realize that the main idea of its existence is to more or less
rewrite C2.2 and add some RESTful features.
Yes, that's explained by the first paragraph of the Cocoon 3 website.
Ahhh right, I've looked at source code of C3 but forgot about the website. Apparently, I have to
check recent developments of C3.
Post by Reinhard Pötz
You probably have missed it but with Simone we actually have one very
active committer and I know that many other people are fond of the
Cocoon 3 pipeline module.
Yes, sort of.
Post by Reinhard Pötz
Currently the main problem is that most developers don't know that there
is such a simple thing as the Cocoon 3 pipeline library. I've already
started to provide documentation but haven't got very far yet. But be
assured that it has a very high priority on my opensource todo list.
Good to hear that. Some advertising company on e.g. Pipeline library that would show us it's
potential would be useful but it might be that I ask for way too much. ;-)
Post by Reinhard Pötz
Post by Grzegorz Kossakowski
Has anyone here thoughts on this topic or it's only me who has a problem?
When I started Cocoon 3 my main goal was to solve two problems: 1)
provide a plain and simple pipeline API that is easily usable from
within any Java environment 2) make Cocoon a simple platform for RESTful
services.
This made *me* excited about it and solves *my* problems. I haven't done
any market research about what would have excited others.
It would be very nice if you could provide some more details how it solved your problems and what
kind of problems. I suspect that you have lots of ideas how this thing should evolve and what kind
of new opportunities it brings to us.

I would really like to help you with building up the community but before I can start doing that I
need a solid background, a vision so I can guide others. That's why I'm asking for all of that all
of the time.
Post by Reinhard Pötz
Anyway, I don't think that it makes much sense to talk about what an
anonymous mass of people might want. So Grzegorz and all others reading
this, what would make *you* excited about Cocoon 3 so that *you* would
be willing to contribute?
Actually, I find myself at the crossroads now. I haven't done anything really pleasant that would
make me happy with C2.2. The COCOON-2216 issues almost killed my whole motivation when it comes to
C2.2. I feel like the time I can hack C2.2's core is over for me. Until someone helps me with this I
will probably stay away of C2.2 completely because this issue blocks most of my plans when it comes
to C2.2.

That's a reason for me to look for something new.

SSF should get some attention so SAX forwarding is implement and some caching bugs are fixed.
Anyway, I would like to leave this task for someone else as it's a bad situation that it looks like
only me and you have an idea what's going on there. I want someone else to become involved.


So the only thing left is C3. What would make me excited? The best thing would be to rewrite C3 in
some pure functional language like Haskell. ;-)

Ok, that's a joke but an introduction to something more serious. I've been off-line a while which
was a perfect chance to read some books and papers. Let's start with a quote from a master thesis
"Implementing an XSLT processor for the Haskell XML Toolbox" by Tim Walkenhorst[1]:

"The processor is written in a purely in Haskell 98 and does not make use of any advanced
libraries. [...] It might be possible to make the implementation even shorter and more concise by
using this features; however, the basic implementation should enable interested volunteers
to gain familiarity with the code rather quickly. The entire implementation has about 1800
lines of code and is thereby 192 times smaller than the XALAN Java implementation which
has about 347000 lines of code.[...]
Of course, we could not implement the full functionality of
such a huge tool within one master thesis; however, it should be possible to perform the
most common kinds of stylesheet transformations within the subset of XSLT we
implemented."

You read it correctly. The XSLT processor implemented with 1800 lines of Haskell vs 347000 lines of
Java. I've checked features and parts of specification that are not implemented and I found that
they don't form a big portion of the whole specification and seemed to be rather trivial implement.
Of course, this processor does not additional features of Xalan like support for debugging, etc.

Anyway, can you think of almost complete implementation of XSLT 1.0 spec. in 2000 lines of Java? I
cannot.

Even more surprising, I can moderately easily read that code even if I'm not fluent in Haskell. I
guess I'm not the only one realizing that a reason for such a phenomenon must be something more than
just a fancy syntax.


-------------- o0o --------------


Of course, proposing to reimplement something like Cocoon would be just a joke because there is only
a little industry support for Haskell and Apache is definitively industry-oriented. However, there
is a compromise solution called Scala[2]. The main advantage (and disadvantage at the same time) of
Scala that it's been designed from scratch to play well with Java but at the same time incorporate
functional programing features and ideas.

It's looks to me that in C3 the idea of using scripting language for flow/controller has been
abandoned. I've never been a great supporter of scripting languages with weak typing like
Javascript. At the same time, I can understand those people that see scripting languages sexy.
Obviously, there are some constructs that are awkward and verbose (thus overly complicated) in Java
and much simpler counterpart in some scripting language. On the other hand, lack of refactoring and
need for extensive unit-testing for every little-stupid-thing is a major problem with scripting
languages. A nice paragraph[3] on that can be found in "Real World Haskell" that has just hit the
shelves and additionally is available for free online.

Anyway, there is a third option provided by functional languages which *are* strongly typed (at
least those that I'm aware of) but at the same time provide flexibility found in scripting
languages. Therefore I would like to work on integrating Scala into Cocoon.

This idea is rather fresh and I'm only starting with Scala but idea would be to implement two parts
of Cocoon in Scala:
1. Sitemap (or something corresponding)
2. Controllers

I guess this e-mail is already long enough to cut it here. If you are interested in my ideas on
providing functional implementation of sitemap (that would be inspired by some characteristics of
bash) I could write a little bit more on it with some details.

If there is no interest in such subject and I do not find any other interesting thing to do I'll
probably start a fork of C3 at GitHub so it won't interfere with your work here.


Having pipelines as capable higher-order functions seems to be a neat idea...



[1] http://www.fh-wedel.de/~si/HXmlToolbox/xslt/thesis.pdf
[2] http://www.scala-lang.org/
[3] http://book.realworldhaskell.org/read/types-and-functions.html#id577931
[4] http://en.wikipedia.org/wiki/Pure_function
--
Best regards,
Grzegorz Kossakowski
Sylvain Wallez
2008-11-26 10:33:56 UTC
Permalink
I guess this e-mail is already long enough to cut it here. If you are interested in my ideas on providing functional implementation of sitemap (that would be inspired by some characteristics of bash) I could write a little bit more on it with some details.
Interesting thoughts, especially as I am myself interested in functional
programming, which I started with Javascript, then learned Erlang and
looked at Scala as a very interesting way to bring those programming
paradigms to the Java platform.

Now we have to think about what this community is about, and what we can
do to make it successful again. An open source community is a delicate
balance between interest of developers in developing the product, and
interest of users in actually using the product. The concept of
"interest" covers many different aspects: for developers, this includes
a combination of hacking pleasure, pure altruism, strengthening a
business related to the product, socializing with like-minded people,
etc. For users, it includes being able to be efficient and productive,
finding support from developers and other users, and being able to
understand the product to tune it and ultimately write bugfixes and
patches, opening the way to committership.

The Cocoon community has been a bit special in this regard, since Cocoon
allows to do quite complex stuff with a small amount of "code" (sitemap
and XSLT are code) and without requiring strong programming skills. I
remember someone sending a "Thank you" email, explaining how Cocoon
allowed him to do stuff he wouldn't have been able to do without it, and
thus start a consulting business that allowed him to work from home and
spend more time with his family. How rewarding for us developers! Cocoon
allows less skilled users to _do_ stuff, and skilled developers to be
highly productive. This is why this complex product attracted brillant
innovation but at the same time was more accessible to average people
than less sophisticated products.

Looking at our website, I think we have forgotten what forms our
community: "Apache Cocoon is a Spring-based framework (since version 2.2
of Cocoon) built around the concepts of separation of concerns and
component-based development. Cocoon implements these concepts around the
notion of component pipelines, each component on the pipeline
specializing on a particular operation."

Well, Cocoon old-timers understand what it means (at least roughly in my
case, as I never digged into blocks). Now put yourself as a newcomer,
especially a less skilled person representing the largest part of our
users. What the heck is this Cocoon stuff all about? What kind of
problems does it solve? How is it different/better than other products I
can find at Apache and elsewhere?

Cocoon has been very successful by being a superb integration platform
for everything that can be represented as XML, and there are blocks for
every Apache-compatible library that can produce or consume XML. Even
music, and I've seen people's jaws dropping when I showed them the Bach
prelude being processed in XSLT. Over time blocks have accumulated, the
framework has been abstracted and modularized to become even more
flexible and address even more problems, but this came with a price:
newcomers simply can't grasp what Cocoon is about.

Also, Cocoon has been an incredible source of innovation, with its
component architecture, the ReSTful sitemap, the mighty (but complex)
portal, server-side scripting, continuations, etc. But the outside world
has also innovated, and new frameworks/techniques have emerged, at all
levels of the stack: Spring as a replacement for Avalon, Wicket for
complex forms, GWT and many others for Ajax, aggregated pages and
portals are now replaced with Ajax gadgets, etc.

The newer products aren't necessarily easier to use, but are probably
easier to grasp because they do less, or have more introductory
material, or are more "standard" (i.e. widely accepted, be it for good
reasons or not). There also has been simpler approaches such as Django,
Ruby on Rails, or the numerous PHP equivalents.

Coming back to the original proposal, my opinion is that writing Cocoon
in a functional language would be a fun exercise, but nobody would use
it because nobody in this community would understand it. Note that I say
_this_ community, since for example the CouchDB community happily hacks
hard-core functional Erlang.

Also we have to consider that the XML hype is fading away and that the
times of "everything can be represented as XML" are over, for good
reasons or not. Welcome JSON as a replacement to XML for data
interchange, because it's much more lightweight, native in browsers, and
more typed than XML (it has numbers, arrays, maps).

Considering this, my personal opinion is that XML pipelines still have a
value, but this value has been reduced back to the original goals of
Cocoon: document transformation for multiple presentations. But it's no
more good as the foundation of a whole application since other
techniques and new approaches (esp Ajax and JSON) have made it easier.

At least this is my feeling and own experience. At $work we have a
full-ajax portal, and a very simple URL-matching Java library that has
most of the sitemap matching features in a dozen classes, and a
super-lightweight XML pipeline engine to adapt HTML pages for the web or
mobile phones. And we use Wicket for data-intensive backoffice webapps.

So what does this all mean for our community? What community of users
should we target? The historical community described above, or a new
kind of community? What's in Cocoon to make it appealing to newcomers?
XML pipelines, the sitemap, server-side scripting and continuations.
Cocoon 2.2 has buried them under a huge technical and presentational
complexity.

Cocoon 3 builds on these core values, but is already IMHO too complex by
having more than a dozen different modules. Note that this complexity is
more organizational than technical, but it makes it too difficult for
people to find their way there (that was my case). Also, a complete
rewrite is needed, but at the same time we should not forget all the
technical expertise that has been put in Cocoon over the years (e.g.
cache, work arounds for well-known Xalan quirks, etc) and completely
reinvent the wheel. Difficult exercise.

I know this mail brings more questions than answers, and Cocoon has to
reinvent itself, both from a technical and a community point of view.
Are we ready for this reinvention? Can a consensus emerge on what it
should be? The answer is ours.

Thanks for reading so far.

Sylvain
--
Sylvain Wallez - http://bluxte.net
Luca Morandini
2008-11-26 13:19:58 UTC
Permalink
Post by Sylvain Wallez
I know this mail brings more questions than answers, and Cocoon has to
reinvent itself, both from a technical and a community point of view.
Are we ready for this reinvention? Can a consensus emerge on what it
should be? The answer is ours.
To put it succinctly: Cocoon has, mostly, failed to be a popular
one-stop framework for web application development, and this while the
focus on XML faded, leaving Cocoon a bit passè.

As a matter of fact, I am now developing using the Hibernate/Cocoon
2.2/DoJo stack in RESTful-style applications, and still found the
sitemap a breeze to use for managing the URI- and HTTP methods- space,
but I renounced to continuations and Cocoon Forms (not RESTful enough).

In the end, I think Cocoon is great for views (XML processing, i18n,
URI-space management), so-and-so for controllers (which should be on the
client anyway), irrelevant for models.

Hmm... given the above, I'd rather concentrate on views and sitemap,
like: standardizing the expression language between sitemap and JX
templates, better support to JSON, etc.

Just my 0.2€.
Post by Sylvain Wallez
Thanks for reading so far.
Don't mention, it was a pleasure.

Regards,

P.S.
If people keep insisting on functional languages, I will launch my bid
for a total conversion of Cocoon to the one and only OO language:
Smalltalk !
;)


--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Thorsten Scherler
2008-11-26 13:45:07 UTC
Permalink
Post by Luca Morandini
Post by Sylvain Wallez
I know this mail brings more questions than answers, and Cocoon has to
reinvent itself, both from a technical and a community point of view.
Are we ready for this reinvention? Can a consensus emerge on what it
should be? The answer is ours.
To put it succinctly: Cocoon has, mostly, failed to be a popular
one-stop framework for web application development, and this while the
focus on XML faded, leaving Cocoon a bit passè.
As a matter of fact, I am now developing using the Hibernate/Cocoon
2.2/DoJo stack in RESTful-style applications, and still found the
sitemap a breeze to use for managing the URI- and HTTP methods- space,
but I renounced to continuations and Cocoon Forms (not RESTful enough).
In the end, I think Cocoon is great for views (XML processing, i18n,
URI-space management), so-and-so for controllers (which should be on the
client anyway), irrelevant for models.
Hmm... given the above, I'd rather concentrate on views and sitemap,
like: standardizing the expression language between sitemap and JX
templates, better support to JSON, etc.
Actually more or less the same here. I like the sitemap concept since it
allows my team to create "connectors" and in our portal we can just use
the matches from the connectors. It is an abstraction layer since we
have x different data sources (from db to the different flavors of cms),
further this data sources are moving targets so we need to have this
abstraction to not have to change our presentation layer all the time.

Never had been a big fan of the flow/forms stuff since IMO there are
other more qualified tools for this kind of development (like e.g.
Sylvain pointed out) and if I used flow it was java based.

Like Luca said
Post by Luca Morandini
Cocoon is great for views (XML processing, i18n,
URI-space management), so-and-so for controllers (which should be on the
client anyway), irrelevant for models.
where I need to say more front-end controller then other stuff.
Regarding the models cocoon should provide a clean easy to use approach
to pass models to the different components but not much more.

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

Sociedad Andaluza para el Desarrollo de la Sociedad
de la Información, S.A.U. (SADESI)
Grzegorz Kossakowski
2008-11-26 22:58:26 UTC
Permalink
Post by Luca Morandini
Hmm... given the above, I'd rather concentrate on views and sitemap,
like: standardizing the expression language between sitemap and JX
templates, better support to JSON, etc.
Standarizing expression is a task more for 2.3. Actually most of the code is already in place. There
are only a few open bugs that are blocking this to happen.

It's a pity I'm not able to tackle them...
Post by Luca Morandini
Post by Sylvain Wallez
Thanks for reading so far.
Don't mention, it was a pleasure.
Regards,
P.S.
If people keep insisting on functional languages, I will launch my bid
Smalltalk !
;)
That would be dangerous. ;-)
--
Grzegorz Kossakowski
s***@apache.org
2008-11-26 21:31:36 UTC
Permalink
"Apache Cocoon is a Spring-based framework (since version 2.2 of Cocoon)
built around the concepts of separation of concerns and component-based
development. Cocoon implements these concepts around the notion of component
pipelines, each component on the pipeline specializing on a particular
operation."
Sylvain Wallez - http://bluxte.net
Seems the project definition does not fit the typical first use. My
definition is:

Cocoon allows easy manipulation of XML using pipes defined in XML:
generate/aggregate - load content
transform - modify content using XSL.
serialize - deliver in a variety of formats.

This allows non-programmers to be productive writing simple XML-based
applications. Everything else is for extensibility. The many blocks,
Java programming, Spring architecture, etc. allow complete control and
the addition of almost any functionality, but the primary reason to
use Cocoon is for easy manipulation of XML.

Whether XML is no longer the current fad should not be relevant.
Cocoon is an XML processing platform built on Java. Change this
statement, and the result would no longer be Cocoon. This does not
imply that any architecture improvements are unimportant, just that
the primary purpose must be honored. Some suggestions (e.g. changing
the programming language) should require creating a new project.

solprovider
Bertrand Delacretaz
2008-11-27 08:55:33 UTC
Permalink
Hi,
Post by s***@apache.org
...My
generate/aggregate - load content
transform - modify content using XSL.
serialize - deliver in a variety of formats...
Agree with that, although I've been (successfully and happily)
building complete applications with Cocoon in the past, I wouldn't do
that today anymore.

But if I have to process XML data or generate various formats from
XML, the above functionalities remain a good choice - ideally
embeddable in today's java environments. That's why I'm keeping an eye
on Cocoon 3, although I haven't been able to do more than that lately.
Post by s***@apache.org
...Whether XML is no longer the current fad should not be relevant.
Cocoon is an XML processing platform built on Java. Change this
statement, and the result would no longer be Cocoon....
Agree with that as well.

-Bertrand
Simone Tripodi
2008-11-28 15:50:52 UTC
Permalink
Hi everybody,
I'm the younger person - in therms of cocoon's experience - who
recently joined Reinhard and Steven in their enthusiasm about Cocoon3.

Please let me spend my 0.2€ too, feel free moving this email in the
spam or trash box :)

Just a prelude: I've never experienced using oldest Cocoon's release,
but months ago, while I was working on an important OpenID provider
(for the biggest Italian Telecommunication company), I had the need to
generate , manipulate, validate, transform and serialize large XML
data set in various format.
So I felt the need to use a solid framework able to help me in a quick
and clear way... so, the miracle happened when I found "accidentally"
the Reinhard's blog.
My first word was just a "wow!", so I wrote an email to him. I was
totally charmed, not only about Cocoon, but above all the
collaborative way that both Reinhard and Steven demonstrated in
explaining me how the new Cocoon works, helping me in adopting it in
the way to resolve my problems and involving me in the development,
exhorting me in "bombing" the Issue Tracker :)

Starting from that time, I've been evangelizing new Pipeline APIs, our
customer are satisfied by the product we developed on top of them...
and finally, also some friend of mine started being Cocoon3's users.
Everybody agree that's a nice framework with - more important - an
excellent community behind.

So, in my humble opinion, Cocoon3 has sense to exist. I like it, I
adore it, it resolved my problems and makes me enthusiastic. Reinhard
is a great leader, and Steven an excellent guide, and this justifies -
at least, for me - that Cocoon3's community MUST exist. I'm sure
there's someone that, like me, one day will need joining this great
community.

Best regards, sorry for the
David Crossley
2008-12-02 01:39:01 UTC
Permalink
Post by Simone Tripodi
Hi everybody,
I'm the younger person - in therms of cocoon's experience - who
recently joined Reinhard and Steven in their enthusiasm about Cocoon3.
Please let me spend my 0.2??? too, feel free moving this email in the
spam or trash box :)
Thanks for your comments. Very important.
Post by Simone Tripodi
Just a prelude: I've never experienced using oldest Cocoon's release,
but months ago, while I was working on an important OpenID provider
(for the biggest Italian Telecommunication company), I had the need to
generate , manipulate, validate, transform and serialize large XML
data set in various format.
So I felt the need to use a solid framework able to help me in a quick
and clear way... so, the miracle happened when I found "accidentally"
the Reinhard's blog.
My first word was just a "wow!", so I wrote an email to him. I was
totally charmed, not only about Cocoon, but above all the
collaborative way that both Reinhard and Steven demonstrated in
explaining me how the new Cocoon works, helping me in adopting it in
the way to resolve my problems and involving me in the development,
exhorting me in "bombing" the Issue Tracker :)
It would be better if we all heard those explanations
here on the dev list.
Post by Simone Tripodi
Starting from that time, I've been evangelizing new Pipeline APIs, our
customer are satisfied by the product we developed on top of them...
and finally, also some friend of mine started being Cocoon3's users.
Everybody agree that's a nice framework with - more important - an
excellent community behind.
Please encourage your collaborators to join us.

-David
Post by Simone Tripodi
So, in my humble opinion, Cocoon3 has sense to exist. I like it, I
adore it, it resolved my problems and makes me enthusiastic. Reinhard
is a great leader, and Steven an excellent guide, and this justifies -
at least, for me - that Cocoon3's community MUST exist. I'm sure
there's someone that, like me, one day will need joining this great
community.
Best regards, sorry for the spam :)
Simone
Grzegorz Kossakowski
2008-11-26 22:55:43 UTC
Permalink
Post by Sylvain Wallez
Post by Grzegorz Kossakowski
I guess this e-mail is already long enough to cut it here. If you are
interested in my ideas on providing functional implementation of
sitemap (that would be inspired by some characteristics of bash) I
could write a little bit more on it with some details.
Interesting thoughts, especially as I am myself interested in functional
programming, which I started with Javascript, then learned Erlang and
looked at Scala as a very interesting way to bring those programming
paradigms to the Java platform.
Hi Sylvain.

Thanks for your comments. Great integration of Scala with Java is one the most important reasons why
I brought Scala into this discussion.

For others reading this thread: Scala's code compiles to a binary format understood by JVM so you
can use Java code from Scala code and the opposite way.
Post by Sylvain Wallez
Now we have to think about what this community is about, and what we can
do to make it successful again. An open source community is a delicate
balance between interest of developers in developing the product, and
interest of users in actually using the product. The concept of
"interest" covers many different aspects: for developers, this includes
a combination of hacking pleasure, pure altruism, strengthening a
business related to the product, socializing with like-minded people,
etc. For users, it includes being able to be efficient and productive,
finding support from developers and other users, and being able to
understand the product to tune it and ultimately write bugfixes and
patches, opening the way to committership.
The Cocoon community has been a bit special in this regard, since Cocoon
allows to do quite complex stuff with a small amount of "code" (sitemap
and XSLT are code) and without requiring strong programming skills. I
remember someone sending a "Thank you" email, explaining how Cocoon
allowed him to do stuff he wouldn't have been able to do without it, and
thus start a consulting business that allowed him to work from home and
spend more time with his family. How rewarding for us developers! Cocoon
allows less skilled users to _do_ stuff, and skilled developers to be
highly productive. This is why this complex product attracted brillant
innovation but at the same time was more accessible to average people
than less sophisticated products.
Yep, that's a great description of Cocoon strengths. The question that comes to my mind is if we
still continue to maintain these characteristics?
Post by Sylvain Wallez
Looking at our website, I think we have forgotten what forms our
community: "Apache Cocoon is a Spring-based framework (since version 2.2
of Cocoon) built around the concepts of separation of concerns and
component-based development. Cocoon implements these concepts around the
notion of component pipelines, each component on the pipeline
specializing on a particular operation."
Ok, that looks like an answer to the above question. ;-)
Post by Sylvain Wallez
Well, Cocoon old-timers understand what it means (at least roughly in my
case, as I never digged into blocks). Now put yourself as a newcomer,
especially a less skilled person representing the largest part of our
users. What the heck is this Cocoon stuff all about? What kind of
problems does it solve? How is it different/better than other products I
can find at Apache and elsewhere?
Cocoon has been very successful by being a superb integration platform
for everything that can be represented as XML, and there are blocks for
every Apache-compatible library that can produce or consume XML. Even
music, and I've seen people's jaws dropping when I showed them the Bach
prelude being processed in XSLT. Over time blocks have accumulated, the
framework has been abstracted and modularized to become even more
newcomers simply can't grasp what Cocoon is about.
Also, Cocoon has been an incredible source of innovation, with its
component architecture, the ReSTful sitemap, the mighty (but complex)
portal, server-side scripting, continuations, etc. But the outside world
has also innovated, and new frameworks/techniques have emerged, at all
levels of the stack: Spring as a replacement for Avalon, Wicket for
complex forms, GWT and many others for Ajax, aggregated pages and
portals are now replaced with Ajax gadgets, etc.
The newer products aren't necessarily easier to use, but are probably
easier to grasp because they do less, or have more introductory
material, or are more "standard" (i.e. widely accepted, be it for good
reasons or not). There also has been simpler approaches such as Django,
Ruby on Rails, or the numerous PHP equivalents.
Coming back to the original proposal, my opinion is that writing Cocoon
in a functional language would be a fun exercise, but nobody would use
it because nobody in this community would understand it. Note that I say
_this_ community, since for example the CouchDB community happily hacks
hard-core functional Erlang.
By introduction of flowscript many people from this community (including me) has been, in fact,
gently forced to learn that language. Given the fact that flowscript is widely used it looks like it
wasn't harmful experience.

I would like to see similar route for Scala that is gently introduced and its integration is
orthogonal to mainstream implementation. The it would be community's decision if we want to develop
and support it.

Also, I'm not proposing to rewrite everything into Scala because it does not make any sense to me;
at least at this stage.
Post by Sylvain Wallez
Also we have to consider that the XML hype is fading away and that the
times of "everything can be represented as XML" are over, for good
reasons or not. Welcome JSON as a replacement to XML for data
interchange, because it's much more lightweight, native in browsers, and
more typed than XML (it has numbers, arrays, maps).
Considering this, my personal opinion is that XML pipelines still have a
value, but this value has been reduced back to the original goals of
Cocoon: document transformation for multiple presentations. But it's no
more good as the foundation of a whole application since other
techniques and new approaches (esp Ajax and JSON) have made it easier.
Our XML pipeline may serialize into JSON. The point is in how we obtain, aggregate and transform the
data. For all of this I thing XML is still the best choice.

Moreover, the fading hype of XML might be caused by some other subtle fact. Usually an XML document
is represented as a rather heavy *tree* of objects. The problem is that imperative languages (like
Java) are very bad at processing trees. At least they a way worse than most of functional languages.

Processing XML document in Java is painful and boring so it's not so surprising that people look for
something easier. Of course this only adds to your arguments.
Post by Sylvain Wallez
At least this is my feeling and own experience. At $work we have a
full-ajax portal, and a very simple URL-matching Java library that has
most of the sitemap matching features in a dozen classes, and a
super-lightweight XML pipeline engine to adapt HTML pages for the web or
mobile phones. And we use Wicket for data-intensive backoffice webapps.
So what does this all mean for our community? What community of users
should we target? The historical community described above, or a new
kind of community? What's in Cocoon to make it appealing to newcomers?
XML pipelines, the sitemap, server-side scripting and continuations.
Cocoon 2.2 has buried them under a huge technical and presentational
complexity.
From your list my personal choice would be: XML Pipelines, Sitemap.
With rich clients the need for continuations seems to be fading away. At least I've lost interest in
this subject completely.
Post by Sylvain Wallez
Cocoon 3 builds on these core values, but is already IMHO too complex by
having more than a dozen different modules. Note that this complexity is
more organizational than technical, but it makes it too difficult for
people to find their way there (that was my case). Also, a complete
rewrite is needed, but at the same time we should not forget all the
technical expertise that has been put in Cocoon over the years (e.g.
cache, work arounds for well-known Xalan quirks, etc) and completely
reinvent the wheel. Difficult exercise.
I know this mail brings more questions than answers, and Cocoon has to
reinvent itself, both from a technical and a community point of view.
Are we ready for this reinvention? Can a consensus emerge on what it
should be? The answer is ours.
As I've expressed I would love to see a reminiscence of Cocoon's "invention corner". We used to be
good at it, why not to continue this tradition?
Post by Sylvain Wallez
Thanks for reading so far.
Thanks for answering.
--
Best regards,
Grzegorz Kossakowski
Simone Gianni
2008-11-26 13:48:49 UTC
Permalink
Hi Grzergorz,
I've been reading of this thing of "write the same stuff using just a
few lines, not like in java" all over in the last two years, and I
tested it out using a large number of these languages, from Python to
Ruby to Scala, and I can assure you that it is mostly FALSE.

On one side, surely Java IS a verbose language, and surely there can be
more concise ones, but the entire idea of line counting is an error. I
can pretty well write Xalan in a single line of Java code, it's just a
matter of executing s/\n// on the whole source code :) :)

In fact :
- Many tools out there (CLOC just to mention one) consider also the
closing bracket a line of code, while obviously it is not.
- Using chaining (like A.b().c().d().e().f()) will reduce 5 "lines of
code" to one, but in reality you are always writing 5 calls .. same
amount of headache and possible bugs, or even more cause your code is
less readable.

Also considering a better metric, like the number of join points or
branches or whatever else, there are a number of reasons why these
claims are at least exaggerated :
- Many of these languages have huge libraries, with hundreds of methods
that accomplish most tasks that would require you to write lines of code
in java. This is not a bad thing in itself, but to make an appropriate
count of lines of code you should put all these stuff in a separate
library (commons is there for this reason), and see how many "lines of
code" are present in your CORE code.
- Most of these libraries are not customizable in any way, they do work
perfectly 90% of times which is good, but you will end up having to
re-implement part of these. Java went the opposite way : the bare
minimum on the common library, no facades except where really really
useful, which will require a lot of code from the programmer. None of
the two is the perfect way, both have drawbacks.
- Many of these libraries are tiny in number of lines because they are
also tiny in functionalities. For example :
... They don't implement what they claim to completely, or implement an
early version of it, partially and in a buggy way.
... Have not gone thru the pain of adding all the features users will
ask you to add, which can make a simple one-man-show library grow up to
thousands of hundreds of lines in a few years.
... Have not gone thru any test or bugfixing, and bugfixing WILL
ENORMOUSLY increase the "size" of code (and also make it a mess).
... Usually does not have all the fluff around the basic core, like
utilities, error messages, handling of special cases or exceptions, and
so on ... that will also make your code multiply in size.

Obviously, there are languages which are easier than Java, more concise,
more performant and all the rest, functional approach is easier than
passing Runnables, there are no doubt about the fact that our industry
is young and there is huge space for new technologies, and probably
Cocoon would greatly benefit from some of them.

But take these revolutionary claims for what they are : propaganda, not
necessarily real facts, or at least not THAT MUCH as they try to
demonstrate.

Just my 2 cents.

Simone
Post by Grzegorz Kossakowski
Post by Reinhard Pötz
Post by Grzegorz Kossakowski
Cocoon 3.0 started by Reinhard looked promising to me but now I
realize that the main idea of its existence is to more or less
rewrite C2.2 and add some RESTful features.
Yes, that's explained by the first paragraph of the Cocoon 3 website.
Ahhh right, I've looked at source code of C3 but forgot about the website. Apparently, I have to
check recent developments of C3.
Post by Reinhard Pötz
You probably have missed it but with Simone we actually have one very
active committer and I know that many other people are fond of the
Cocoon 3 pipeline module.
Yes, sort of.
Post by Reinhard Pötz
Currently the main problem is that most developers don't know that there
is such a simple thing as the Cocoon 3 pipeline library. I've already
started to provide documentation but haven't got very far yet. But be
assured that it has a very high priority on my opensource todo list.
Good to hear that. Some advertising company on e.g. Pipeline library that would show us it's
potential would be useful but it might be that I ask for way too much. ;-)
Post by Reinhard Pötz
Post by Grzegorz Kossakowski
Has anyone here thoughts on this topic or it's only me who has a problem?
When I started Cocoon 3 my main goal was to solve two problems: 1)
provide a plain and simple pipeline API that is easily usable from
within any Java environment 2) make Cocoon a simple platform for RESTful
services.
This made *me* excited about it and solves *my* problems. I haven't done
any market research about what would have excited others.
It would be very nice if you could provide some more details how it solved your problems and what
kind of problems. I suspect that you have lots of ideas how this thing should evolve and what kind
of new opportunities it brings to us.
I would really like to help you with building up the community but before I can start doing that I
need a solid background, a vision so I can guide others. That's why I'm asking for all of that all
of the time.
Post by Reinhard Pötz
Anyway, I don't think that it makes much sense to talk about what an
anonymous mass of people might want. So Grzegorz and all others reading
this, what would make *you* excited about Cocoon 3 so that *you* would
be willing to contribute?
Actually, I find myself at the crossroads now. I haven't done anything really pleasant that would
make me happy with C2.2. The COCOON-2216 issues almost killed my whole motivation when it comes to
C2.2. I feel like the time I can hack C2.2's core is over for me. Until someone helps me with this I
will probably stay away of C2.2 completely because this issue blocks most of my plans when it comes
to C2.2.
That's a reason for me to look for something new.
SSF should get some attention so SAX forwarding is implement and some caching bugs are fixed.
Anyway, I would like to leave this task for someone else as it's a bad situation that it looks like
only me and you have an idea what's going on there. I want someone else to become involved.
So the only thing left is C3. What would make me excited? The best thing would be to rewrite C3 in
some pure functional language like Haskell. ;-)
Ok, that's a joke but an introduction to something more serious. I've been off-line a while which
was a perfect chance to read some books and papers. Let's start with a quote from a master thesis
"The processor is written in a purely in Haskell 98 and does not make use of any advanced
libraries. [...] It might be possible to make the implementation even shorter and more concise by
using this features; however, the basic implementation should enable interested volunteers
to gain familiarity with the code rather quickly. The entire implementation has about 1800
lines of code and is thereby 192 times smaller than the XALAN Java implementation which
has about 347000 lines of code.[...]
Of course, we could not implement the full functionality of
such a huge tool within one master thesis; however, it should be possible to perform the
most common kinds of stylesheet transformations within the subset of XSLT we
implemented."
You read it correctly. The XSLT processor implemented with 1800 lines of Haskell vs 347000 lines of
Java. I've checked features and parts of specification that are not implemented and I found that
they don't form a big portion of the whole specification and seemed to be rather trivial implement.
Of course, this processor does not additional features of Xalan like support for debugging, etc.
Anyway, can you think of almost complete implementation of XSLT 1.0 spec. in 2000 lines of Java? I
cannot.
Even more surprising, I can moderately easily read that code even if I'm not fluent in Haskell. I
guess I'm not the only one realizing that a reason for such a phenomenon must be something more than
just a fancy syntax.
-------------- o0o --------------
Of course, proposing to reimplement something like Cocoon would be just a joke because there is only
a little industry support for Haskell and Apache is definitively industry-oriented. However, there
is a compromise solution called Scala[2]. The main advantage (and disadvantage at the same time) of
Scala that it's been designed from scratch to play well with Java but at the same time incorporate
functional programing features and ideas.
It's looks to me that in C3 the idea of using scripting language for flow/controller has been
abandoned. I've never been a great supporter of scripting languages with weak typing like
Javascript. At the same time, I can understand those people that see scripting languages sexy.
Obviously, there are some constructs that are awkward and verbose (thus overly complicated) in Java
and much simpler counterpart in some scripting language. On the other hand, lack of refactoring and
need for extensive unit-testing for every little-stupid-thing is a major problem with scripting
languages. A nice paragraph[3] on that can be found in "Real World Haskell" that has just hit the
shelves and additionally is available for free online.
Anyway, there is a third option provided by functional languages which *are* strongly typed (at
least those that I'm aware of) but at the same time provide flexibility found in scripting
languages. Therefore I would like to work on integrating Scala into Cocoon.
This idea is rather fresh and I'm only starting with Scala but idea would be to implement two parts
1. Sitemap (or something corresponding)
2. Controllers
I guess this e-mail is already long enough to cut it here. If you are interested in my ideas on
providing functional implementation of sitemap (that would be inspired by some characteristics of
bash) I could write a little bit more on it with some details.
If there is no interest in such subject and I do not find any other interesting thing to do I'll
probably start a fork of C3 at GitHub so it won't interfere with your work here.
Having pipelines as capable higher-order functions seems to be a neat idea...
[1] http://www.fh-wedel.de/~si/HXmlToolbox/xslt/thesis.pdf
[2] http://www.scala-lang.org/
[3] http://book.realworldhaskell.org/read/types-and-functions.html#id577931
[4] http://en.wikipedia.org/wiki/Pure_function
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/
Luca Morandini
2008-11-26 14:27:05 UTC
Permalink
Post by Simone Gianni
On one side, surely Java IS a verbose language, and surely there can be
more concise ones,
You got to try APL to fully understand what "conciseness" is, not to
mention Whitespace... but, ultimately, programs are read by humans
(literate programming, anyone ?).

Regards,

--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Grzegorz Kossakowski
2008-11-26 22:04:13 UTC
Permalink
Post by Simone Gianni
Hi Grzergorz,
I've been reading of this thing of "write the same stuff using just a
few lines, not like in java" all over in the last two years, and I
tested it out using a large number of these languages, from Python to
Ruby to Scala, and I can assure you that it is mostly FALSE.
I don't know Python enough to formulate any strong claims but it looks to me that Python, Ruby and
Scala does not have feature "lazy evaluation". I consider this feature as one the most important if
IMHO if you try a language without it then you are playing with not a pure (fully) functional
languages. This leads to different conclusions and experience, obviously.

Actually, the whole claim about the number of lines of code was more to spur a discussion than a
real argument. I'm sure that everyone would stop reading my mail as soon as I would start talking
about how mathematical models can be very easily expressed in functional languages or how we can
easily _reason_ on functional statements. This all results in better code but I didn't wanted to
write an e-mail full of details that nobody would read.
Post by Simone Gianni
On one side, surely Java IS a verbose language, and surely there can be
more concise ones, but the entire idea of line counting is an error. I
can pretty well write Xalan in a single line of Java code, it's just a
matter of executing s/\n// on the whole source code :) :)
Have a look at the code of that processor, it's readable, really.
Post by Simone Gianni
- Many tools out there (CLOC just to mention one) consider also the
closing bracket a line of code, while obviously it is not.
- Using chaining (like A.b().c().d().e().f()) will reduce 5 "lines of
code" to one, but in reality you are always writing 5 calls .. same
amount of headache and possible bugs, or even more cause your code is
less readable.
Of course, you can play tricks or you can have sexy syntax so you get less lines of code. However,
can you think of a syntax that is readable and compresses your code by factor of 100?

What I wanted to say using argument of LoC is that it looks like functional languages lets you to
express the essential idea leaving out the details. Functional languages operate on a different
level of abstraction. This is something different than having 5 methods calls in one line or
declaring or not getters and setters for a object's field for example.
Post by Simone Gianni
Also considering a better metric, like the number of join points or
branches or whatever else, there are a number of reasons why these
- Many of these languages have huge libraries, with hundreds of methods
that accomplish most tasks that would require you to write lines of code
in java. This is not a bad thing in itself, but to make an appropriate
count of lines of code you should put all these stuff in a separate
library (commons is there for this reason), and see how many "lines of
code" are present in your CORE code.
If there is a core library that can be useful for every application and reduces size of your code so
much then it only proves the power of expressiveness of the language in which such a library has
been implemented.
Post by Simone Gianni
- Most of these libraries are not customizable in any way, they do work
perfectly 90% of times which is good, but you will end up having to
re-implement part of these. Java went the opposite way : the bare
minimum on the common library, no facades except where really really
useful, which will require a lot of code from the programmer. None of
the two is the perfect way, both have drawbacks.
I have lesser practical experience with libraries from functional languages but up to know I have
seen only extremely generic libraries in Haskell. They are so generic that you cannot compare then
to Java mainly because they are just higher-order functions.
Post by Simone Gianni
- Many of these libraries are tiny in number of lines because they are
... They don't implement what they claim to completely, or implement an
early version of it, partially and in a buggy way.
... Have not gone thru the pain of adding all the features users will
ask you to add, which can make a simple one-man-show library grow up to
thousands of hundreds of lines in a few years.
... Have not gone thru any test or bugfixing, and bugfixing WILL
ENORMOUSLY increase the "size" of code (and also make it a mess).
I wholeheartedly disagree with the last statement. I've written lots of code in Java which has been
buggy and you can easily point your finger at the very specific line of code where the particular
bug has been made and this way prove that it was entirely my fault.

I don't want to dismiss that simple fact but I do bring into question if it's not a tool (Java) that
makes it too easy for me to make simple bugs. These days it's rather common saying that if you write
a big application in Java you have to cover it with both test-cases and integration tests in order
to avoid obscure bugs and long debugging sessions. I was the one saying the same, actually.

However, I started to realize that this approach seems to be broken to some extent. In test-case you
execute actions that are meant to check whether your code follows the behaviour you intended to
describe in original code.

What about a language that is precise and abstract enough that lets you describe what it should
really do (read what you really mean) instead of what kind of actions it should perform? What about
a language that is immune to most of simple bugs in code we make because it simply does not operate
at level were this bugs are made?


I happen to attend lectures on mathematical logic and subject called "Languages, Automata and
Computations" which give me lots of insights into the subject we are discussing. Even if my
understanding of the subject is at introductory level I've got more and more reasons to think that
languages can be powerful enough to express your needs so precisely that unit testing and similar
surrogates are not needed in most situations. This is only heuristic claim based on some theorems
I've learned, though.
Post by Simone Gianni
... Usually does not have all the fluff around the basic core, like
utilities, error messages, handling of special cases or exceptions, and
so on ... that will also make your code multiply in size.
Actually the XSLT processor follows specification when it comes to error reporting. Anyway, you are
right that in general all boring details make our code bigger but still not 100 times bigger or so...
Post by Simone Gianni
Obviously, there are languages which are easier than Java, more concise,
more performant and all the rest, functional approach is easier than
passing Runnables, there are no doubt about the fact that our industry
is young and there is huge space for new technologies, and probably
Cocoon would greatly benefit from some of them.
Yep, that's my whole idea. This community used to be very innovate (maybe not so good at marketing
but we all know that already) and I would like to put at least some parts of Cocoon at bleeding edge
again.

Neither I'm a salesman trying to sell you a hype nor I feel like a chosen one to change a world of
programming. I simply believe that Cocoon community would benefit from a little bit of functional
programming.
Post by Simone Gianni
But take these revolutionary claims for what they are : propaganda, not
necessarily real facts, or at least not THAT MUCH as they try to
demonstrate.
Actually, as I've already said I've cited such claims to spur a discussion and I have more deep
insights into whole subject. Anyway, we both understand that nobody here wants to listen to a _very_
abstract talk on language theory that would support my current interests and the whole excitement
about them.

Moreover, I take into account that I might be simply wrong and there is no added value coming with
functional languages. However, we'll never know until we experiment with some real world
application. Cocoon's reimplementation looks like a perfect chance and here I simply ask if others
are interested in experimenting.


PS. Thanks for your comments Simone. It's been a long time since we talked last time!
--
Best regards,
Grzegorz Kossakowski
r***@dds.nl
2008-11-21 08:50:11 UTC
Permalink
Post by Grzegorz Kossakowski
Another side-note: I observe that we have a number of "badly needed
to-be-done" tasks but there is a
constantly decreasing number of people willing to take care of them.
This leads me personally to a
question about the future of this community.
--
(worried)
Grzegorz Kossakowski
I'd be happy to pitch in, but I should warn you that I'm fairly new to
Cocoon (so some initial help would be much appreciated).

Is there a (prioritized) list of bugs/feature requests somewhere?

Regards,

Martin
David Crossley
2008-11-25 00:24:56 UTC
Permalink
Post by r***@dds.nl
Post by Grzegorz Kossakowski
Another side-note: I observe that we have a number of "badly needed
to-be-done" tasks but there is a
constantly decreasing number of people willing to take care of them.
This leads me personally to a question about the future of this community.
I'd be happy to pitch in, but I should warn you that I'm fairly new to
Cocoon (so some initial help would be much appreciated).
Is there a (prioritized) list of bugs/feature requests somewhere?
Thanks, i think that Grek and Jasha were talking about
project management type tasks. For most of these, only the
Cocoon PMC members have the wherewithal to carry them out.

As a developer, you can certainly help in other areas.

One thing is to generally browse our issue tracker and see
what takes your interest. Perhaps fix some, comment on others.
These changes are alerted to this dev@ mail list, which might
spark the interest of others.
https://issues.apache.org/jira/browse/COCOON

Another would be to try the examples on the zone server.
Create issues for anything that needs attention.
http://cocoon.zones.apache.org/

-David
Post by r***@dds.nl
Regards,
Martin
Grzegorz Kossakowski
2008-11-25 11:52:31 UTC
Permalink
Post by David Crossley
Thanks, i think that Grek and Jasha were talking about
project management type tasks. For most of these, only the
Cocoon PMC members have the wherewithal to carry them out.
David, you are generally right but there are some tasks that are crossing boundaries like this one:
http://article.gmane.org/gmane.text.xml.cocoon.devel/79044

Our samples are down due to some bug in Maven which seems to be more or less already identified. The
task is to contact Maven developers, report them this bug and maybe cooperate on fixing it.
Meanwhile, some ugly work-around should be introduced on our zone.

The first part of this task does not require any special rights. Anyone can pick this up.
Post by David Crossley
As a developer, you can certainly help in other areas.
One thing is to generally browse our issue tracker and see
what takes your interest. Perhaps fix some, comment on others.
spark the interest of others.
https://issues.apache.org/jira/browse/COCOON
Maybe I'm speaking too much from my own position but I believe that the most urgent issue is this:
http://article.gmane.org/gmane.text.xml.cocoon.devel/79192

Why I think it's so important:
1. Any multi-thread processing of a request is completely broken.
2. This blocks last step of introduction of unified expressions into Cocoon (notably into sitemap)
and deprecating a big portion of old code.

Actually, this issue and the fact that I cannot fix it makes me so ashamed that I've lost any
motivation to work on anything related to Cocoon.
Post by David Crossley
Another would be to try the examples on the zone server.
Create issues for anything that needs attention.
http://cocoon.zones.apache.org/
Yes, this is for someone that wants something easier to work on.

Another very important thing is helping Jeremy with Dojo migration:
http://article.gmane.org/gmane.text.xml.cocoon.devel/78940

Unfortunately, I don't have a time to provide any valuable in-depth feedback at the moment.
--
Grzegorz Kossakowski
Continue reading on narkive:
Loading...