You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/07/31 15:27:19 UTC
[Proposal] Cocoon Organization
Currently Cocoon is 1.5 MB in size. That is a huge jar. In Cocoon
there
are the core files, the servlet compatibility files, the CLI
compatibility
files, and hundreds of components.
The fact that we as a community are thriving is excellent. However, as
a
project, Cocoon is feeling quite heavy. Esp. since there are features
in
Cocoon that not everyone needs. I proposed this a while back, but I am
going to propose it again.
We should split Cocoon into core development and component development
efforts, much like Avalon does with Framework and Excalibur. That will
allow the components to be packaged in jars that serve a similar
purpose.
Things like all the database related components should be in their own
mini-project. Each mini-project has its own documentation, and its own
life. It also allows each mini-project to determine whether it is ready
for prime-time or not. At every release, the core cocoon does not have
to worry about which components it has to move into scratchpad. Also
each set of components has a little focused mini-community so the docs
get upgraded in a focused manner.
I have already seen the benefits of how this works in Excalibur--now
that
we are going through systematically.
When I am generating a site, I don't want to have to include the portal
components or the DB and auth components. Those don't need to be there
for the site.
Keep in mind that the mini-projects are all part of the cocoon umbrella,
and they foster functioning communities within the larger Cocoon
community,
not detract from it.
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>Yes, you may use only one or two. But think about it: right now there is
>no one, commonly shared syntax for these two (esql and transformer), and
>they have no common roots, they are not well integrated.
>
>If you to put esql and sql transformer into different subprojects, then
>situation will just get worse. They must be in the same subproject, and
>should be unified and integrated as much as possible, to reduce
>repetitive code and make maintainance / feature additions easy.
>
>
>IIRC, somebody (Andrew?) was about to integrate these two.
>
>
Yes I plan to. Its on the task list.
>Vadim
>
>
>
>
>
>>So, I reckon it boils down to someone with a good overview to suggest
>>the grouping scheme and prepare a layout. I would hope that everyone
>>would move the stuff they feel responsible for to the appropriate
>>location.
>>
>> Chris.
>>--
>>C h r i s t i a n H a u l
>>haul@informatik.tu-darmstadt.de
>> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by "Andrew C. Oliver" <ac...@apache.org>.
This sounds like it could be an undue burden on the users. I think what
really needs to be done
is an improvement in the build system. Something more aken to the Linux
"MenuConfig" or "XConfig"
rather than try and break the project up at this point.
I think what will probably happen is it will become a tremendous pain
for users to get it all
working together. And eventually there will be "distributions" of
sorts. If you're sure thats
what you really want.... Thats fine, but plan the distributions up front
instead of having those
years of meandering that Linux et al had when it was a royal pain to set
up (pre-REAL distributions). The only way it
was secure was that no script kiddies could run it either ;-)
If Cocoon wants to do the same. Avalon is a bad pattern to follow as no
one outside of avalon understands the various
pieces either.
-Andy
>
>I was thinking at least along the lines of required libraries.
>Therefore since all the database related stuff requires a
>DB driver library, then all the DB stuff would be in one
>subproject. I.e. ESQL and SQLTransformer would live together.
>
>
>Using that line of thought, The PDF/PNG generation would go
>into a "graphical" package (i.e. the output stream is not
>a form of text like XML/HTML). FOP uses Batik, so they are
>somewhat required to be together.
>
>Here is my stab at the separation (and I don't have the full
>list of components either):
>
>database: All DB related actions/transformers/generators/readers/
> logicsheets/etc.
>
>graphical: FOP & Batik related stuff
>
>portal: All the sun* stuff
>
>forms: All the form validation/processing tools
>
>
>Essentially, we need to break down the jar file dependency graph,
>and use that as a starting point. If a jar file is required by
>another jar file (like FOP needs Batik), they should be grouped
>together along with all their associated Cocoon components.
>
>Keep in mind that separating the back end from the front end
>(i.e. the servlet/environment files and the cli/environment
>files) we can have a centrally installed Cocoon and several
>[much] lighter weight WAR files that use Cocoon. But that's
>only what I like.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal] Cocoon Organization
Posted by Berin Loritsch <bl...@apache.org>.
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>
> > From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
> >
> > On 31.Jul.2002 -- 09:27 AM, Berin Loritsch wrote:
> > > We should split Cocoon into core development and component
> development
> > > efforts, much like Avalon does with Framework and Excalibur. That
> will
> > > allow the components to be packaged in jars that serve a similar
> > > purpose.
> >
> > In general, I agree. But I fear that many functional
> subprojects are
> > too small to be handled seperately.
> >
> > > Things like all the database related components should be in their
> own
> > > mini-project. Each mini-project has its own
> documentation, and its
> own
> >
> > Which is a good example: We have ESQL (depends on XSP),
> > SQLTransformer, and two sets of Database*Actions. Putting
> all in one
> > subproject could be done. But from the deployment
> perspective, I would
> > perhaps use one or two, hardly all of them.
>
> Yes, you may use only one or two. But think about it: right
> now there is no one, commonly shared syntax for these two
> (esql and transformer), and they have no common roots, they
> are not well integrated.
>
> If you to put esql and sql transformer into different
> subprojects, then situation will just get worse. They must be
> in the same subproject, and should be unified and integrated
> as much as possible, to reduce repetitive code and make
> maintainance / feature additions easy.
>
>
> IIRC, somebody (Andrew?) was about to integrate these two.
I was thinking at least along the lines of required libraries.
Therefore since all the database related stuff requires a
DB driver library, then all the DB stuff would be in one
subproject. I.e. ESQL and SQLTransformer would live together.
Using that line of thought, The PDF/PNG generation would go
into a "graphical" package (i.e. the output stream is not
a form of text like XML/HTML). FOP uses Batik, so they are
somewhat required to be together.
Here is my stab at the separation (and I don't have the full
list of components either):
database: All DB related actions/transformers/generators/readers/
logicsheets/etc.
graphical: FOP & Batik related stuff
portal: All the sun* stuff
forms: All the form validation/processing tools
Essentially, we need to break down the jar file dependency graph,
and use that as a starting point. If a jar file is required by
another jar file (like FOP needs Batik), they should be grouped
together along with all their associated Cocoon components.
Keep in mind that separating the back end from the front end
(i.e. the servlet/environment files and the cli/environment
files) we can have a centrally installed Cocoon and several
[much] lighter weight WAR files that use Cocoon. But that's
only what I like.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal] Cocoon Organization
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> On 31.Jul.2002 -- 09:27 AM, Berin Loritsch wrote:
> > We should split Cocoon into core development and component
development
> > efforts, much like Avalon does with Framework and Excalibur. That
will
> > allow the components to be packaged in jars that serve a similar
> > purpose.
>
> In general, I agree. But I fear that many functional subprojects are
> too small to be handled seperately.
>
> > Things like all the database related components should be in their
own
> > mini-project. Each mini-project has its own documentation, and its
own
>
> Which is a good example: We have ESQL (depends on XSP),
> SQLTransformer, and two sets of Database*Actions. Putting all in one
> subproject could be done. But from the deployment perspective, I would
> perhaps use one or two, hardly all of them.
Yes, you may use only one or two. But think about it: right now there is
no one, commonly shared syntax for these two (esql and transformer), and
they have no common roots, they are not well integrated.
If you to put esql and sql transformer into different subprojects, then
situation will just get worse. They must be in the same subproject, and
should be unified and integrated as much as possible, to reduce
repetitive code and make maintainance / feature additions easy.
IIRC, somebody (Andrew?) was about to integrate these two.
Vadim
> So, I reckon it boils down to someone with a good overview to suggest
> the grouping scheme and prepare a layout. I would hope that everyone
> would move the stuff they feel responsible for to the appropriate
> location.
>
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 31.Jul.2002 -- 09:27 AM, Berin Loritsch wrote:
> We should split Cocoon into core development and component development
> efforts, much like Avalon does with Framework and Excalibur. That will
> allow the components to be packaged in jars that serve a similar
> purpose.
In general, I agree. But I fear that many functional subprojects are
too small to be handled seperately.
> Things like all the database related components should be in their own
> mini-project. Each mini-project has its own documentation, and its own
Which is a good example: We have ESQL (depends on XSP),
SQLTransformer, and two sets of Database*Actions. Putting all in one
subproject could be done. But from the deployment perspective, I would
perhaps use one or two, hardly all of them.
So, I reckon it boils down to someone with a good overview to suggest
the grouping scheme and prepare a layout. I would hope that everyone
would move the stuff they feel responsible for to the appropriate
location.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal] Cocoon Organization
Posted by Berin Loritsch <bl...@apache.org>.
> From: Ross Gardler [mailto:rgardler@wkwyw.net]
>
> Gianugo Rabellino wrote:
>
> > Berin Loritsch wrote:
> >
> >> We should split Cocoon into core development and component
> >> development efforts, much like Avalon does with Framework and
> >> Excalibur. That will allow the components to be packaged in jars
> >> that serve a similar purpose.
> >
> >
> > Yes, +1, go for it, hippy-ya-ye-o! This is badly needed.
>
>
> How does this relate to the Cocoon Blocks idea? (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=1025283980163
25&w=2 for
start of thread). It strikes me that there is a certain amount of
overlap between these two activities.
There is.
Blocks are their own entity, which is good. They have their own
natural boundaries. However, there is a sizeable number of other
entities that could stand to be grouped together, that don't
necessarily fit into the block concept.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by Ross Gardler <rg...@wkwyw.net>.
Gianugo Rabellino wrote:
> Berin Loritsch wrote:
>
>> We should split Cocoon into core development and component development
>> efforts, much like Avalon does with Framework and Excalibur. That will
>> allow the components to be packaged in jars that serve a similar
>> purpose.
>
>
> Yes, +1, go for it, hippy-ya-ye-o! This is badly needed.
How does this relate to the Cocoon Blocks idea? (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102528398016325&w=2 for
start of thread). It strikes me that there is a certain amount of
overlap between these two activities.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal] Cocoon Organization
Posted by Berin Loritsch <bl...@apache.org>.
> From: Gianugo Rabellino [mailto:gianugo@apache.org]
>
> Berin Loritsch wrote:
>
> > We should split Cocoon into core development and component
> development
> > efforts, much like Avalon does with Framework and Excalibur. That
> > will allow the components to be packaged in jars that serve
> a similar
> > purpose.
>
> Yes, +1, go for it, hippy-ya-ye-o! This is badly needed.
>
> The problem is how to split actually. Based on functionality (i.e
> cocoon-sql.jar, cocoon-xmldb.jar, cocoon-ldap.jar), by Cocoon role
> (cocoon-generators.jar, cocoon-actions.jar), by status
> (cocoon-stable.jar, cocoon-scratchpad.jar, cocoon-beta.jar)
> or by what?
>
> It doesn't seem to me an easy task, but someone has to do it...
I would split based on function. The difficult part is getting the
split started. The Portal stuff (sun***) is an easy thing to separate
out. Once it is done, people will start thinking about what seems
natural, and it will organize itself. (provided the people are
intelligent as I suspect the Cocoon community is).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Konstantin Piroumian wrote:
>An alternative proposal:
> - Cocoon 2 Micro Edition (C2ME): basic functionality/components
> - Cocoon 2 Standard Edition (C2SE): most frequently used
>functionality/components
> - Cocoon 2 Enterprise Edition (C2EE): complete suit, including flow
>control, form handling, DB-stuff, etc.
>
>
dunno about that...smells like sun's crappy scheme...then again...it
sells. . . . (thats no indication of
quality)
>But this does not require any sub-projects, but a more sophisticated build.
>
>I don't think that development of Cocoon itself will be any easier if it'll
>be split into subprojects. How would you syncronize all of them? Are there
>any really big parts that can be separated and developed independently?..
>
>
Completely agree with that!
-Andy
>Konstantin
>
>From: "Leo Sutic" <le...@inspireinfrastructure.com>
>
>
>>
>>
>>>From: Gianugo Rabellino [mailto:gianugo@apache.org]
>>>
>>>Berin Loritsch wrote:
>>>
>>>
>>>
>>>>We should split Cocoon into core development and component
>>>>
>>>>
>>>development
>>>
>>>
>>>>efforts, much like Avalon does with Framework and Excalibur. That
>>>>will allow the components to be packaged in jars that serve
>>>>
>>>>
>>>a similar
>>>
>>>
>>>>purpose.
>>>>
>>>>
>>>Yes, +1, go for it, hippy-ya-ye-o! This is badly needed.
>>>
>>>The problem is how to split actually. Based on functionality (i.e
>>>cocoon-sql.jar, cocoon-xmldb.jar, cocoon-ldap.jar), by Cocoon role
>>>(cocoon-generators.jar, cocoon-actions.jar), by status
>>>(cocoon-stable.jar, cocoon-scratchpad.jar, cocoon-beta.jar)
>>>or by what?
>>>
>>>
>>By functionality and status:
>>
>>cocoon-sql.jar
>>cocoon-sql-scratchpad.jar
>>cocoon.jar
>>cocoon-scratchpad.jar
>>.
>>.
>>.
>>
>>I agree, it is a big job... But *badly* needed.
>>
>>/LS
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by Konstantin Piroumian <KP...@protek.com>.
An alternative proposal:
- Cocoon 2 Micro Edition (C2ME): basic functionality/components
- Cocoon 2 Standard Edition (C2SE): most frequently used
functionality/components
- Cocoon 2 Enterprise Edition (C2EE): complete suit, including flow
control, form handling, DB-stuff, etc.
But this does not require any sub-projects, but a more sophisticated build.
I don't think that development of Cocoon itself will be any easier if it'll
be split into subprojects. How would you syncronize all of them? Are there
any really big parts that can be separated and developed independently?..
Konstantin
From: "Leo Sutic" <le...@inspireinfrastructure.com>
>
>
> > From: Gianugo Rabellino [mailto:gianugo@apache.org]
> >
> > Berin Loritsch wrote:
> >
> > > We should split Cocoon into core development and component
> > development
> > > efforts, much like Avalon does with Framework and Excalibur. That
> > > will allow the components to be packaged in jars that serve
> > a similar
> > > purpose.
> >
> > Yes, +1, go for it, hippy-ya-ye-o! This is badly needed.
> >
> > The problem is how to split actually. Based on functionality (i.e
> > cocoon-sql.jar, cocoon-xmldb.jar, cocoon-ldap.jar), by Cocoon role
> > (cocoon-generators.jar, cocoon-actions.jar), by status
> > (cocoon-stable.jar, cocoon-scratchpad.jar, cocoon-beta.jar)
> > or by what?
>
> By functionality and status:
>
> cocoon-sql.jar
> cocoon-sql-scratchpad.jar
> cocoon.jar
> cocoon-scratchpad.jar
> .
> .
> .
>
> I agree, it is a big job... But *badly* needed.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal] Cocoon Organization
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Gianugo Rabellino [mailto:gianugo@apache.org]
>
> Berin Loritsch wrote:
>
> > We should split Cocoon into core development and component
> development
> > efforts, much like Avalon does with Framework and Excalibur. That
> > will allow the components to be packaged in jars that serve
> a similar
> > purpose.
>
> Yes, +1, go for it, hippy-ya-ye-o! This is badly needed.
>
> The problem is how to split actually. Based on functionality (i.e
> cocoon-sql.jar, cocoon-xmldb.jar, cocoon-ldap.jar), by Cocoon role
> (cocoon-generators.jar, cocoon-actions.jar), by status
> (cocoon-stable.jar, cocoon-scratchpad.jar, cocoon-beta.jar)
> or by what?
By functionality and status:
cocoon-sql.jar
cocoon-sql-scratchpad.jar
cocoon.jar
cocoon-scratchpad.jar
.
.
.
I agree, it is a big job... But *badly* needed.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by Gianugo Rabellino <gi...@apache.org>.
Berin Loritsch wrote:
> We should split Cocoon into core development and component development
> efforts, much like Avalon does with Framework and Excalibur. That will
> allow the components to be packaged in jars that serve a similar
> purpose.
Yes, +1, go for it, hippy-ya-ye-o! This is badly needed.
The problem is how to split actually. Based on functionality (i.e
cocoon-sql.jar, cocoon-xmldb.jar, cocoon-ldap.jar), by Cocoon role
(cocoon-generators.jar, cocoon-actions.jar), by status
(cocoon-stable.jar, cocoon-scratchpad.jar, cocoon-beta.jar) or by what?
It doesn't seem to me an easy task, but someone has to do it...
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>> And one final note:
>> Just do a simple performance test: create a pipeline reading an xml file
>> transform this in two steps with two xslt transformers and serialize it
>> to html (or xml if you want). Do a stress test on the same machine
>> using Cocoon 2.0, 2.0.1, 2.0.2, 2.0.3 and 2.1-dev. (I don't know
>> the answer to this test, but I would bet a book on the result).
>
>
> Or compare Cocoon CLI versus Anakia ;-)
+1!!!
>
>> So, whew, you see I had some time to prepare this email...and now
>> the flame-war can begin...
>>
>> But summarizing this: +1 on Berins idea.
>
>
> +1
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
...
> Now I think we really did some mistakes (and yes, this again includes
> myself).
I don't think that anyone did mistakes, because there was no mechanism
for adding features in Cocoon without making it part of the monolithis
system.
You /could/ have discussed the integration architecture first, but I
doubt it would have been effective.
Now we see the need to make it even better, and this is cool :-)
> But let's come back, to what we can do.
> First of all, a feature stop! I don't mean an RT stop.
.Yes, let's start doing this block thing.
> Second, thinking of SoC (ok, perhaps not the right context to use this
> term) - we should try to build a minimal Cocoon or core Cocoon if you prefer
> and put everything else into additional modules (read: not blocks). By
> modules I simply mean different directories in the CVS in order to
> optionally build them. Let's remove the authentication framework from the
> core, the form handling, the input modules, the flow map, the fop serializer
> etc - simply everything which is not necessary to run Cocoon.
+1
> Third, let's identify the issues for the upcomming releases.
>
> Fourth, let's search for volunteers for the open issues, for bug fixing and
> for testing!
>
> Fifth, discuss the available patches and open RTs and make proposal
> documents out of them.
I think that doing 1 and 2 will take us quite a lot of time, and will be
very important.
> Or putting it in other words: Let's not forget the users needs over all
> this cool new features and RTs.
+1
...
> And one final note:
> Just do a simple performance test: create a pipeline reading an xml file
> transform this in two steps with two xslt transformers and serialize it
> to html (or xml if you want). Do a stress test on the same machine
> using Cocoon 2.0, 2.0.1, 2.0.2, 2.0.3 and 2.1-dev. (I don't know
> the answer to this test, but I would bet a book on the result).
Or compare Cocoon CLI versus Anakia ;-)
> So, whew, you see I had some time to prepare this email...and now
> the flame-war can begin...
>
> But summarizing this: +1 on Berins idea.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Amen! YES!
<snip/>
>Ok, I know, one answer to this will be, if you don't want to use blocks or
>flowmaps, you don't have to. But how does this work? Will we state: "Cocoon
>has
>the sitemap, flowmaps and blocks. But don't worry, if this is too
>complex for you, just use only the sitemap and forget about the others, you
>don't
>need them...". Well...
>
>
Not that my opinion should count, but I prefer starting with the easiest
solution first, which is creating a
more sophisticated build system, something that smells like the Linux
Kernel "menuconfig" or "xconfig".
>So what can we do about it? Try to act more like a team and let's more
>listening
>to the user needs. The documentation effort is one step in this direction,
>but
>personally I think there is a problem there, too. New documentation features
>are currently delayed until forrest is ready! So, instead of focusing on the
>real problem, a new construction area has been build up (forrest) which has
>to be
>completed beforehand! This is not very helpfull.
>
>
This is what I call Cocoon Syndrome. Someone says "documentation" and
10 people pipe in on all the
cool tools they'll write to do documentation but no one generates any.
Lets talk about probable effort:
1. Creation of documentation
65%
2. Creation of forrest
30%
3. Conversion of docmentation to work with forrest. 5%
So I dare say holding up the 65% until you complete the 30% so that you
can save on the 5% is probably errant logic.
<snip/>
>Second, thinking of SoC (ok, perhaps not the right context to use this
>term) - we should try to build a minimal Cocoon or core Cocoon if you prefer
>and put everything else into additional modules (read: not blocks). By
>modules I simply mean different directories in the CVS in order to
>optionally build them. Let's remove the authentication framework from the
>core, the form handling, the input modules, the flow map, the fop serializer
>etc - simply everything which is not necessary to run Cocoon.
>
>
BUT NOT seperate CVS "Modules" I hope! That would be a PAIN. (speaking
both as a user and someone
who occasionally hacks cocoon). Not trying to be pedantic with the
verbage but whoooo. Having everything
in its own module would hurt!
>Third, let's identify the issues for the upcomming releases.
>
>
+1
>Fourth, let's search for volunteers for the open issues, for bug fixing and
>for testing!
>
>
+1
>Fifth, discuss the available patches and open RTs and make proposal
>documents out of them.
>
>
+1
>Or putting it in other words: Let's not forget the users needs over all
>this cool new features and RTs.
>
>
+1
>Now, I'm pretty sure, that some might now stand up and say: "Hey, Carsten,
>you know what? Cocoon is open source, so if you see a need, you can
>contribute and fix it." Well, that's the individual approach we were
>following in the last months. And does it really work? Or someone will
>say "Hey, it's alpha, what do you expect?"...
>
>
+1 - Humble suggestion:
http://jakarta.apache.org/poi/plan/POI20Vision.html
We do this for each major release and have the committers sign off on
it, make sure they all contribute
to it.
>And one final note:
>Just do a simple performance test: create a pipeline reading an xml file
>transform this in two steps with two xslt transformers and serialize it
>to html (or xml if you want). Do a stress test on the same machine
>using Cocoon 2.0, 2.0.1, 2.0.2, 2.0.3 and 2.1-dev. (I don't know
>the answer to this test, but I would bet a book on the result).
>
>So, whew, you see I had some time to prepare this email...and now
>the flame-war can begin...
>
>But summarizing this: +1 on Berins idea.
>
>Carsten
>
>Berin Loritsch wrote:
>
>
>>Currently Cocoon is 1.5 MB in size. That is a huge jar. In Cocoon
>>there
>>are the core files, the servlet compatibility files, the CLI
>>compatibility
>>files, and hundreds of components.
>>
>>The fact that we as a community are thriving is excellent. However, as
>>a
>>project, Cocoon is feeling quite heavy. Esp. since there are features
>>in
>>Cocoon that not everyone needs. I proposed this a while back, but I am
>>going to propose it again.
>>
>>We should split Cocoon into core development and component development
>>efforts, much like Avalon does with Framework and Excalibur. That will
>>allow the components to be packaged in jars that serve a similar
>>purpose.
>>Things like all the database related components should be in their own
>>mini-project. Each mini-project has its own documentation, and its own
>>life. It also allows each mini-project to determine whether it is ready
>>for prime-time or not. At every release, the core cocoon does not have
>>to worry about which components it has to move into scratchpad. Also
>>each set of components has a little focused mini-community so the docs
>>get upgraded in a focused manner.
>>
>>I have already seen the benefits of how this works in Excalibur--now
>>that
>>we are going through systematically.
>>
>>When I am generating a site, I don't want to have to include the portal
>>components or the DB and auth components. Those don't need to be there
>>for the site.
>>
>>Keep in mind that the mini-projects are all part of the cocoon umbrella,
>>and they foster functioning communities within the larger Cocoon
>>community,
>>not detract from it.
>>
>>
>>"They that give up essential liberty to obtain a little temporary safety
>> deserve neither liberty nor safety."
>> - Benjamin Franklin
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Aren't we talking about Cocoon Blocks? (was: [Proposal] Cocoon Organization (Cocoon plugins))
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote
>
> > Can't help it, but this sounds like Cocoon Blocks "light" to me. And
> > then there is the question why not going all the way and implement
> > Blocks as outlined by the RT of Stefano ?
> >
>
> Yes, my opinion too! After following the thread I think that all
> the points
> discussed are the same as in the COB thread. Maybe this is a good starting
> point for the realization of Stefano's great concept of COBs!!!
>
I don't think that we are talking here about blocks - at least not
the way the proposal explained. Again, I don't believe that we get I
more handable Cocoon by just adding a new complexity layer.
And I still believe that adding blocks to Cocoon makes Cocoon even
slower as the 2.1-dev version currently is.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Aren't we talking about Cocoon Blocks? (was: [Proposal] Cocoon Organization (Cocoon plugins))
Posted by re...@gmx.net.
> Can't help it, but this sounds like Cocoon Blocks "light" to me. And
> then there is the question why not going all the way and implement
> Blocks as outlined by the RT of Stefano ?
>
Yes, my opinion too! After following the thread I think that all the points
discussed are the same as in the COB thread. Maybe this is a good starting
point for the realization of Stefano's great concept of COBs!!!
Regards,
Reinhard
>
>
> Jens
>
> --
>
> jens.lorenz at interface-projects dot de
>
> interface:projects GmbH \\|//
> Tolkewitzer Strasse 49 (o o)
> 01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
> Germany
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization (Cocoon plugins)
Posted by Jens Lorenz <je...@interface-projects.de>.
----- Original Message -----
From: "Bertrand Delacretaz" <bd...@codeconsult.ch>
To: <co...@xml.apache.org>
Sent: Monday, August 05, 2002 12:05 PM
Subject: Re: [Proposal] Cocoon Organization (Cocoon plugins)
> On Monday 05 August 2002 09:41, Carsten Ziegeler wrote:
> >. . .
> > we should try to build a minimal Cocoon or core Cocoon if you
> > prefer and put everything else into additional modules (read: not
blocks).
> > By modules I simply mean different directories in the CVS in order to
> > optionally build them.
> >. . .
>
> It would be great if these modules could be pluggable at runtime, simply
by
> copying the required jars in the right places. Users won't like having
to
> recompile Cocoon just to activate different options IMHO.
>
> I don't know Cocoon internals or Avalon in much detail, but maybe the
> following scenario could be implemented simply and help users locate and
add
> the required functionality when they need it:
>
> 1) create an XML map of modules, classnames and URLs that is distributed
with
> Cocoon, example:
>
> <plugin-module
> name="xslt-xalan"
> class="org.apache.cocooon.wrappers.XalanWrapper"
> download-url="http://xml.apache.org/cocoon/dist/modules/xalan"
> download-file="cocoon-xalan-plugin.2.0.3.jar"
> />
>
> 2) when a Component is requested from the Sitemap and is not available,
a
> custom ClassLoader (or a catch of the ClassNotFoundException) uses the
> above map to let users know how to activate it, something like:
>
> CocoonPluginNotFoundException:
> The "xslt-xalan" plugin (requested by blablabla...) is not present in
your
> Cocoon configuration. To activate it, download file
> "cocoon-xalan-plugin.2.0.3.jar" from
> "http://xml.apache.org/cocoon/dist/modules/xalan", copy this jar to the
> WEB-INF/lib subdirectory of your Cocoon installation and restart Cocoon
>
> I don't know how well this fits your plans, but it might help
distributing a
> minimal Cooon while making it easy for users to install what they need.
>
> Just my 2 cents.
> --
> Bertrand Delacrétaz (codeconsult.ch, jfor.org)
>
> buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
> disclaimer: eternity is very long. mostly towards the end. get ready.
>
Can't help it, but this sounds like Cocoon Blocks "light" to me. And
then there is the question why not going all the way and implement
Blocks as outlined by the RT of Stefano ?
Jens
--
jens.lorenz at interface-projects dot de
interface:projects GmbH \\|//
Tolkewitzer Strasse 49 (o o)
01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Ugo Cei <u....@cbim.it>.
Ugo Cei wrote:
> Nicola Ken Barozzi wrote:
>
> <snip/>
>
> http://www.dictionary.com/search?q=coon
>
> 2. Offensive Slang. Used as a disparaging term for a Black person.
>
> Quindi qualcuno potrebbe interpretare CLEANCOON come "negraccio pulito"
> ;-).
>
> Ugo
>
Sorry, this was meant as a private message, but I forgot about the
Reply-To: header.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
> Cocoon may be the best thing since sliced bread, but nobody's going
> to put their fingers anywhere near it whilst it's still being sliced.
+1
>
> Stuart.
>
>
> On Monday, August 5, 2002, at 07:38 pm, Torsten Curdt wrote:
>
>> On Monday 05 August 2002 19:40, Berin Loritsch wrote:
>>
>>>> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>>>>
>>>> That being said... I grew up in "the south" and would not
>>>> have thought
>>>> of this meaning in this context.
>>>>
>>> :)
>>>
>>> Yes, but Ugo did. Someone else may.
>>>
>>>
>>> Really, I didn't have that picture in my head, but Ugo's
>>> comment jogged my memory.
>>>
>>> Anyhoo, I have been having a mild itch to completely refactor
>>> Cocoon and call it C4 (more for the explosive reference than
>>> for the Cocoon evolutionary reference). However, it has not
>>> been itching enough for me to do anything about it.
>>
>>
>> feeling the same itch...
>>
>> ...it would be really cool to at least collect some ideas and write
>> them down
>> somewhere. Not even discuss them... (it might set the wrong signals)
>> but just
>> marking down the itches we found while using and improving cocoon2.
>>
>> In the end it might give us a better starting point for C3/C4. Or we
>> end up
>> fixing all this in C2. (although I am a friend of rewrites)
>> --
>> Torsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
> Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck
> (Adolos)
> Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD
> 65AF
> ------------------------------------------------------------------------
> -
> Stuart Roebuck
> stuart.roebuck@adolos.com
> Systems Architect Java, XML, MacOS X, XP,
> etc.
> ADOLOS
> <http://www.adolos.com/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Torsten Curdt <tc...@dff.st>.
On Tuesday 06 August 2002 00:58, Stuart Roebuck wrote:
> Okay, I wonder if it's time for me to poor water on the flames!
>
>
> * Cocoon 2.0.3 has some problems with it that need fixing.
>
> * Cocoon 2.1 hasn't been released yet.
>
> * We have three books coming out this year, presumably based around
> Cocoon 2.0.x, or maybe around 2.1.some-months-ago.
>
> * There's still isn't adequate documentation for 2.0.x.
>
> * There's a whole bundle of software running 'out there' based on
> Cocoon 1.x and 2.0.x that relies on any number of the existing
> 'unstable' APIs in Cocoon.
...even on an early HEAD version after the 2.0.x branch ;-)
> And now we're talking about refactoring everything.
I guess we are not... I am quite sure everyone here will agree that we should
delay such idea until we have a real stable and well documented 2.1 branch!
People will walk off screaming if now start with another version...
...but what we need are people using it - not running away from it. We already
give them the burden of complexity...
But I am quite sure some people on cocoon-dev felt the same itch Berin was
talking about. I would insist on marking down those itches because that's the
way we find the needed improvements - whether they make it into the 2.x
branch or into a much later(?!) refactored version.
At least that's how I see it...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 06.Aug.2002 -- 09:30 AM, Stephan Michels wrote:
>
> On Tue, 6 Aug 2002, Carsten Ziegeler wrote:
> > Actually this is a maintainance nightmare, Often new features were added
> > and the build system (or the optional checks) were not added accurately.
> > The build.xml is getting bigger and bigger. By separating this into
> > directories this will be IMHO much cleaner and easier.
>
> How should this look like?
>
> src/java/org/apache/cocoon/modules/forms/components/*
> src/java/org/apache/cocoon/modules/forms/generation/*
> src/webapp/samples/forms/*
>
> src/java/org/apache/cocoon/modules/fop/components/*
> src/java/org/apache/cocoon/modules/fop/serialization/*
> src/webapp/samples/fop/*
> etc.
>
> Like this? It is more cleaner, but I see directories, which owns only
> one class :-|
Guess that's the price to pay. It improves visibility a great deal
though :-) Ever tried to find all form handling classes and files?
Even for the simple form support it's almost a dozen! Now add XMLForm...
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 06.Aug.2002 -- 09:48 AM, Torsten Curdt wrote:
> <snip/>
>
> > I would suggest something like this:
> >
> > Core:
> > src/java/org/apache/cocoon/*
> >
> > FOP module:
> > src/modules/fop/build.xml
> > src/modules/fop/lib/*
> > src/modules/fop/java/org/apache/cocoon/serialization/*
> > src/modules/fop/java/org/apache/cocoon/components/*
> > src/modules/fop/samples/*
Just one minor point: we have already "components", "parts", and
"modules". We need yet another term for this. "block" is too much
associated with a much richer implementation although this might
evolve into "blocks".
But yes, we should keep the original package names and thus the
original directory structure.
Another point: This this won't break anything, we could do it for
2.0.4 as well and "mv" (unix: move) the files on
cvs.apache.org. Loosing cvs logs is a pitty and should be avoided.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
John Morrison wrote:
> The only thing I'm unsure about is
>
> src/java for core and
> src/modules for modules... wouldn't either
>
> src/java and src/java/modules or
> src/java/core with src/java/modules or
> src/core and src/modules be better?
>
Hmm, right, as we have more than just java code the last one
seems the best solution, or we could (I like adding more choices...):
src/... for the core
modules/ for (guess what)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by John Morrison <jo...@ntlworld.com>.
> <snip/>
>
> > I would suggest something like this:
> >
> > Core:
> > src/java/org/apache/cocoon/*
> >
> > FOP module:
> > src/modules/fop/build.xml
> > src/modules/fop/lib/*
> > src/modules/fop/java/org/apache/cocoon/serialization/*
> > src/modules/fop/java/org/apache/cocoon/components/*
> > src/modules/fop/samples/*
> >
> > etc.
The only thing I'm unsure about is
src/java for core and
src/modules for modules... wouldn't either
src/java and src/java/modules or
src/java/core with src/java/modules or
src/core and src/modules be better?
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> I would suggest something like this:
>
> Core:
> src/java/org/apache/cocoon/*
>
> FOP module:
> src/modules/fop/build.xml
> src/modules/fop/lib/*
> src/modules/fop/java/org/apache/cocoon/serialization/*
> src/modules/fop/java/org/apache/cocoon/components/*
> src/modules/fop/samples/*
>
> etc.
+1
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tuesday 06 August 2002 09:56, Stephan Michels wrote:
>. . .
> And want about the builded cocoon.jar. Does it includes all
> selected modules, or does we have a
> cocoon-core.jar
> cocoon-fop.jar
> cocoon-forms.jar
> etc. ?
>. . .
If there are several jars I think their names should include version numbers:
cocoon-core-2.0.3.jar
cocoon-forms-2.0.3.jar
. . .
to avoid version mismatches when installing/upgrading.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Stephan Michels <st...@apache.org>.
On Tue, 6 Aug 2002, Carsten Ziegeler wrote:
> Stephan Michels wrote:
> >
> > How should this look like?
> >
> > src/java/org/apache/cocoon/modules/forms/components/*
> > src/java/org/apache/cocoon/modules/forms/generation/*
> > src/webapp/samples/forms/*
> >
> > src/java/org/apache/cocoon/modules/fop/components/*
> > src/java/org/apache/cocoon/modules/fop/serialization/*
> > src/webapp/samples/fop/*
> > etc.
> >
> > Like this? It is more cleaner, but I see directories, which owns only
> > one class :-|
> >
> This is the compatibility burdon...
hmm I see ...
> I would suggest something like this:
>
> Core:
> src/java/org/apache/cocoon/*
When I we do such big reorganzation, I would prefer
src/core/java/org/apache/cocoon/*
src/core/lib/*
> FOP module:
> src/modules/fop/build.xml
> src/modules/fop/lib/*
> src/modules/fop/java/org/apache/cocoon/serialization/*
> src/modules/fop/java/org/apache/cocoon/components/*
> src/modules/fop/samples/*
Then we will have a similar build system like excalibur ;-)
I like this idea ;-) How about the scratchpad? Do we need this
anymore?
And want about the builded cocoon.jar. Does it includes all
selected modules, or does we have a
cocoon-core.jar
cocoon-fop.jar
cocoon-forms.jar
etc. ?
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephan Michels wrote:
>
> How should this look like?
>
> src/java/org/apache/cocoon/modules/forms/components/*
> src/java/org/apache/cocoon/modules/forms/generation/*
> src/webapp/samples/forms/*
>
> src/java/org/apache/cocoon/modules/fop/components/*
> src/java/org/apache/cocoon/modules/fop/serialization/*
> src/webapp/samples/fop/*
> etc.
>
> Like this? It is more cleaner, but I see directories, which owns only
> one class :-|
>
This is the compatibility burdon...
I would suggest something like this:
Core:
src/java/org/apache/cocoon/*
FOP module:
src/modules/fop/build.xml
src/modules/fop/lib/*
src/modules/fop/java/org/apache/cocoon/serialization/*
src/modules/fop/java/org/apache/cocoon/components/*
src/modules/fop/samples/*
etc.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Stephan Michels <st...@apache.org>.
On Tue, 6 Aug 2002, Carsten Ziegeler wrote:
> Stephan Michels wrote:
> >
> > On Tue, 6 Aug 2002, Christian Haul wrote:
> >
> > > On 06.Aug.2002 -- 08:32 AM, Carsten Ziegeler wrote:
> > > > So, *if* we vote on refactoring or starting a new Cocoon
> > > > major version, I'm definitly -1 on this.
> > > >
> > > > I still believe that we can solve some (perhaps not all)
> > > > problems simply by organizing our project structure and
> > > > by shifting our activities from "hacking new features"
> > > > to "making a more perfect solution".
> > >
> > > So, could we just come back to Berin's original idea, create some
> > > subdirectories based e.g. on functionality, move stuff to
> > > subdirectories if appropriate, and change the build process to include
> > > these subdirectories as we do with scratchpad?
> > >
> > > Step two could be to build seperate jars, step three to relax release
> > > cycles for sub-projects. No magic, no changing of any names, just
> > > re-packaging.
> > >
> > > Candidates so far:
> > >
> > > * forms (simple and XML)
> > > * databases (esql, transformer, actions)
> > > * fop
> > > * portal
> > >
> > > How about (in addition to the above):
> > >
> > > * delhi
> > > * docbook
> > > * ...
> >
> >
> > Why do we need sub directories? I like Andrew's idea with the xconfig.
> > All we need some more properties for the buid file.
> >
> > .ant.properties.minimal:
> > include.forms=no
> > include.databases=no
> > include.fop=no
> > [...]
> >
> > .ant.properties.full
> > include.forms=yes
> > include.databases=yes
> > include.fop=yes
> > [...]
> >
> > And the build file can exclude the files for the subprojects, similar to
> > the prepare-src-main task.
> >
> Yes, this is correct and it's (more or less) the way the build system
> is currently working - (the difference is that currently we don't have
> properties but we check for available classes).
>
> Actually this is a maintainance nightmare, Often new features were added
> and the build system (or the optional checks) were not added accurately.
> The build.xml is getting bigger and bigger. By separating this into
> directories this will be IMHO much cleaner and easier.
How should this look like?
src/java/org/apache/cocoon/modules/forms/components/*
src/java/org/apache/cocoon/modules/forms/generation/*
src/webapp/samples/forms/*
src/java/org/apache/cocoon/modules/fop/components/*
src/java/org/apache/cocoon/modules/fop/serialization/*
src/webapp/samples/fop/*
etc.
Like this? It is more cleaner, but I see directories, which owns only
one class :-|
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephan Michels wrote:
>
> On Tue, 6 Aug 2002, Christian Haul wrote:
>
> > On 06.Aug.2002 -- 08:32 AM, Carsten Ziegeler wrote:
> > > So, *if* we vote on refactoring or starting a new Cocoon
> > > major version, I'm definitly -1 on this.
> > >
> > > I still believe that we can solve some (perhaps not all)
> > > problems simply by organizing our project structure and
> > > by shifting our activities from "hacking new features"
> > > to "making a more perfect solution".
> >
> > So, could we just come back to Berin's original idea, create some
> > subdirectories based e.g. on functionality, move stuff to
> > subdirectories if appropriate, and change the build process to include
> > these subdirectories as we do with scratchpad?
> >
> > Step two could be to build seperate jars, step three to relax release
> > cycles for sub-projects. No magic, no changing of any names, just
> > re-packaging.
> >
> > Candidates so far:
> >
> > * forms (simple and XML)
> > * databases (esql, transformer, actions)
> > * fop
> > * portal
> >
> > How about (in addition to the above):
> >
> > * delhi
> > * docbook
> > * ...
>
>
> Why do we need sub directories? I like Andrew's idea with the xconfig.
> All we need some more properties for the buid file.
>
> .ant.properties.minimal:
> include.forms=no
> include.databases=no
> include.fop=no
> [...]
>
> .ant.properties.full
> include.forms=yes
> include.databases=yes
> include.fop=yes
> [...]
>
> And the build file can exclude the files for the subprojects, similar to
> the prepare-src-main task.
>
Yes, this is correct and it's (more or less) the way the build system
is currently working - (the difference is that currently we don't have
properties but we check for available classes).
Actually this is a maintainance nightmare, Often new features were added
and the build system (or the optional checks) were not added accurately.
The build.xml is getting bigger and bigger. By separating this into
directories this will be IMHO much cleaner and easier.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Stephan Michels [mailto:stephan@apache.org]
>>
>
>
> <snip/>
>
>>Why do we need sub directories? I like Andrew's idea with the
>>xconfig. All we need some more properties for the buid file.
>>
>>.ant.properties.minimal:
>>include.forms=no
>>include.databases=no
>>include.fop=no
>>[...]
>>
>>.ant.properties.full
>>include.forms=yes
>>include.databases=yes
>>include.fop=yes
>>[...]
>>
>>And the build file can exclude the files for the subprojects,
>>similar to the prepare-src-main task.
>
>
>
> Because you will run across issues where hidden interdependencies
> will crop up. Dependencies need to be planned.
Gump descriptor is made to handle these interdependencies, in a similar
way to which Excalibur does it.
Basically all these "modules" are defined as projects, and should be
declared as such.
I'm working on it on a simplified Gump ant task-target, and maybe it
would be the best thing to do.
As for the branch, it's evident that it will not be done, so I will
continue to help on a clear evolutive path, with minimal refactorings.
I think that it's the best thing to do too now, the comments were very
well done and insightful.
-oOo-
What about this:
src/framework/java|lib|*/*
src/core/java|lib|*/*
src/components/*componentname*/java|lib|*/*
I will put many components in Morphos, so we will have to see how we can
interoperate from a project POV.
Any ideas?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephan Michels [mailto:stephan@apache.org]
>
<snip/>
> Why do we need sub directories? I like Andrew's idea with the
> xconfig. All we need some more properties for the buid file.
>
> .ant.properties.minimal:
> include.forms=no
> include.databases=no
> include.fop=no
> [...]
>
> .ant.properties.full
> include.forms=yes
> include.databases=yes
> include.fop=yes
> [...]
>
> And the build file can exclude the files for the subprojects,
> similar to the prepare-src-main task.
Because you will run across issues where hidden interdependencies
will crop up. Dependencies need to be planned.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Stephan Michels <st...@apache.org>.
On Tue, 6 Aug 2002, Christian Haul wrote:
> On 06.Aug.2002 -- 08:32 AM, Carsten Ziegeler wrote:
> > So, *if* we vote on refactoring or starting a new Cocoon
> > major version, I'm definitly -1 on this.
> >
> > I still believe that we can solve some (perhaps not all)
> > problems simply by organizing our project structure and
> > by shifting our activities from "hacking new features"
> > to "making a more perfect solution".
>
> So, could we just come back to Berin's original idea, create some
> subdirectories based e.g. on functionality, move stuff to
> subdirectories if appropriate, and change the build process to include
> these subdirectories as we do with scratchpad?
>
> Step two could be to build seperate jars, step three to relax release
> cycles for sub-projects. No magic, no changing of any names, just
> re-packaging.
>
> Candidates so far:
>
> * forms (simple and XML)
> * databases (esql, transformer, actions)
> * fop
> * portal
>
> How about (in addition to the above):
>
> * delhi
> * docbook
> * ...
Why do we need sub directories? I like Andrew's idea with the xconfig.
All we need some more properties for the buid file.
.ant.properties.minimal:
include.forms=no
include.databases=no
include.fop=no
[...]
.ant.properties.full
include.forms=yes
include.databases=yes
include.fop=yes
[...]
And the build file can exclude the files for the subprojects, similar to
the prepare-src-main task.
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
+5
Carsten
> -----Original Message-----
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
> Sent: Tuesday, August 06, 2002 8:59 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [CLEANCOON] Let's clean Cocoon and modularize it (was:
> Cocoon Organization (Cocoon plugins))
>
>
> On 06.Aug.2002 -- 08:32 AM, Carsten Ziegeler wrote:
> > So, *if* we vote on refactoring or starting a new Cocoon
> > major version, I'm definitly -1 on this.
> >
> > I still believe that we can solve some (perhaps not all)
> > problems simply by organizing our project structure and
> > by shifting our activities from "hacking new features"
> > to "making a more perfect solution".
>
> So, could we just come back to Berin's original idea, create some
> subdirectories based e.g. on functionality, move stuff to
> subdirectories if appropriate, and change the build process to include
> these subdirectories as we do with scratchpad?
>
> Step two could be to build seperate jars, step three to relax release
> cycles for sub-projects. No magic, no changing of any names, just
> re-packaging.
>
> Candidates so far:
>
> * forms (simple and XML)
> * databases (esql, transformer, actions)
> * fop
> * portal
>
> How about (in addition to the above):
>
> * delhi
> * docbook
> * ...
>
> Thus I suggest that someone more knowledgeable of the build process
> creates directories for the above and integrates them with the process
> and then those who feel responsible for components move them and their
> samples to one of the subprojects where sensible.
>
> Step four could be to make this pluggable, i.e. blocks.
>
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 06.Aug.2002 -- 08:32 AM, Carsten Ziegeler wrote:
> So, *if* we vote on refactoring or starting a new Cocoon
> major version, I'm definitly -1 on this.
>
> I still believe that we can solve some (perhaps not all)
> problems simply by organizing our project structure and
> by shifting our activities from "hacking new features"
> to "making a more perfect solution".
So, could we just come back to Berin's original idea, create some
subdirectories based e.g. on functionality, move stuff to
subdirectories if appropriate, and change the build process to include
these subdirectories as we do with scratchpad?
Step two could be to build seperate jars, step three to relax release
cycles for sub-projects. No magic, no changing of any names, just
re-packaging.
Candidates so far:
* forms (simple and XML)
* databases (esql, transformer, actions)
* fop
* portal
How about (in addition to the above):
* delhi
* docbook
* ...
Thus I suggest that someone more knowledgeable of the build process
creates directories for the above and integrates them with the process
and then those who feel responsible for components move them and their
samples to one of the subprojects where sensible.
Step four could be to make this pluggable, i.e. blocks.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Ross Gardler <rg...@wkwyw.net>.
Sylvain Wallez wrote:
>
> Something we didn't talk of up to now is testing : subsitemap handling
> by the treeprocessor is broken in the 2.0.3 release because of a
> change in Avalon which had a bad side effect. I'm in the ones to blame
> as I checked the 2.0.3 before it gets released in its default
> configuration only, which is using the compiled engine.
>
> However, such a bug would have been easily found if we had both
> repeatable unit and functional testing. Testing Avalon components and
> SAX-based components may not be easy, but we have to do it in order to
> improve the stability and our confidence in the code base.
>
I too am having problems getting people to buy Cocoon due to stability
issues, lets get things under control while we still can.
I promised some time ago that I would get started on building tests.
Other things have overtaken me at present and I will not get chance to
focus on this for at least a couple of months. However, I am still here,
still watching what's going on and still intending on building some test
harnesses when the time comes.
If people want to get started before I come back for good then all the
better!
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by "Robert S. Koberg" <ro...@koberg.com>.
Torsten Curdt wrote:
> On Tuesday 06 August 2002 18:34, Robert S. Koberg wrote:
>
>>Hi,
>>
>>Berin Loritsch wrote:
>>
>>>What Cocoon needs to test pipelines is an XML Diff utility. I think
>>>I remember something about such a beast existing, but I have no links
>>>or licensing info. You need to compare the generated output to the
>>>expected output. If it is different, it fails the test.
>>
>>http://subversion.tigris.org brings diffs back well-formed.
>
>
> A well-formed diff is not the same thing... one thing is a node based diff,
> the other one is a text based diff but with xml output. You sure subversion
> can do a node based diff?
>
> the only thing I found was http://xmlunit.sourceforge.net/ which should be
> exactly what we need... plus an easy way of constructing a pipeline within a
> testcase.
>
> ...and it comes with a BSD license. is that ok to go into our cvs?
> --
I am invetigating using subversion as the DB & repository. It use
Berkeley DB (who just released an alpha version of their Native XML DB
with a java api).
You can access an XML piece right from the repository locally
(file:///path/to/resource/in/subversion) or through webdav
(https://path/to/resource/in/subversion) or other ways.
If the pipeline gets the source file directly from subversion you might
have what you are looking for?? You bring an XML piece through a
pipeline, if it finds a conflict it transforms an informative message to
the output or takes whatever action necessary.
I am just thinking, don't know how practical...
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Torsten Curdt <tc...@dff.st>.
On Tuesday 06 August 2002 18:34, Robert S. Koberg wrote:
> Hi,
>
> Berin Loritsch wrote:
> > What Cocoon needs to test pipelines is an XML Diff utility. I think
> > I remember something about such a beast existing, but I have no links
> > or licensing info. You need to compare the generated output to the
> > expected output. If it is different, it fails the test.
>
> http://subversion.tigris.org brings diffs back well-formed.
A well-formed diff is not the same thing... one thing is a node based diff,
the other one is a text based diff but with xml output. You sure subversion
can do a node based diff?
the only thing I found was http://xmlunit.sourceforge.net/ which should be
exactly what we need... plus an easy way of constructing a pipeline within a
testcase.
...and it comes with a BSD license. is that ok to go into our cvs?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by "Robert S. Koberg" <ro...@koberg.com>.
Hi,
Berin Loritsch wrote:
>
> What Cocoon needs to test pipelines is an XML Diff utility. I think
> I remember something about such a beast existing, but I have no links
> or licensing info. You need to compare the generated output to the
> expected output. If it is different, it fails the test.
http://subversion.tigris.org brings diffs back well-formed.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Torsten Curdt [mailto:tcurdt@dff.st]
>>
>>we have some simple test cases for our transformers. which is
>>basically
>>building a mini pipeline.
>>
>> public void testXXXX() throws CascadingAssertionFailedError {
>> String srcXML = "<root><childs>....</childs></root>";
>> String dstXML = "<root><childs/></root>";
>>
>> assertTransformation(srcXML, new MyTransformer(), dstXML);
>> }
>>
>>It would be cool to record a orignial pipeline and save it's
>>states...
>>something like one could mime using the log transformer:
>>
>> <map:generate src="..."/>
>> <map:transform type"log"/> ---> state A
>> ....
>> <map:transform type"log"/> ---> state B
>>
>>Then we can pass point A and B to the testcase and see if the
>>behaviour has
>>changed...
>>
>>This won't solve all problems... but...
>>
>>Just some RT ;-)
>
>
>
> What Cocoon needs to test pipelines is an XML Diff utility. I think
> I remember something about such a beast existing, but I have no links
> or licensing info. You need to compare the generated output to the
> expected output. If it is different, it fails the test.
Three tools:
http://www.vmguys.com/vmtools/
http://diffxml.sourceforge.net/
http://www.cs.ucl.ac.uk/staff/c.nentwich/treediff/
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Berin Loritsch <bl...@apache.org>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> we have some simple test cases for our transformers. which is
> basically
> building a mini pipeline.
>
> public void testXXXX() throws CascadingAssertionFailedError {
> String srcXML = "<root><childs>....</childs></root>";
> String dstXML = "<root><childs/></root>";
>
> assertTransformation(srcXML, new MyTransformer(), dstXML);
> }
>
> It would be cool to record a orignial pipeline and save it's
> states...
> something like one could mime using the log transformer:
>
> <map:generate src="..."/>
> <map:transform type"log"/> ---> state A
> ....
> <map:transform type"log"/> ---> state B
>
> Then we can pass point A and B to the testcase and see if the
> behaviour has
> changed...
>
> This won't solve all problems... but...
>
> Just some RT ;-)
What Cocoon needs to test pipelines is an XML Diff utility. I think
I remember something about such a beast existing, but I have no links
or licensing info. You need to compare the generated output to the
expected output. If it is different, it fails the test.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Torsten Curdt <tc...@dff.st>.
On Tuesday 06 August 2002 18:01, Berin Loritsch wrote:
> > Carsten Ziegeler wrote:
> >
> > I experienced recently a customer which preferred JSP/Struts
> > to Cocoon.
> > Cocoon seemed really a nice thing to them, allowing their app
> > to be more
> > cleanly built than with Struts, but they were afraid of both its
> > stability and the important learning curve, even if my
> > company was able
> > to provide support and consulting.
>
> The learning curve does have to be lessoned.
>
> > However, such a bug would have been easily found if we had both
> > repeatable unit and functional testing. Testing Avalon components and
> > SAX-based components may not be easy, but we have to do it in
> > order to
> > improve the stability and our confidence in the code base.
>
> Testing SAX based components is more difficult than testing Avalon
> components.
> Avalon does have a TestCase framework that extends Junit to provide a
> container, logger, etc. so that a component can be tested in its native
> environment.
we have some simple test cases for our transformers. which is basically
building a mini pipeline.
public void testXXXX() throws CascadingAssertionFailedError {
String srcXML = "<root><childs>....</childs></root>";
String dstXML = "<root><childs/></root>";
assertTransformation(srcXML, new MyTransformer(), dstXML);
}
It would be cool to record a orignial pipeline and save it's states...
something like one could mime using the log transformer:
<map:generate src="..."/>
<map:transform type"log"/> ---> state A
....
<map:transform type"log"/> ---> state B
Then we can pass point A and B to the testcase and see if the behaviour has
changed...
This won't solve all problems... but...
Just some RT ;-)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Berin Loritsch <bl...@apache.org>.
> Carsten Ziegeler wrote:
>
> I experienced recently a customer which preferred JSP/Struts
> to Cocoon.
> Cocoon seemed really a nice thing to them, allowing their app
> to be more
> cleanly built than with Struts, but they were afraid of both its
> stability and the important learning curve, even if my
> company was able
> to provide support and consulting.
The learning curve does have to be lessoned.
> However, such a bug would have been easily found if we had both
> repeatable unit and functional testing. Testing Avalon components and
> SAX-based components may not be easy, but we have to do it in
> order to
> improve the stability and our confidence in the code base.
Testing SAX based components is more difficult than testing Avalon
components.
Avalon does have a TestCase framework that extends Junit to provide a
container, logger, etc. so that a component can be tested in its native
environment.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>People,
>
>it's really interesting and I must confess also amuzing to follow
>such a thread like this.
>
>It started with a list of problems we currently have and a
>proposal for reorganizing the project structure.
>And it didn't take long until several come up and say, "Hey,
>the solution is simple: we make Cocoon 3/4 or even Cocoon XP."
>
>How will we ever get people/companies to use Cocoon if we
>change (or refactor) the core every five months? Is this
>refactoring the only solution? Is it the best solution?
>
>You all should now that even changing a package name is a
>real PITA for updating an already running system.
>
>So, *if* we vote on refactoring or starting a new Cocoon
>major version, I'm definitly -1 on this.
>
>
Same for me : -1
I experienced recently a customer which preferred JSP/Struts to Cocoon.
Cocoon seemed really a nice thing to them, allowing their app to be more
cleanly built than with Struts, but they were afraid of both its
stability and the important learning curve, even if my company was able
to provide support and consulting.
So if we want to be able to sell cocoon-based solutions or see large
companies adopt Cocoon we *need* this stability.
Something we didn't talk of up to now is testing : subsitemap handling
by the treeprocessor is broken in the 2.0.3 release because of a change
in Avalon which had a bad side effect. I'm in the ones to blame as I
checked the 2.0.3 before it gets released in its default configuration
only, which is using the compiled engine.
However, such a bug would have been easily found if we had both
repeatable unit and functional testing. Testing Avalon components and
SAX-based components may not be easy, but we have to do it in order to
improve the stability and our confidence in the code base.
>I still believe that we can solve some (perhaps not all)
>problems simply by organizing our project structure and
>by shifting our activities from "hacking new features"
>to "making a more perfect solution".
>
>
+10, even if hacking may be the funniest part of the job. But hacking
tests can be fun also ;)
Sylvain (on a rainy vacation afternoon...)
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: wiki options (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tuesday 06 August 2002 16:42, Sylvain Wallez wrote:
>. . .
> Have you looked at JSPWiki at http://www.ecyrd.com/JSPWiki ?
>. . .
Yes, someone mentioned it here recently. Looks good indeed.
>. . .
> Writing on a wiki is also different from writing on a mailing list : on
> a ML, you can throw an idea in a few lines and see if you get some
> feedback. On a wiki, your thoughts have to be more cleanly structured in
> order to be presented. This also helps maturing ideas.
>. . .
100% agreed. Hopefully this gets going for Cocoon...
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Le...@ingenta.com.
Diana:
>>Sorry if this is an stupid question, but can Wikis check
>>links (included in submitted content)?
No. But there are automated tools for checking link integrity, I believe
there are some open source options if this is a burden.
Steven:
> I've just put up a copy of JSPWiki on my server, and Leigh Dodds of
> Eclectic and xml.com fame is filling it already with his contributions
> (lots).
Yep I've just completed a dump of all my research notes. Hope they're useful.
> <quote src="leigh" medium="private mail">
> I think just putting up a chunk of content will decide where the
> Wiki lives.
> </quote>
I should qualify this and say that I wouldn't presume to pre-empt any 'official'
process, but I also didn't want to see several Wikis spring up with overlapping
content. So I just picked one that used the same platform as my research notes
instance, and pasted the docs in.
Besides, Wiki sites work better once they've been seeded with content.
> Content is king, and we should applaud Leigh for giving us such a
> tremendous headstart. Feeling much obliged - we will take of this.
No probs. I haven't had time to contribute code, so this is my way of helping out.
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> Diana Shannon wrote:
>
>
> I've just put up a copy of JSPWiki on my server, and Leigh Dodds of
> Eclectic and xml.com fame is filling it already with his contributions
> (lots).
>
>> Syvain, how's http://www.anyware-tech.com/wikiland/ faring?
>
Once again about wikiland : it's an attempt to build a Cocoon-based
wiki, and feeding it with Cocoon-related content was meant to attract
Cocoon-related people. And its rather asleep now...
> <quote src="leigh" medium="private mail">
> I think just putting up a chunk of content will decide where the
> Wiki lives.
> </quote>
>
> Content is king, and we should applaud Leigh for giving us such a
> tremendous headstart. Feeling much obliged - we will take of this.
>
> If you feel like wiki'ing, have a look at http://outerthought.net/wiki/
I completely agree with the above and what others said in this thread :
we should not delay the use of a wiki because we don't have a
Cocoon-based wiki. And even more because a wiki *is* its content more
than its infrastructure.
Let's start _today_ with something that works _today_ and if one day a
cool Cocoon-based wiki is available (be it wikiland or something else),
then we may consider migrating the content.
So let's go on with Steven's JSPWiki installation and see how it lives.
It's better to do something with tools that may not be the ultimate ones
than building these ultimate tools and delay forever what we wanted to
do with them.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Steven Noels <st...@outerthought.org>.
Diana Shannon wrote:
>
> On Tuesday, August 6, 2002, at 02:24 PM, Steven Noels wrote:
>
>>>
>>> Writing on a wiki is also different from writing on a mailing list : on
>>> a ML, you can throw an idea in a few lines and see if you get some
>>> feedback.
I didn't wrote that, check your indentation ;-)
> True, but on cocoon-users, there are some great threads which yield good
> doc material. The problem now is a lack of doc committers and patches
> from volunteers. Perhaps we should be encouraging users to post their
> summaries in a wiki-like grammar on cocoon-users. I guess the quality of
> doc-oriented wikis will depend in part if uber-knowledgeable people,
> like Vadim, Christian, and others, spend time monitoring/editing
> doc-wikis like they do currently on cocoon-users. Since Vadim started
> this wiki topic, sounds like he'll be visiting it??? Seems to me we'd
> need a QA stage before commits to cvs.
Agree. A Wiki might be such a QA tool, I believe. And since the back-end
of JSPWiki (read below) stores its content as plain text files, and we
have Chaperon at our disposition, XML-izing the result afterwards
wouldn't be too much of a problem.
>>> On a wiki, your thoughts have to be more cleanly structured in
>>> order to be presented. This also helps maturing ideas.
>>>
> Yes, but in some ways, **until** we can transform Wiki content into a
> structure based on document.dtd, etc., isn't this a step backwards for
> some of the more complex-structured docs? In other words, it seems it
> could significantly increase the burden on committers making periodic
> updates to cvs, etc. I also worry a bit about managing links introduced
> by Wiki docs. Link troubleshooting already consumes a huge chunk of my
> volunteer time. Sorry if this is an stupid question, but can Wikis check
> links (included in submitted content)?
Must be investigated, but I consider *any* progress to be important
enough to live with the results (and pitfalls) they might cause. Wiki
links are only 'established' once the target page exists. We will have
too see how this transposes into the XML world.
>> A wiki for RT's would be really, really great.
>
> I think we should seriously consider doing individual FAQs/Topics this
> way, i.e., one page for each FAQ/Topic.
>
>> Do I proceed with my setup?
>
> Would this now become a Forrest sub-project? Will doc committers have
> access to the resources/files they need?
I've just put up a copy of JSPWiki on my server, and Leigh Dodds of
Eclectic and xml.com fame is filling it already with his contributions
(lots).
> Syvain, how's http://www.anyware-tech.com/wikiland/ faring?
<quote src="leigh" medium="private mail">
I think just putting up a chunk of content will decide where the
Wiki lives.
</quote>
Content is king, and we should applaud Leigh for giving us such a
tremendous headstart. Feeling much obliged - we will take of this.
If you feel like wiki'ing, have a look at http://outerthought.net/wiki/
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by MJ Ray <ma...@cloaked.freeserve.co.uk>.
Steven Noels <st...@outerthought.org> wrote:
> [...] it is currently not up-to-speed with other Wiki implementations
[...]
Please be cautious. The original wiki at http://c2.com/cgi/wiki?FrontPage
should be the benchmark, not any of the BellsWhistlesAndStuffTheWikiWay
implementations. I don't know whether the others you mention are from that
family, but wikis are intentionally lightweight.
--
MJR|
---'
|-----[ Luminas internet applications http://www.luminas.co.uk/ ]-----|
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Ulrich Mayring <ul...@denic.de>.
Steven Noels wrote:
>
> Thanks Ulrich. We all understand your point. It's just that we have
> other priorities right now. Or better: this is a volunteer effort, you
> can't force people to go into your direction.
Of course not, but I am not aware of having tried.
> If you want to influence
> the course of an open source project, the only way to do so is by
> contributing (and I know you did with Avalon).
Isn't that what I'm doing right now? Contributing ideas. Whether they
are useful to others is another question - but surely no-one gets dumber
by reading my comments? :)
As for contributing code, I was not able to explain to my employer the
ROI of migrating all our Cocoon1-based apps to Cocoon2. So all I can do
now is comment occasionally. The ROI of Avalon/Phoenix was easier to
explain and they had zero docs at the time.
cheers,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Steven Noels <st...@outerthought.org>.
Ulrich Mayring wrote:
> Andrew C. Oliver wrote:
>
>> <snip/>
>> Every documentation discussion has broken down into a "lets develop
>> undocumented tool X to serve the documentation!" and
>> faded.
>
>
> My point: X should be Cocoon. Does Adobe ship the docs for Acrobat in
> MS-Word format, because PDF creation is too unwieldy? No, they made PDF
> creation easy instead.
>
> Ulrich
>
Thanks Ulrich. We all understand your point. It's just that we have
other priorities right now. Or better: this is a volunteer effort, you
can't force people to go into your direction. If you want to influence
the course of an open source project, the only way to do so is by
contributing (and I know you did with Avalon). For documentation,
content is equally important as infrastructure. Some of us are focussing
on content. If you come up (preferably together with Olivier Rossel)
with a Wiki solution that runs on top of Cocoon and offers a
footprint/feature set comparable with JSPWiki (which is a pretty
lightweight WikiEngine anyhow), I'm quite sure it will be well received
by this community. I'd be happy to host it, too.
I should be leaving on holidays soon. If you are looking for a group of
like-minded documentation bone-headed people to discuss documentation
infrastructure tools, please go and visit http://xml.apache.org/forrest/.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Ulrich Mayring <ul...@denic.de>.
Andrew C. Oliver wrote:
> Ulrich Mayring wrote:
>
>> My point: X should be Cocoon. Does Adobe ship the docs for Acrobat in
>> MS-Word format, because PDF creation is too unwieldy? No, they made
>> PDF creation easy instead.
>
> My point: So develop the tool. We'll switch to it once you develop the
> tool.
I'm not a Cocoon developer anymore :(
> The rest of us shouldn't STOP documenting until an adequate
> Cocoon Wiki exists.
Agreed. So, everyone is busy writing docs now? :)
> Did Microsoft close Hotmail until it could convert
> it to NT? No. Hotmail ran for a good year or two on UNIX servers after
> being bought by MS.
Initially MS wasn't aware of the bad publicity this could create, so it
was deemed a non-problem. After the bad publicity arose, it became their
first priority to switch over to NT. That took as long as it took, but
it was first priority.
The developers of BeOS were compelled to develop under BeOS. The CEO
said that the product would only become good, if the developers actually
had to work with it. They were given intentionally slow machines, too :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Ulrich Mayring wrote:
> Andrew C. Oliver wrote:
>
>> <snip/>
>> Every documentation discussion has broken down into a "lets develop
>> undocumented tool X to serve the documentation!" and
>> faded.
>
>
> My point: X should be Cocoon. Does Adobe ship the docs for Acrobat in
> MS-Word format, because PDF creation is too unwieldy? No, they made
> PDF creation easy instead.
My point: So develop the tool. We'll switch to it once you develop the
tool. The rest of us shouldn't STOP documenting until an adequate
Cocoon Wiki exists. Did Microsoft close Hotmail until it could convert
it to NT? No. Hotmail ran for a good year or two on UNIX servers after
being bought by MS. Documentation is MORE critical than hosting the
documentation on a Cocoon-based site. Just like MS signing up more
hotmail users so that they could invade their privacy was MORE important
then running it on NT at first.
-Andy
>
> Ulrich
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Ulrich Mayring <ul...@denic.de>.
Andrew C. Oliver wrote:
> <snip/>
> Every documentation discussion has broken down into a "lets develop
> undocumented tool X to serve the documentation!" and
> faded.
My point: X should be Cocoon. Does Adobe ship the docs for Acrobat in
MS-Word format, because PDF creation is too unwieldy? No, they made PDF
creation easy instead.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Priorities [was: Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)]
Posted by Ivelin Ivanov <iv...@apache.org>.
Agreed!
We've started discussing the release plan for 2.1 and we ended up on another
planet again.
Here go my votes in order of priority:
1) Feature freeze for 2.1
2) Announce 2.1 Alpha stage on the main Web Site, so that people that don't
follow the threads are aware of the plan.
3) Improve documentation for 2.1
4) Announce one month voting period for users and developers to decide which
components of Cocoon do not need to be included in the core.
5) Move low voted components back to scratchpad.
6) Announce 2.1 Beta in December-January timeframe
7) Wait until majority of us are comfortable with the quality of the
documentation and the code.
8) Release 2.1 in March-April time frame
As a side task, if someone is willing to work on a build script which allows
modules to be included or excluded from a build, it will be great. While
this is critical for an OS kernel, it is not necessarily a show stopper for
a J2EE server. Weblogic comes as a 100mb install, while we don't use more
than 10mb. Same with WebSphere and other J2EE servers. Cocoon is not exactly
a J2EE container, but it is as sophisticated in many ways.
Disk space is not such a big issue. As long as it is a stable build, size is
not that important on the server side.
Also, when are we merging Forrest with Cocoon's web site?
Regards,
Ivelin
----- Original Message -----
From: "Andrew C. Oliver" <ac...@apache.org>
To: <co...@xml.apache.org>
Sent: Wednesday, August 07, 2002 6:11 AM
Subject: Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and
modularize it . . .)
> <snip/>
>
> >
> > The marketing-savvy people will also fail to adopt Cocoon if there
> > isn't any good documentation with it. So let's stop discussing the
> > 'how', and focus on the 'what'.
> >
> > </Steven>
>
> BIG TIME! +10000000000000000000000000000
>
> Every documentation discussion has broken down into a "lets develop
> undocumented tool X to serve the documentation!" and
> faded.
>
> -Andy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
<snip/>
>
> The marketing-savvy people will also fail to adopt Cocoon if there
> isn't any good documentation with it. So let's stop discussing the
> 'how', and focus on the 'what'.
>
> </Steven>
BIG TIME! +10000000000000000000000000000
Every documentation discussion has broken down into a "lets develop
undocumented tool X to serve the documentation!" and
faded.
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Steven Noels <st...@outerthought.org>.
Ulrich Mayring wrote:
> I'm sure there are good reasons, but from a marketing point of view this
> is a show-stopper. It gives the impression that Cocoon is so hard to use
> that even the devs themselves prefer lighter tools.
Showstopper is a strong word - use it cautiously IMO.
There's two problems here:
* building the app
* hosting the app
Building the app shouldn't be a problem, hence wikiLand
(http://www.lolive.net/). From what I can see however, this is a one-man
show and it is currently not up-to-speed with other Wiki implementations
(not meaning to criticize the work of Olivier, just stating the facts
as-is). JSPWiki has a small but thriving community and is more
feature-advanced then wikiLand.
Now about hosting a Cocoon Wiki:
I and some others have been spending literally *hours* discussing the
use of Java webapps on ASF-infrastructure for Forrest purposes on
infrastructure@apache.org. Given the current state of Java VM's on
FreeBSD and other issues, this is not an option on daedalus nor on
icarus. Pier Fumagalli has offered us access to nagoya, but given my
lack of experience with the Solaris platform, and the fact that Pier
already is doing many thing for ASF, I went for my own server instead
for various Cocoon/Forrest/documentation related experimentations.
I don't have the knowledge nor the time to host a true Sourceforge-like
Cocoon development environment, where people can work on a shared
Cocoon-based webapp, recycle Tomcat as needed, configure cocoon.xconf,
etc, all in a secure and easy-to-maintain way. So I opted for the
sysadmin-fascist approach: I am root on my own server, so I can install
what I want and hopefully provide some useful tools to the community.
I use what is in my reach: a simple Linux server, fortunately well
connected, with tools I can easily install and administer. JSPWiki seems
such a tool to me. After my holidays I will investigate how I can
republish the stored Wiki pages as xdoc XML *through* Cocoon using some
decent skin, as a testcase to migrate Wiki content to xdocs in CVS.
CocoDocoWiki should primarily be used by the documentation contributors,
not necessarily by the community at large - there exist people in our
community that are able and willing to graduate Wiki docs to real Cocoon
documentation.
All this talk about logistics is boring me to death. There was the issue
of not being able to persist [RT]s using some Wiki-like website. So Andy
and I investigated whether we could host such a website. Then Leigh
jumped up with loads of doco contribs. I consider this rapid advancement
of content- and process-related matters much more important than the
technology being used.
The marketing-savvy people will also fail to adopt Cocoon if there isn't
any good documentation with it. So let's stop discussing the 'how', and
focus on the 'what'.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Ulrich Mayring wrote:
> Andrew C. Oliver wrote:
>
>> Personally.... I feel content is king. The rest is details. Lets
>> start generating more content..then we'll figure out how to organize
>> it, and then figure out the technical details (which often seem to
>> become the focus....but this is WRONG)
>
>
> Generally I would agree with you. But as with all good rules, there
> are exceptions. Content is NOT king, when there is not at least a
> basic presentation layer and a sense of "we practice what we preach"
> aka "proof of concept".
>
> When Cocoon first started out, many people got excited and went to
> coding. But no-one could be bothered to use this new tool for the most
> basic purpose: to serve its own website. Even today, generations and
> generations of code later, Cocoon does not serve its own website. And
> now it does not serve its own Wiki.
>
> People from outside ask: what kind of web publishing technology cannot
> even serve its own website? And, Cocoon wants to replace JSP, but it
> uses JSPWiki?
>
> I'm sure there are good reasons, but from a marketing point of view
> this is a show-stopper. It gives the impression that Cocoon is so hard
> to use that even the devs themselves prefer lighter tools.
So you'd rather have NO documentation than serve it on un-cool tools?
As for why Cocoon doesn't serve its own website, I think that has more
to do with the fact Apache has
SEVERAL projects to serve websites and *few* servers doing it. If EVER
project that CAN served its
own website, we'd need some new hardware.
Anyhow, the wiki has been set up outside project resources. The only
resolve those who object really have is
not to use it. Which is unfortunate but your choice. I applaud the
setup of this wiki and plan to contribute!
-Andy
>
> Ulrich
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Ulrich Mayring <ul...@denic.de>.
Andrew C. Oliver wrote:
> Personally.... I feel content is king. The rest is details. Lets
> start generating more content..then we'll figure out how to organize it,
> and then figure out the technical details (which often seem to become
> the focus....but this is WRONG)
Generally I would agree with you. But as with all good rules, there are
exceptions. Content is NOT king, when there is not at least a basic
presentation layer and a sense of "we practice what we preach" aka
"proof of concept".
When Cocoon first started out, many people got excited and went to
coding. But no-one could be bothered to use this new tool for the most
basic purpose: to serve its own website. Even today, generations and
generations of code later, Cocoon does not serve its own website. And
now it does not serve its own Wiki.
People from outside ask: what kind of web publishing technology cannot
even serve its own website? And, Cocoon wants to replace JSP, but it
uses JSPWiki?
I'm sure there are good reasons, but from a marketing point of view this
is a show-stopper. It gives the impression that Cocoon is so hard to use
that even the devs themselves prefer lighter tools.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Personally.... I feel content is king. The rest is details. Lets
start generating more content..then we'll figure out how to organize it,
and then figure out the technical details (which often seem to become
the focus....but this is WRONG)
-Andy
Diana Shannon wrote:
>
> On Tuesday, August 6, 2002, at 04:32 PM, Leigh.Dodds@ingenta.com wrote:
>
>> As far as QA goes, I'd suggest this be applied to Wiki content to
>> make 'official docs', but you can still point people at the Wiki
>> for information, and say "here be dragons".
>
>
> But making "official" cvs xdocs from the wiki still seems like a PITA
> -- at least at the moment. Why not wrap a decent skin on the wiki
> site, do periodic QA, and dump the periodic result (html docs?) into
> the cvs/web site for distros/snapshots, etc. Why do we need cvs xdocs
> anymore?
>
> -- Diana (suddenly feeling very liberated)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> Apparently ;-)
>
> Seriously, I think we will have both, but perhaps for different reasons:
>
> * Wiki for document creation and collaboration, for [RT] sharing and
> the like
> * xdocs for reference documentation, in-sync with releases/branches,
> incorporating Javadoc, etc etc
>
> Don't forget Wikis have no hierarchy (except as made apparent through
> hyperlinkage), all Wiki docs are stored in one directory and are not
> very well organized serverside (which is the purpose, of course)
>
> I see CocoDocoWiki as a breeding pool, and grown-up fishes can then
> migrate to xdoc heaven ;-)
>
> </Steven>
+1 - And later when we have lots and lots of documentation in the Wiki
and its a problem, we can think about Cool Tool X. But until then...
Developing Cool Tool X is like driving a Battleship through a small canal.
-andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Steven Noels <st...@outerthought.org>.
Diana Shannon wrote:
> On Tuesday, August 6, 2002, at 04:32 PM, Leigh.Dodds@ingenta.com wrote:
>
>> As far as QA goes, I'd suggest this be applied to Wiki content to
>> make 'official docs', but you can still point people at the Wiki
>> for information, and say "here be dragons".
>
>
> But making "official" cvs xdocs from the wiki still seems like a PITA --
> at least at the moment. Why not wrap a decent skin on the wiki site, do
> periodic QA, and dump the periodic result (html docs?) into the cvs/web
> site for distros/snapshots, etc. Why do we need cvs xdocs anymore?
>
> -- Diana (suddenly feeling very liberated)
Apparently ;-)
Seriously, I think we will have both, but perhaps for different reasons:
* Wiki for document creation and collaboration, for [RT] sharing and the
like
* xdocs for reference documentation, in-sync with releases/branches,
incorporating Javadoc, etc etc
Don't forget Wikis have no hierarchy (except as made apparent through
hyperlinkage), all Wiki docs are stored in one directory and are not
very well organized serverside (which is the purpose, of course)
I see CocoDocoWiki as a breeding pool, and grown-up fishes can then
migrate to xdoc heaven ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Diana Shannon <sh...@apache.org>.
On Tuesday, August 6, 2002, at 04:32 PM, Leigh.Dodds@ingenta.com wrote:
> As far as QA goes, I'd suggest this be applied to Wiki content to
> make 'official docs', but you can still point people at the Wiki
> for information, and say "here be dragons".
But making "official" cvs xdocs from the wiki still seems like a PITA --
at least at the moment. Why not wrap a decent skin on the wiki site, do
periodic QA, and dump the periodic result (html docs?) into the cvs/web
site for distros/snapshots, etc. Why do we need cvs xdocs anymore?
-- Diana (suddenly feeling very liberated)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Le...@ingenta.com.
> True, but on cocoon-users, there are some great threads which yield good
> doc material.
There certainly are, and I'd hope this could be captured in the Wiki.
> The problem now is a lack of doc committers and patches
> from volunteers.
Lowering the barrier to entry (making it easy to submit content, add
corrections, etc may resolve this)
> Perhaps we should be encouraging users to post their
> summaries in a wiki-like grammar on cocoon-users.
Why not directly into the Wiki?
> I guess the quality of
> doc-oriented wikis will depend in part if uber-knowledgeable people,
> like Vadim, Christian, and others, spend time monitoring/editing
> doc-wikis like they do currently on cocoon-users. Since Vadim started
> this wiki topic, sounds like he'll be visiting it??? Seems to me we'd
> need a QA stage before commits to cvs.
Can't claim to be uber-knowledgeable, but I'll certainly be keeping an eye on
Steven's Wiki, I've just added a chunk of content, as you can see:
http://outerthought.net/wiki/Wiki.jsp?page=RecentChanges
One thing I like about JSPWiki is that it has an RSS feed, so you can
monitor changes to the site with an RSS reader right from your
desktop, you don't have to keep trawling through the site.
As far as QA goes, I'd suggest this be applied to Wiki content to
make 'official docs', but you can still point people at the Wiki
for information, and say "here be dragons".
> Yes, but in some ways, **until** we can transform Wiki content into a
> structure based on document.dtd, etc., isn't this a step backwards for
> some of the more complex-structured docs?
You can do this with WikiML (http://www.wikiml.org) amongst other things.
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Diana Shannon <sh...@apache.org>.
On Tuesday, August 6, 2002, at 02:24 PM, Steven Noels wrote:
>>
>> Writing on a wiki is also different from writing on a mailing list : on
>> a ML, you can throw an idea in a few lines and see if you get some
>> feedback.
True, but on cocoon-users, there are some great threads which yield good
doc material. The problem now is a lack of doc committers and patches
from volunteers. Perhaps we should be encouraging users to post their
summaries in a wiki-like grammar on cocoon-users. I guess the quality of
doc-oriented wikis will depend in part if uber-knowledgeable people,
like Vadim, Christian, and others, spend time monitoring/editing
doc-wikis like they do currently on cocoon-users. Since Vadim started
this wiki topic, sounds like he'll be visiting it??? Seems to me we'd
need a QA stage before commits to cvs.
>> On a wiki, your thoughts have to be more cleanly structured in
>> order to be presented. This also helps maturing ideas.
>>
Yes, but in some ways, **until** we can transform Wiki content into a
structure based on document.dtd, etc., isn't this a step backwards for
some of the more complex-structured docs? In other words, it seems it
could significantly increase the burden on committers making periodic
updates to cvs, etc. I also worry a bit about managing links introduced
by Wiki docs. Link troubleshooting already consumes a huge chunk of my
volunteer time. Sorry if this is an stupid question, but can Wikis check
links (included in submitted content)?
> A wiki for RT's would be really, really great.
I think we should seriously consider doing individual FAQs/Topics this
way, i.e., one page for each FAQ/Topic.
> Do I proceed with my setup?
Would this now become a Forrest sub-project? Will doc committers have
access to the resources/files they need?
Syvain, how's http://www.anyware-tech.com/wikiland/ faring?
-- Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Cocoon Wiki (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Steven Noels <st...@outerthought.org>.
Sylvain Wallez wrote:
> Bertrand Delacretaz wrote:
>
> >On Tuesday 06 August 2002 08:58, Steven Noels wrote:
> >
> >
> >>. . .
> >>phpWiki looks nice, but running PHP
> >>as an Apache2 module doesn't work for me.
> >></sidenote>
> >>. . .
> >>
> >>
> >
> >I don't know about an RCS backend but these might be interesting:
> >
> >http://chiki.emaho.org/
> >based on Struts
> >
> >http://moin.sourceforge.net/
> >Phyton-based but provides an XML view of the content
> >
> >
>
> Have you looked at JSPWiki at http://www.ecyrd.com/JSPWiki ? It's very
> lightweight, and has two features I wanted : versioning and support for
> tables. It has a pluggable versioned filesystem implementation which
> come in two flavors : RCS and flat file.
I had it already installed at http://outerthought.net/wiki/, but I
wasn't able to get RCS working immediately - did you? I will try to
tweak it this evening. Chiki offers versioning information as well.
> We've been using it internally for a few weeks (I tweaked a bit the
> presentation) and I must say a wiki really changes the way of building
> and sharing information in a group. Some people (including myself) also
> use this wiki as a personal scratchbook because of its ease of use, and
> the fact that it is visible to others turns a personal itch into some
> collective thinking.
>
> Writing on a wiki is also different from writing on a mailing list : on
> a ML, you can throw an idea in a few lines and see if you get some
> feedback. On a wiki, your thoughts have to be more cleanly structured in
> order to be presented. This also helps maturing ideas.
>
> As said in Nicola Ken's signature, "verba volant, scripta manent"
> (discussions get forgotten, only _writings_ remain). And the experience
> of lost RTs shows that a mailing list, even with its archive, is mainly
> discussions.
A wiki for RT's would be really, really great. Do I proceed with my setup?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: wiki options (was: Re: [CLEANCOON] Let's clean Cocoon and modularize
it . . .)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bertrand Delacretaz wrote:
>On Tuesday 06 August 2002 08:58, Steven Noels wrote:
>
>
>>. . .
>>phpWiki looks nice, but running PHP
>>as an Apache2 module doesn't work for me.
>></sidenote>
>>. . .
>>
>>
>
>I don't know about an RCS backend but these might be interesting:
>
>http://chiki.emaho.org/
>based on Struts
>
>http://moin.sourceforge.net/
>Phyton-based but provides an XML view of the content
>
>
Have you looked at JSPWiki at http://www.ecyrd.com/JSPWiki ? It's very
lightweight, and has two features I wanted : versioning and support for
tables. It has a pluggable versioned filesystem implementation which
come in two flavors : RCS and flat file.
We've been using it internally for a few weeks (I tweaked a bit the
presentation) and I must say a wiki really changes the way of building
and sharing information in a group. Some people (including myself) also
use this wiki as a personal scratchbook because of its ease of use, and
the fact that it is visible to others turns a personal itch into some
collective thinking.
Writing on a wiki is also different from writing on a mailing list : on
a ML, you can throw an idea in a few lines and see if you get some
feedback. On a wiki, your thoughts have to be more cleanly structured in
order to be presented. This also helps maturing ideas.
As said in Nicola Ken's signature, "verba volant, scripta manent"
(discussions get forgotten, only _writings_ remain). And the experience
of lost RTs shows that a mailing list, even with its archive, is mainly
discussions.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
wiki options (was: Re: [CLEANCOON] Let's clean Cocoon and modularize it . . .)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tuesday 06 August 2002 08:58, Steven Noels wrote:
>. . .
> phpWiki looks nice, but running PHP
> as an Apache2 module doesn't work for me.
> </sidenote>
>. . .
I don't know about an RCS backend but these might be interesting:
http://chiki.emaho.org/
based on Struts
http://moin.sourceforge.net/
Phyton-based but provides an XML view of the content
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Steven Noels <st...@outerthought.org>.
Andrew C. Oliver wrote:
> I have wikis installed on my server... its written in PERL.. . Its very
> simple.... I Has difference highlighting. See here:
> http://www.superlinksoftware.com/cgi-bin/jugwiki.pl
lol :-)
http://outerthought.net/chiki/
> So I saw 2 people who'd like to see me set the wiki up. I don't mind
> but I don't want to set 4 wikis up. If you want to set it up thats
> totally cool with me.. . otherwise I will. Let me know.
Chiki uses XML as it's backend format. Its TextFormattingRules however
are quite strange compared with more common WikiEngines.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Steven Noels wrote:
> Carsten Ziegeler wrote:
>
>> I still believe that we can solve some (perhaps not all)
>> problems simply by organizing our project structure and
>> by shifting our activities from "hacking new features"
>> to "making a more perfect solution".
>
>
> empathic +1
>
> <sidenote>
> On the doco infrastructure level:
> I've been trying to set up a WikiWiki web along the other
> Cocoon/Forrest resources on outerthought.net yesterday evening, but
> failed to find a decent Java port with RCS-backend. phpWiki looks
> nice, but running PHP as an Apache2 module doesn't work for me.
> </sidenote>
I have wikis installed on my server... its written in PERL.. . Its very
simple.... I Has difference highlighting. See here:
http://www.superlinksoftware.com/cgi-bin/jugwiki.pl
>
> Let's focus on finetuning what we have whilst growing a good
> documentation culture, people.
>
> OTOH, let's not fall into the trap of Ant 2.0
> (http://marc.theaimsgroup.com/?l=ant-dev&m=102604001510675&w=2)
> If people feel like major refactoring is the way to go, there is
> nothing in the process that prevents this
> (http://www.x180.net/rules.html).
>
> But I still feel we have some way to go before we could say Cocoon is
> stable in terms of design (flowmap/blocks/...), features (form
> handling...) and documentation. IMO, we need this stable version
> before we can fork.
So I saw 2 people who'd like to see me set the wiki up. I don't mind
but I don't want to set 4 wikis up. If you want to set it up thats
totally cool with me.. . otherwise I will. Let me know.
-Andy
>
> </Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Steven Noels <st...@outerthought.org>.
Leigh Dodds wrote:
>><sidenote>
>>On the doco infrastructure level:
>>I've been trying to set up a WikiWiki web along the other Cocoon/Forrest
>>resources on outerthought.net yesterday evening, but failed to find a
>>decent Java port with RCS-backend. phpWiki looks nice, but running PHP
>>as an Apache2 module doesn't work for me.
>></sidenote>
>
>
> Have you tried JSPWiki? I've been using it for a while and it's pretty good.
> Even has an RSS 1.0 feed of the changes. RCS backend is supported
> (although I've not used this yet).
>
> http://www.ecyrd.com/JSPWiki/
I was actually trying that one - no luck with RCS however. Its interface
is kind of barebones, however (not that this is overly important, of
course). I've got a test instance up and running at
http://outerthought.net/wiki/.
> As an aside, something else worth looking at is WikiML:
>
> http://www.wikiml.org
>
> It's a SAX parser for reading Wiki markup and spitting out XHTML.
> It'd be very simple to repackage it as a Cocoon Generator, and
> generalise the markup it creates.
Chaperon basically does the same thing, IIRC.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Jason Foster wrote:
> <snip/>
>
> With respect to choosing a Wiki, I think that we should (to use a
> Steve Jobs euphemism) "eat our own dogfood" and either use the
> existing WikiLand or...
As I said before, wikiland isn't ready _today_ for us to use it. Let's
not once again fall into the "build the tool first"-syndrome. Let's
install an existing implementation somewhere and start using it. If one
day wikiland is featurefull and stable enough, then a migation can be
thought of.
Also, if Andrew doesn't want to set up an additional wiki on his site, I
would be happy to host it at Anyware. This would be a JSPWiki, which we
already use internally.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Jason Foster <ja...@uwaterloo.ca>.
<snip/>
With respect to choosing a Wiki, I think that we should (to use a Steve
Jobs euphemism) "eat our own dogfood" and either use the existing WikiLand
or...
> As an aside, something else worth looking at is WikiML:
>
> http://www.wikiml.org
>
> It's a SAX parser for reading Wiki markup and spitting out XHTML.
> It'd be very simple to repackage it as a Cocoon Generator, and
> generalise the markup it creates.
Given that Cocoon is supposed to be a whiz-bang framework, it would be
pretty weird, if not disconcerting to people looking at adopting the
framework, not to use it ourselves.
Jason Foster
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Leigh Dodds <ld...@ingenta.com>.
> <sidenote>
> On the doco infrastructure level:
> I've been trying to set up a WikiWiki web along the other Cocoon/Forrest
> resources on outerthought.net yesterday evening, but failed to find a
> decent Java port with RCS-backend. phpWiki looks nice, but running PHP
> as an Apache2 module doesn't work for me.
> </sidenote>
Have you tried JSPWiki? I've been using it for a while and it's pretty good.
Even has an RSS 1.0 feed of the changes. RCS backend is supported
(although I've not used this yet).
http://www.ecyrd.com/JSPWiki/
As an aside, something else worth looking at is WikiML:
http://www.wikiml.org
It's a SAX parser for reading Wiki markup and spitting out XHTML.
It'd be very simple to repackage it as a Cocoon Generator, and
generalise the markup it creates.
> Let's focus on finetuning what we have whilst growing a good
> documentation culture, people.
+1
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Steven Noels <st...@outerthought.org>.
Carsten Ziegeler wrote:
> I still believe that we can solve some (perhaps not all)
> problems simply by organizing our project structure and
> by shifting our activities from "hacking new features"
> to "making a more perfect solution".
empathic +1
<sidenote>
On the doco infrastructure level:
I've been trying to set up a WikiWiki web along the other Cocoon/Forrest
resources on outerthought.net yesterday evening, but failed to find a
decent Java port with RCS-backend. phpWiki looks nice, but running PHP
as an Apache2 module doesn't work for me.
</sidenote>
Let's focus on finetuning what we have whilst growing a good
documentation culture, people.
OTOH, let's not fall into the trap of Ant 2.0
(http://marc.theaimsgroup.com/?l=ant-dev&m=102604001510675&w=2)
If people feel like major refactoring is the way to go, there is nothing
in the process that prevents this (http://www.x180.net/rules.html).
But I still feel we have some way to go before we could say Cocoon is
stable in terms of design (flowmap/blocks/...), features (form
handling...) and documentation. IMO, we need this stable version before
we can fork.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
People,
it's really interesting and I must confess also amuzing to follow
such a thread like this.
It started with a list of problems we currently have and a
proposal for reorganizing the project structure.
And it didn't take long until several come up and say, "Hey,
the solution is simple: we make Cocoon 3/4 or even Cocoon XP."
How will we ever get people/companies to use Cocoon if we
change (or refactor) the core every five months? Is this
refactoring the only solution? Is it the best solution?
You all should now that even changing a package name is a
real PITA for updating an already running system.
So, *if* we vote on refactoring or starting a new Cocoon
major version, I'm definitly -1 on this.
I still believe that we can solve some (perhaps not all)
problems simply by organizing our project structure and
by shifting our activities from "hacking new features"
to "making a more perfect solution".
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Stuart Roebuck [mailto:stuartroebuck@mac.com]
>
> Okay, I wonder if it's time for me to poor water on the flames!
>
>
> * Cocoon 2.0.3 has some problems with it that need fixing.
>
> * Cocoon 2.1 hasn't been released yet.
>
> * We have three books coming out this year, presumably based around
> Cocoon 2.0.x, or maybe around 2.1.some-months-ago.
>
> * There's still isn't adequate documentation for 2.0.x.
>
> * There's a whole bundle of software running 'out there' based on
> Cocoon 1.x and 2.0.x that relies on any number of the existing
> 'unstable' APIs in Cocoon.
>
>
> And now we're talking about refactoring everything.
>
>
> Refactoring is very therapeutic and essential from time to time - like
> tidying your desk. And untidiness is fine too - part of the creative
> process.
>
> But...
>
> If cocoon is more than just a pet project then it needs some checks
and
> balances. From time to time someone has to say. "That's a great
idea,
> keep hold of it and bring it back in six months time!"
>
> Cocoon may be the best thing since sliced bread, but nobody's going to
> put their fingers anywhere near it whilst it's still being sliced.
:)
It's fun and it's to the point.
If any refactoring happens any time soon, I propose to limit it to
repackaging / improving build / etc, with no major code changes.
And, of course, +1 to write down ideas. Wiki would help with it.
Vadim
> Stuart.
>
>
> On Monday, August 5, 2002, at 07:38 pm, Torsten Curdt wrote:
>
> > On Monday 05 August 2002 19:40, Berin Loritsch wrote:
...
> >> Anyhoo, I have been having a mild itch to completely refactor
> >> Cocoon and call it C4 (more for the explosive reference than
> >> for the Cocoon evolutionary reference). However, it has not
> >> been itching enough for me to do anything about it.
> >
> > feeling the same itch...
> >
> > ...it would be really cool to at least collect some ideas and write
> > them down
> > somewhere. Not even discuss them... (it might set the wrong signals)
> > but just
> > marking down the itches we found while using and improving cocoon2.
> >
> > In the end it might give us a better starting point for C3/C4. Or we
> > end up
> > fixing all this in C2. (although I am a friend of rewrites)
> > --
> > Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Stuart Roebuck <st...@mac.com>.
Okay, I wonder if it's time for me to poor water on the flames!
* Cocoon 2.0.3 has some problems with it that need fixing.
* Cocoon 2.1 hasn't been released yet.
* We have three books coming out this year, presumably based around
Cocoon 2.0.x, or maybe around 2.1.some-months-ago.
* There's still isn't adequate documentation for 2.0.x.
* There's a whole bundle of software running 'out there' based on
Cocoon 1.x and 2.0.x that relies on any number of the existing
'unstable' APIs in Cocoon.
And now we're talking about refactoring everything.
Refactoring is very therapeutic and essential from time to time - like
tidying your desk. And untidiness is fine too - part of the creative
process.
But...
If cocoon is more than just a pet project then it needs some checks and
balances. From time to time someone has to say. "That's a great idea,
keep hold of it and bring it back in six months time!"
Cocoon may be the best thing since sliced bread, but nobody's going to
put their fingers anywhere near it whilst it's still being sliced.
Stuart.
On Monday, August 5, 2002, at 07:38 pm, Torsten Curdt wrote:
> On Monday 05 August 2002 19:40, Berin Loritsch wrote:
>>> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>>>
>>> That being said... I grew up in "the south" and would not
>>> have thought
>>> of this meaning in this context.
>>>
>> :)
>>
>> Yes, but Ugo did. Someone else may.
>>
>>
>> Really, I didn't have that picture in my head, but Ugo's
>> comment jogged my memory.
>>
>> Anyhoo, I have been having a mild itch to completely refactor
>> Cocoon and call it C4 (more for the explosive reference than
>> for the Cocoon evolutionary reference). However, it has not
>> been itching enough for me to do anything about it.
>
> feeling the same itch...
>
> ...it would be really cool to at least collect some ideas and write
> them down
> somewhere. Not even discuss them... (it might set the wrong signals)
> but just
> marking down the itches we found while using and improving cocoon2.
>
> In the end it might give us a better starting point for C3/C4. Or we
> end up
> fixing all this in C2. (although I am a friend of rewrites)
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck
(Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD
65AF
------------------------------------------------------------------------
-
Stuart Roebuck
stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS
<http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Torsten Curdt <tc...@dff.st>.
On Monday 05 August 2002 19:40, Berin Loritsch wrote:
> > From: Andrew C. Oliver [mailto:acoliver@apache.org]
> >
> > That being said... I grew up in "the south" and would not
> > have thought
> > of this meaning in this context.
> >
> :)
>
> Yes, but Ugo did. Someone else may.
>
>
> Really, I didn't have that picture in my head, but Ugo's
> comment jogged my memory.
>
> Anyhoo, I have been having a mild itch to completely refactor
> Cocoon and call it C4 (more for the explosive reference than
> for the Cocoon evolutionary reference). However, it has not
> been itching enough for me to do anything about it.
feeling the same itch...
...it would be really cool to at least collect some ideas and write them down
somewhere. Not even discuss them... (it might set the wrong signals) but just
marking down the itches we found while using and improving cocoon2.
In the end it might give us a better starting point for C3/C4. Or we end up
fixing all this in C2. (although I am a friend of rewrites)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Ugo Cei <u....@cbim.it>.
Berin Loritsch wrote:
> Yes, but Ugo did. Someone else may.
I must admit most of my knowledge of English comes from great rock
songs' lyrics:
Are there any queers in the theatre tonight?
Get 'em up against the wall. -- 'Gainst the wall!
And that one in the spotlight, he don't look right to me.
Get him up against the wall. -- 'Gainst the wall!
And that one looks Jewish, and that one's a coon.
Who let all this riffraff into the room?
There's one smoking a joint, and another with spots!
If I had my way I'd have all of ya shot.
-- "In the Flesh", Pink Floyd
OK, enough off-topic posts, already! ;-)
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Andy Lewis <aj...@ascii27.net>.
Whatever this entails - keep in mind that published books are your friends. Don't make them
useless too quickly. Clean, solid and stable - I'm for it. But don't invalidate the exisitng books
anymore than absolutely necessary...
> Berin Loritsch wrote:
>>>From: Andrew C. Oliver [mailto:acoliver@apache.org]
>>>
>>>That being said... I grew up in "the south" and would not
>>>have thought
>>>of this meaning in this context.
>>
>>
>> :)
>>
>> Yes, but Ugo did. Someone else may.
>>
>>
>> Really, I didn't have that picture in my head, but Ugo's
>> comment jogged my memory.
>>
>> Anyhoo, I have been having a mild itch to completely refactor
>> Cocoon and call it C4 (more for the explosive reference than
>> for the Cocoon evolutionary reference). However, it has not
>> been itching enough for me to do anything about it.
>
> It's itching me enough :-O
>
> What I am proposing is basically a first step of a refactoring.
> Wanna join the party?
>
> I want a playground to mess with refactorings, so we can see how it can be done.
> I am doing Morphos for an easy object pipeline.
>
> Since branching seems not to be the solution, do we need another CVS module?
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --------------------------------------------------------------------- To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
--
"The heights of genius are only measurable by the depths of stupidity."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Andrew C. Oliver [mailto:acoliver@apache.org]
>>
>>That being said... I grew up in "the south" and would not
>>have thought
>>of this meaning in this context.
>
>
> :)
>
> Yes, but Ugo did. Someone else may.
>
>
> Really, I didn't have that picture in my head, but Ugo's
> comment jogged my memory.
>
> Anyhoo, I have been having a mild itch to completely refactor
> Cocoon and call it C4 (more for the explosive reference than
> for the Cocoon evolutionary reference). However, it has not
> been itching enough for me to do anything about it.
It's itching me enough :-O
What I am proposing is basically a first step of a refactoring.
Wanna join the party?
I want a playground to mess with refactorings, so we can see how it can
be done.
I am doing Morphos for an easy object pipeline.
Since branching seems not to be the solution, do we need another CVS module?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Berin Loritsch <bl...@apache.org>.
> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>
> That being said... I grew up in "the south" and would not
> have thought
> of this meaning in this context.
:)
Yes, but Ugo did. Someone else may.
Really, I didn't have that picture in my head, but Ugo's
comment jogged my memory.
Anyhoo, I have been having a mild itch to completely refactor
Cocoon and call it C4 (more for the explosive reference than
for the Cocoon evolutionary reference). However, it has not
been itching enough for me to do anything about it.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
That being said... I grew up in "the south" and would not have thought
of this meaning in this context.
-Andy
Berin Loritsch wrote:
>>From: Ugo Cei [mailto:u.cei@cbim.it]
>>
>>Nicola Ken Barozzi wrote:
>>
>><snip/>
>>
>>http://www.dictionary.com/search?q=coon
>>
>> 2. Offensive Slang. Used as a disparaging term for a
>>Black person.
>>
>>Quindi qualcuno potrebbe interpretare CLEANCOON come
>>"negraccio pulito" ;-).
>>
>>
>
>
>My wife, who happens to be black, has a great retort for someone
>using the term "Coon" (usually by a group of people known as
>"Red Necks" an equally derogatory term). BTW, for those not
>familiar with the American stereotypes, the "Red Neck" is accused
>of the following:
>
>* Intensive inbreeding (living up in those isolated mountains)
>* Not too bright or hiegenic ("I done had my bath last May!")
>* Loving guns
>* Hating people with darker hues of skin tone, or essentially any
> other minority group.
>* Drive pickups with gun racks in the back
>
>
>One of these characters pulled up next to my wife when she was
>in college, calling her a "'Coon" (short for Racoon because of the
>black eyes). Her response? "Oh, please. You couldn't even spell
>Coon." He had no response.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> I want to make it really clear.
>
> I apologise if I unintendedly offended someone, it has never been my
> intention.
>
> The term I unhappily coined came from the words Clean and Cocoon.
No offense. It was obvious you were ignorant of the cultural biases
in the term. I was just passing along a funny story that fit the
term.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Ugo Cei [mailto:u.cei@cbim.it]
>>
>>Nicola Ken Barozzi wrote:
>>
>><snip/>
>>
>>http://www.dictionary.com/search?q=coon
>>
>> 2. Offensive Slang. Used as a disparaging term for a
>>Black person.
>>
>>Quindi qualcuno potrebbe interpretare CLEANCOON come
>>"negraccio pulito" ;-).
>
>
>
> My wife, who happens to be black, has a great retort for someone
> using the term "Coon" (usually by a group of people known as
> "Red Necks" an equally derogatory term). BTW, for those not
> familiar with the American stereotypes, the "Red Neck" is accused
> of the following:
>
> * Intensive inbreeding (living up in those isolated mountains)
> * Not too bright or hiegenic ("I done had my bath last May!")
> * Loving guns
> * Hating people with darker hues of skin tone, or essentially any
> other minority group.
> * Drive pickups with gun racks in the back
>
>
> One of these characters pulled up next to my wife when she was
> in college, calling her a "'Coon" (short for Racoon because of the
> black eyes). Her response? "Oh, please. You couldn't even spell
> Coon." He had no response.
I want to make it really clear.
I apologise if I unintendedly offended someone, it has never been my
intention.
The term I unhappily coined came from the words Clean and Cocoon.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Berin Loritsch <bl...@apache.org>.
> From: Ugo Cei [mailto:u.cei@cbim.it]
>
> Nicola Ken Barozzi wrote:
>
> <snip/>
>
> http://www.dictionary.com/search?q=coon
>
> 2. Offensive Slang. Used as a disparaging term for a
> Black person.
>
> Quindi qualcuno potrebbe interpretare CLEANCOON come
> "negraccio pulito" ;-).
My wife, who happens to be black, has a great retort for someone
using the term "Coon" (usually by a group of people known as
"Red Necks" an equally derogatory term). BTW, for those not
familiar with the American stereotypes, the "Red Neck" is accused
of the following:
* Intensive inbreeding (living up in those isolated mountains)
* Not too bright or hiegenic ("I done had my bath last May!")
* Loving guns
* Hating people with darker hues of skin tone, or essentially any
other minority group.
* Drive pickups with gun racks in the back
One of these characters pulled up next to my wife when she was
in college, calling her a "'Coon" (short for Racoon because of the
black eyes). Her response? "Oh, please. You couldn't even spell
Coon." He had no response.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Ugo Cei <u....@cbim.it>.
Nicola Ken Barozzi wrote:
<snip/>
http://www.dictionary.com/search?q=coon
2. Offensive Slang. Used as a disparaging term for a Black person.
Quindi qualcuno potrebbe interpretare CLEANCOON come "negraccio pulito" ;-).
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Leigh Dodds wrote:
>
>>> Since we are talking about code, CVS logs are our WIKI.
>>> That's the intention.
>>
>>
>>
>> You're not serious?
>> I'm not talking about file level changes, I'm talking about design
>> documents, project roadmaps, proposals, etc. How do they get put into
>> a CVS log?
>
>
> I commit the change, it gets reviewed there, live.
> If I want to make a document I commit it, and others change it, I get
> notified via log, I change again or discuss, etc.
>
> I don't see what a WIKI brings developers more than VCSes.
>
It does.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 05 August 2002 16:46, Andrew C. Oliver wrote:
>. . .
> If no, would you all like me to set this up on my server, and if its
> successful we'll move it to some place bigger?
+1
There have been talks of having a wiki for Cocoon for a while, it would
certainly be good for both developers and "documentors". Much more efficient
than a mailing list when collaborating on specs or documentation IMHO.
(There is wikiland which runs on Cocoon, but I don't know how far it is in
its development. Right now the server at
http://www.anyware-tech.com/wikiland/ seems to be down).
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Do we (Apache) have a server to set this up on?
If no, would you all like me to set this up on my server, and if its
successful we'll move it to some place bigger?
-Andy
Vadim Gritsenko wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Leigh Dodds wrote:
>>
>>
>>>>Since we are talking about code, CVS logs are our WIKI.
>>>>That's the intention.
>>>>
>>>>
>>>You're not serious?
>>>
>>>I'm not talking about file level changes, I'm talking about design
>>>
>>>
>>documents,
>>
>>
>>>project roadmaps, proposals, etc. How do they get put into a CVS
>>>
>>>
>log?
>
>
>>I commit the change, it gets reviewed there, live.
>>If I want to make a document I commit it, and others change it, I get
>>notified via log, I change again or discuss, etc.
>>
>>I don't see what a WIKI brings developers more than VCSes.
>>
>>
>
>Nicola,
>
>I think you missed the point. We have lots of RTs, discussions, etc, and
>the only way to get them is through archives, or sometimes some good
>soul [summary]izes them, and again, these summaries are available in the
>archive. Wiki will allow to keep this information online, browsable, and
>*editable*.
>
>
>You are not proposing to use CVS instead of mail-list, are you? ;)
>
>Vadim
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Diana Shannon <sh...@apache.org>.
On Monday, August 5, 2002, at 10:52 AM, Leigh Dodds wrote:
>
>> I think you missed the point. We have lots of RTs, discussions, etc,
>> and
>> the only way to get them is through archives, or sometimes some good
>> soul [summary]izes them, and again, these summaries are available in
>> the
>> archive. Wiki will allow to keep this information online, browsable,
>> and
>> *editable*.
>
> Yep thats exactly what I meant.
>
> Wikis are a 'step up' from a mailing list archive because they have a
> low barrier to entry (it's just as easy to click 'edit this page' as it
> is to click 'new msg'), but there's the ability to go back and revise
> documents. E.g. to add more information, mark stuff as implemented
> or rejected, rationale behind decisions, etc.
I agree. If we have the resources available we should try **any**
approach that increases doc/author input. Even better if such a wiki
system includes (or we can add on) a structured text -> xml tool (based
on new document dtds?). Converting even well-summarized email posts into
cvs doc commits still takes an overly large amount of commiter time. I'm
really not an experienced wiki person, so I'm sure I'm missing out on
many ways to make my volunteer time more productive.
Still, we're starting to get great input on cocoon-users related to doc
content. The doc list (just recently formed) is getting some traffic; I
believe it serves a different purpose -- doc discussions, not simply
editing/changing. Wiki could become another great tool, but let's keep
all of our options open and continue to encourage all efforts, however
they manifest.
> I've personally being organising my Cocoon notes into a wiki I
> have running locally -- something which I'm hoping to release
> publically soon.
Great.
> Some of it can easily be converted into HOW-TOs and other snippets
> which I'll send to Diana as soon as I get time.
I'd love to know more about this "easy" conversion process. And thanks
for the doc draft, Leigh, along with your other helpful
developerWorks-hosted tutorials! Thanks also to Andy, for offering to
host such a system.
-- Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Leigh Dodds <ld...@ingenta.com>.
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: 05 August 2002 15:37
> To: cocoon-dev@xml.apache.org; nicolaken@apache.org
> Subject: RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon
> Organization(Cocoonplugins))
> ...
> I think you missed the point. We have lots of RTs, discussions, etc, and
> the only way to get them is through archives, or sometimes some good
> soul [summary]izes them, and again, these summaries are available in the
> archive. Wiki will allow to keep this information online, browsable, and
> *editable*.
Yep thats exactly what I meant.
Wikis are a 'step up' from a mailing list archive because they have a
low barrier to entry (it's just as easy to click 'edit this page' as it
is to click 'new msg'), but there's the ability to go back and revise
documents. E.g. to add more information, mark stuff as implemented
or rejected, rationale behind decisions, etc.
I've personally being organising my Cocoon notes into a wiki I
have running locally -- something which I'm hoping to release
publically soon.
It contains all the notes I made whilst writing up my three Cocoon
tutorials with developerWorks, so there's a fair chunk of content there.
Hopefully everyone can benefit from it.
Some of it can easily be converted into HOW-TOs and other snippets
which I'll send to Diana as soon as I get time.
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Leigh Dodds wrote:
> >>Since we are talking about code, CVS logs are our WIKI.
> >>That's the intention.
> >
> >
> > You're not serious?
> >
> > I'm not talking about file level changes, I'm talking about design
> documents,
> > project roadmaps, proposals, etc. How do they get put into a CVS
log?
>
> I commit the change, it gets reviewed there, live.
> If I want to make a document I commit it, and others change it, I get
> notified via log, I change again or discuss, etc.
>
> I don't see what a WIKI brings developers more than VCSes.
Nicola,
I think you missed the point. We have lots of RTs, discussions, etc, and
the only way to get them is through archives, or sometimes some good
soul [summary]izes them, and again, these summaries are available in the
archive. Wiki will allow to keep this information online, browsable, and
*editable*.
You are not proposing to use CVS instead of mail-list, are you? ;)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leigh Dodds wrote:
>>Since we are talking about code, CVS logs are our WIKI.
>>That's the intention.
>
>
> You're not serious?
>
> I'm not talking about file level changes, I'm talking about design documents,
> project roadmaps, proposals, etc. How do they get put into a CVS log?
I commit the change, it gets reviewed there, live.
If I want to make a document I commit it, and others change it, I get
notified via log, I change again or discuss, etc.
I don't see what a WIKI brings developers more than VCSes.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoonplugins))
Posted by Leigh Dodds <ld...@ingenta.com>.
> Since we are talking about code, CVS logs are our WIKI.
> That's the intention.
You're not serious?
I'm not talking about file level changes, I'm talking about design documents,
project roadmaps, proposals, etc. How do they get put into a CVS log?
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoon
plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leigh Dodds wrote:
>>HA! And we'll be in exactly the same situation in the end. I'm sorry
>>but more doing things by the seat of our pants
>>without explaining it in honest to god documentation first (and
>>documents can be modified as your understanding develops) is
>>a fools errand. We'll just have the same thing broken into many pieces
>>that very few people understand. This is not an
>>improvement in my opinion. (Like I said, it shouldn't count for much,
>>I'm 3/4 very dumb user and 1/4 cocoon developer)
>
>
> Here's a concrete suggestion: start a Cocoon wiki site.
>
> Put all proposals in there, as they get implemented fill in the details.
> This can still be developer-oriented docs (i.e. no tutorials), but
> at least it's captured.
>
> Yep, I know there are web archives, but they're not a great way
> of organising information. Wikis are the next step up.
Since we are talking about code, CVS logs are our WIKI.
That's the intention.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoon plugins))
Posted by Leigh Dodds <ld...@ingenta.com>.
> HA! And we'll be in exactly the same situation in the end. I'm sorry
> but more doing things by the seat of our pants
> without explaining it in honest to god documentation first (and
> documents can be modified as your understanding develops) is
> a fools errand. We'll just have the same thing broken into many pieces
> that very few people understand. This is not an
> improvement in my opinion. (Like I said, it shouldn't count for much,
> I'm 3/4 very dumb user and 1/4 cocoon developer)
Here's a concrete suggestion: start a Cocoon wiki site.
Put all proposals in there, as they get implemented fill in the details.
This can still be developer-oriented docs (i.e. no tutorials), but
at least it's captured.
Yep, I know there are web archives, but they're not a great way
of organising information. Wikis are the next step up.
Cheers,
L.
--
Leigh Dodds
http://weblogs.userland.com/eclectic
"Pluralitas non est ponenda sine necessitate" -- William of Ockham
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization
(Cocoon plugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Andrew C. Oliver wrote:
>
>>>
>>> If nobody objects, I will branch on 7 August 2002 and start
>>> refactoring.
>>>
>> Not that my opinion should count for much, but I object. My
>> objection is this. Before there is an agreement and set of
>> documentation explaining "WHAT goes WHERE" then this will be
>> contentious. Secondly, I'd like to see something that explains how a
>> common person will go about installing Cocoon with *feature X* once
>> its split into a billion complex pieces with UNKNOWN dependancies.
>
>
> Each module will be a "project" in the Gump descriptor.
> Hence the dependencies are clear.
Thats a cop out.
>
>> Modularization will only work if the modules are defined in a human
>> language.
>
>
> Exactly.
Lets START there.
>
>> So far I see a million "lets fix it via just hacking at it"
>> approaches, no definitions, and still inadequate documentation.
>> Personally, I feel the documentation is FAR more important than ANY
>> refactoring at helping users understand Cocoon.
>
>
> But how can you document a tangle? By writing tangled documentation,
> as now.
That is false. The state of the documentation is not related to the
state of Cocoon, its related to the low priority that documentation is
given. Example:
http://jakarta.apache.org/poi/poifs/fileformat.html
The OLE 2 Compound Document format is more of a tangle than Cocoon could
ever hope to be. Yet this documentation is organized and conceise. Can
you read this and immediately grasp the low level concepts and just hack
one out? No probably
not, you'd need the experience of working with it. But can you get a
high level conceptual understanding and know where to start? Yes.
There are innumerable examples of this throughout history, but I'm not
that long winded. Read some Stephen Hawkings and understand the order
of the chaotic birth of the universe explained conciecely without making
a web of chaos! (And I'm mathmatically retarded)
>
> We need to get a cleaner separation of stuff and that is gonna be
> documented.
No that is exactly the opposite. We need a clear understanding of what
is going to be seperated before we
do it. Otherwise it will be more of the same.
>
> I will hack on the branch so that others can see the moves, and they
> will be discussed as they are done.
>
HA! And we'll be in exactly the same situation in the end. I'm sorry
but more doing things by the seat of our pants
without explaining it in honest to god documentation first (and
documents can be modified as your understanding develops) is
a fools errand. We'll just have the same thing broken into many pieces
that very few people understand. This is not an
improvement in my opinion. (Like I said, it shouldn't count for much,
I'm 3/4 very dumb user and 1/4 cocoon developer)
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[RACOON] Let's clean Cocoon and modularize it (was: Cocoon Organization
(Cocoon plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew C. Oliver wrote:
>>
>> If nobody objects, I will branch on 7 August 2002 and start refactoring.
>>
> Not that my opinion should count for much, but I object. My objection
> is this. Before there is an agreement and set of documentation
> explaining "WHAT goes WHERE" then this will be contentious. Secondly,
> I'd like to see something that explains how a common person will go
> about installing Cocoon with *feature X* once its split into a billion
> complex pieces with UNKNOWN dependancies.
Each module will be a "project" in the Gump descriptor.
Hence the dependencies are clear.
> Modularization will only work
> if the modules are defined in a human language.
Exactly.
> So far I see a million
> "lets fix it via just hacking at it" approaches, no definitions, and
> still inadequate documentation. Personally, I feel the documentation is
> FAR more important than ANY refactoring at helping users understand Cocoon.
But how can you document a tangle? By writing tangled documentation, as now.
We need to get a cleaner separation of stuff and that is gonna be
documented.
I will hack on the branch so that others can see the moves, and they
will be discussed as they are done.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Hi.. I'm not "not replying" - Vadim covered my opinion:
"
Because (IIRC) there is no docs to it. And refactoring, remodularizing,
forresting, etc will not help this situation - as Andrew pointed out.
And I cannot not to agree with him.
"
Anyhow, I'm not a committer, so my -1 is not binding. Just I hope you realize
how wrong you are before you get to far. I fear the day when Cocoon is refactored
into a billion unexplainable/undocumented pieces that I can't figure out how to fit together.
I'm currently quite able to install Cocoon with the features I need, and I'm even able to
remove some. Granted it took me ~6 months to get there, but I got there. So consider me
the little mouse...the user voice that knows his squeek is irrelevant but squeeks before being
stomped under foot. Then do what you must.
-=Andy "The Please Document Mouse"
Nicola Ken Barozzi wrote:
>
> Vadim Gritsenko wrote:
>
>>> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>>>
>>>
>>>> If nobody objects, I will branch on 7 August 2002 and start
>>>
>>>
>> refactoring.
>>
>>> Not that my opinion should count for much, but I object.
>>
>>
>>
>> I'm with you, we are -1.5 now.
>>
>> Ken, shall we do one step at a time, please?
>> (seems that I'm in favor of evolution)
>
>
> This is not evolution.
> Refactoring is never evolution.
>
>>> My objection
>>> is this. Before there is an agreement and set of documentation
>>> explaining "WHAT goes WHERE" then this will be contentious.
>>
>>
>>
>> +1. Before we start branching CVS, let's define what goes where. "Cocoon
>> Organization" thread was exactly about this.
>
>
> Why?
> The branch is a playground, where many can *see* the difference
> instead of just trying to understand it.
>
> If you prefer I can just write the things I will move, but it just
> seems easier to me to move them and have all evaluate it.
>
> AFAIK there doesn't have to be a vote to branch, but there is to be a
> vote to switch codebases or to switch back.
>
> For now, I haven't heard compelling reasons not to.
>
>>> Secondly,
>>> I'd like to see something that explains how a common person will go
>>> about installing Cocoon with *feature X* once its split into a billion
>>> complex pieces with UNKNOWN dependancies. Modularization will only
>>> work
>>> if the modules are defined in a human language. So far I see a
>>> million
>>> "lets fix it via just hacking at it" approaches, no definitions, and
>>> still inadequate documentation. Personally, I feel the documentation
>>> is
>>> FAR more important than ANY refactoring at helping users understand
>>
>>
>> Cocoon.
>>
>> +1.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>> Also, can you comment on Andrew's suggestion:
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814208304842&w=2
>
>
> I'm doing it since months now, it's called Centipede.
> We are moving right now with the help of Ant-dev to a new level with
> build imports, and it will be proposed to Cocoon ASAP.
No...this is no really an even match with centipede. I mean a nice big
fat menu that it would be nice to be able to run in text mode as well
that reads in a property file with
lines like
"
batik=N
POI=Y
"
./build.sh textconfig would say
"Include Batik [Y/N/H]"?
"Include POI [Y/N/H]"?
Hitting H would get a description such as....
"POI and the associated serialization support classes provide XML
serialization to legacy formats such as Microsoft Excel 97 and Word. In
short if you need to generate XLS spreadsheets from XML documents, say
yes here, otherwise its safe to say N"
"Batik and its associated serialization support classes provide support
for generating Scalable Vector Graphics and converting them to other
formats. If you wish to, for instance, generate JPGs on the fly from
text strings, or bla bla then say yes here, otherwise
its safe to say no"
Following this you could do:
./build.sh configuredwar
and out would come your cocoon with only what you wanted!
We don't necessarily need centipede for this, nor is this necessarily
provided by centipede, though cents supporting this might make it
easier...
>
>> And Konstantin's:
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814539808547&w=2
>
>
> We don't really need different editions, Cocoon core is not that big.
> What we need is instead the possibility of using Cocoon in different
> environments, hence the Bean (embedded), CLI (standard) and
> servlet/Phoenix (enterprise.)
okay.
>
>> And Berin's:
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814063603019&w=2
>
>
> We need to sepate implementations where needed and group them when
> not, a simple rule of -all separate- or -using same libs- is not
> enough, since there will always be many shared dependencies.
> We need a list of the impls and the proposed "components".
>
>>
>> My other reason is: the more (playground) directories we create, the
>> more messy MAIN becomes. And, one cannot work with HEAD, because you
>> cannot commit to HEAD.
>
>
> I said BRANCH, not subdirs.
>
He means when you create subdirs in the branch.
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Vadim Gritsenko wrote:
>>
>>>>From: Andrew C. Oliver [mailto:acoliver@apache.org]
>>>
> ...
>
>>>>My objection
>>>>is this. Before there is an agreement and set of documentation
>>>>explaining "WHAT goes WHERE" then this will be contentious.
>>>
>>>+1. Before we start branching CVS, let's define what goes where.
>>
> "Cocoon
>
>>>Organization" thread was exactly about this.
>>
>>Why?
>>The branch is a playground, where many can *see* the difference
>
> instead
>
>>of just trying to understand it.
>>
>>If you prefer I can just write the things I will move, but it just
>
> seems
>
>>easier to me to move them and have all evaluate it.
>
>
> My main concern about Cocoon health is that it grows with features which
> are *not* integrated with each other. Examples are:
>
> 1. CInclude vs XInclude
> 2. ESQL vs SQLTransformer
> 3. xscript vs session context
> 4. ProgrammingLanguage vs Interpreter
> etc.
>
> All these features should be better integrated with each other, should
> be built on common code and share that common code. The resulting shared
> code base among features will easy maintenance burden, reduce amount of
> code, and will give better integrated Cocoon, where features are work
> with each other seamlessly.
>
> If you to break up things into several packages, it will be much harder
> to do integration work (if possible at all).
Just put them in the same component package.
> Also, can you comment on Andrew's suggestion:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814208304842&w=2
I'm doing it since months now, it's called Centipede.
We are moving right now with the help of Ant-dev to a new level with
build imports, and it will be proposed to Cocoon ASAP.
> And Konstantin's:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814539808547&w=2
We don't really need different editions, Cocoon core is not that big.
What we need is instead the possibility of using Cocoon in different
environments, hence the Bean (embedded), CLI (standard) and
servlet/Phoenix (enterprise.)
> And Berin's:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814063603019&w=2
We need to sepate implementations where needed and group them when not,
a simple rule of -all separate- or -using same libs- is not enough,
since there will always be many shared dependencies.
We need a list of the impls and the proposed "components".
>>AFAIK there doesn't have to be a vote to branch, but there is to be a
>>vote to switch codebases or to switch back.
>>
>>For now, I haven't heard compelling reasons not to.
>
>
> My other reason is: the more (playground) directories we create, the
> more messy MAIN becomes. And, one cannot work with HEAD, because you
> cannot commit to HEAD.
I said BRANCH, not subdirs.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Andrew C. Oliver wrote:
> >
> I'm missing something here Carsten. You may have been saying "and
> Session Transformer" but if I didn't
> make the connection that Session Transformer=Include something... So
> you're saying this has functionality
> that coulde be shared between it CInclude/XInclude?
>
The SessionTransformer (found in the webapps/session package and named
"session" in the sitemap has also an include feature/tag.
Now, why is it called SessionTransformer? We first developed this
transformer with all this session handling stuff and then found out
that we also needed a good include feature. So, instead of making
a new transformer this was added to the SessionTransformer (and the
former name of this transformer was SunShineTransformer anyway).
The main difference is that the include feature of the session
transformer is configurable (as it uses a more verbose syntax):
(Replace sunshine: with session:)
<sunshine:include>
<sunshine:connection type="uri">
<sunshine:target>http://itsunshine/tamino/blah</sunshine:target>
<sunshine:config>
<sunshine:param>
<sunshine:name>method</sunshine:name>
<sunshine:value>POST</sunshine:value>
</sunshine:param>
</sunshine:config>
<sunshine:params>
<sunshine:param>
<sunshine:name>message</sunshine:name>
<sunshine:value>Hi there</sunshine:value>
</sunshine:param>
<sunshine:param>
<sunshine:name>_Process</sunshine:name>
<sunshine:value><name>matti</name><age>36</age></sunshine:value>
</sunshine:param>
<sunshine:param>
<sunshine:name>Test</sunshine:name>
<sunshine:value><sunshine:getxml context="request"
path="/parameter/matti"/></sunshine:value>
</sunshine:param>
</sunshine:params>
</sunshine:connection>
</sunshine:include>
As you can see, you can dynamically add request parameters and configure
the connection, like setting the POST method.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>My main concern about Cocoon health is that it grows with features which
>>are *not* integrated with each other. Examples are:
>>
>>1. CInclude vs XInclude
>>2. ESQL vs SQLTransformer
>>3. xscript vs session context
>>4. ProgrammingLanguage vs Interpreter
>>etc.
>>
>>
>>
>And the interesting thing here is that also I mentioned it over a dozen
>times
>in the last two months, noone realized (or wants to realize) that we have
>a third transformer, the session transformer which can also do includes
>like the CInclude/XInclude transformers, but in a much better way (with
>HTTP POST etc.) (This is not targetted at you, Vadim).
>
I'm missing something here Carsten. You may have been saying "and
Session Transformer" but if I didn't
make the connection that Session Transformer=Include something... So
you're saying this has functionality
that coulde be shared between it CInclude/XInclude?
>
>
>Carsten
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> My main concern about Cocoon health is that it grows with features which
> are *not* integrated with each other. Examples are:
>
> 1. CInclude vs XInclude
> 2. ESQL vs SQLTransformer
> 3. xscript vs session context
> 4. ProgrammingLanguage vs Interpreter
> etc.
>
And the interesting thing here is that also I mentioned it over a dozen
times
in the last two months, noone realized (or wants to realize) that we have
a third transformer, the session transformer which can also do includes
like the CInclude/XInclude transformers, but in a much better way (with
HTTP POST etc.) (This is not targetted at you, Vadim).
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Vadim Gritsenko wrote:
> >>From: Andrew C. Oliver [mailto:acoliver@apache.org]
...
> >>My objection
> >>is this. Before there is an agreement and set of documentation
> >>explaining "WHAT goes WHERE" then this will be contentious.
> >
> > +1. Before we start branching CVS, let's define what goes where.
"Cocoon
> > Organization" thread was exactly about this.
>
> Why?
> The branch is a playground, where many can *see* the difference
instead
> of just trying to understand it.
>
> If you prefer I can just write the things I will move, but it just
seems
> easier to me to move them and have all evaluate it.
My main concern about Cocoon health is that it grows with features which
are *not* integrated with each other. Examples are:
1. CInclude vs XInclude
2. ESQL vs SQLTransformer
3. xscript vs session context
4. ProgrammingLanguage vs Interpreter
etc.
All these features should be better integrated with each other, should
be built on common code and share that common code. The resulting shared
code base among features will easy maintenance burden, reduce amount of
code, and will give better integrated Cocoon, where features are work
with each other seamlessly.
If you to break up things into several packages, it will be much harder
to do integration work (if possible at all).
Also, can you comment on Andrew's suggestion:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814208304842&w=2
And Konstantin's:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814539808547&w=2
And Berin's:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814063603019&w=2
> AFAIK there doesn't have to be a vote to branch, but there is to be a
> vote to switch codebases or to switch back.
>
> For now, I haven't heard compelling reasons not to.
My other reason is: the more (playground) directories we create, the
more messy MAIN becomes. And, one cannot work with HEAD, because you
cannot commit to HEAD.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote:
>>From: Andrew C. Oliver [mailto:acoliver@apache.org]
>>
>>
>>>If nobody objects, I will branch on 7 August 2002 and start
>>
> refactoring.
>
>>Not that my opinion should count for much, but I object.
>
>
> I'm with you, we are -1.5 now.
>
> Ken, shall we do one step at a time, please?
> (seems that I'm in favor of evolution)
This is not evolution.
Refactoring is never evolution.
>>My objection
>>is this. Before there is an agreement and set of documentation
>>explaining "WHAT goes WHERE" then this will be contentious.
>
>
> +1. Before we start branching CVS, let's define what goes where. "Cocoon
> Organization" thread was exactly about this.
Why?
The branch is a playground, where many can *see* the difference instead
of just trying to understand it.
If you prefer I can just write the things I will move, but it just seems
easier to me to move them and have all evaluate it.
AFAIK there doesn't have to be a vote to branch, but there is to be a
vote to switch codebases or to switch back.
For now, I haven't heard compelling reasons not to.
>>Secondly,
>>I'd like to see something that explains how a common person will go
>>about installing Cocoon with *feature X* once its split into a billion
>>complex pieces with UNKNOWN dependancies. Modularization will only
>> work
>>if the modules are defined in a human language. So far I see a
>> million
>>"lets fix it via just hacking at it" approaches, no definitions, and
>>still inadequate documentation. Personally, I feel the documentation
>> is
>>FAR more important than ANY refactoring at helping users understand
>
> Cocoon.
>
> +1.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>
> >
> > If nobody objects, I will branch on 7 August 2002 and start
refactoring.
> >
> Not that my opinion should count for much, but I object.
I'm with you, we are -1.5 now.
Ken, shall we do one step at a time, please?
(seems that I'm in favor of evolution)
> My objection
> is this. Before there is an agreement and set of documentation
> explaining "WHAT goes WHERE" then this will be contentious.
+1. Before we start branching CVS, let's define what goes where. "Cocoon
Organization" thread was exactly about this.
> Secondly,
> I'd like to see something that explains how a common person will go
> about installing Cocoon with *feature X* once its split into a billion
> complex pieces with UNKNOWN dependancies. Modularization will only
work
> if the modules are defined in a human language. So far I see a
million
> "lets fix it via just hacking at it" approaches, no definitions, and
> still inadequate documentation. Personally, I feel the documentation
is
> FAR more important than ANY refactoring at helping users understand
Cocoon.
+1.
Vadim
> -Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> If nobody objects, I will branch on 7 August 2002 and start refactoring.
>
Not that my opinion should count for much, but I object. My objection
is this. Before there is an agreement and set of documentation
explaining "WHAT goes WHERE" then this will be contentious. Secondly,
I'd like to see something that explains how a common person will go
about installing Cocoon with *feature X* once its split into a billion
complex pieces with UNKNOWN dependancies. Modularization will only work
if the modules are defined in a human language. So far I see a million
"lets fix it via just hacking at it" approaches, no definitions, and
still inadequate documentation. Personally, I feel the documentation is
FAR more important than ANY refactoring at helping users understand Cocoon.
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Let's clean Cocoon and modularize it (was: Cocoon Organization(Cocoon plugins))
Posted by Leigh Dodds <ld...@ingenta.com>.
Just to jump in a spend my two euros:
One thing that ought that I think should be collectively
thought about is whether modularization (or indeed,
anything) can help stabilise particular aspects of Cocoon
such that they can be clearly labelled as stable/core, etc.
This is an issue that I've encountered when proposing that
Cocoon be deployed into a commercial environment.
Essentially: "if we build an application on this version of
Cocoon, are we going to easily migrate to newer versions
of the software without having to rearchitect the application".
It seems that there are some aspects of Cocoon that are
undergoing fairly radical changes -- I keep seeing mention
of changes to the Sitemap processing model (blocks?)
for instance -- this is off-putting when you can a stable
platform for your application.
Cheers,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[RACOON] Cocoon refactoring (was many other things)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Vadim Gritsenko wrote:
>>
>>>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>>
>>>
>>><snip/>
>>>
>>>>Now, has anyone easily used Cocoon out of a Servlet environment?
>>>
>>>
>>>Ant to build docs - yes. Offline generation is another one used by
>>
> some
>
>>>people.
>>
>>Ha. *easily* I said.
>>Peter Donald ov Avalon is not the last programmer on earth, yet he
>>doesn't know yet that with Cocoon CLI you can supply a list of URLs to
>>preocess and *not* crawl. I'm 100% sure it's not his fault.
>
> Because (IIRC) there is no docs to it. And refactoring, remodularizing,
> forresting, etc will not help this situation - as Andrew pointed out.
> And I cannot not to agree with him.
I never said that documentation has not to be there.
The point is that if someone needs to read a book just to get started
proficiently, I say we're off track.
>>And how about embedding Cocoon in other apps?
:-?
>>>>We need a _CocoonBean_, that becomes the core entry point.
>>>>You give it a sitemap, input, and it processes the output. Simple as
>>>
>>>that.
>>>
>>>What's wrong with Cocoon.java? It *is* the entry point. If you don't
>>>like something in it - let's fix it, why start another /bean/?
>>
>>Simply because Cocoon.java is not an easy entry point.
>>Look how Main.java calls it, and you will understand how it's not
>>user-friendly.
>
>
>
> Cocoon c = new Cocoon();
> c.setLogger(log);
> c.contextualize(appContext);
> c.setLogKitManager(logKitManager);
> c.initialize();
> FileSavingEnvironment env =
> new FileSavingEnvironment(deparameterizedURI,
> context,
> attributes,
> parameters,
> links,
> stream,
> log);
> c.process(env);
> c.dispose();
>
> Not one line, yes, but not impossible, too... The complexity here is
> that Cocoon is a Component.
And you didn't write how you created log, appContext, logKitManager, etc.
This makes it much longer.
>>We can fix that instead of making a bean, this is just an
>> implementation
>
>>issue. I just thoght that creating a bean would break less stuff that
>>now is depending on the "old" Cocoon.java.
>
>
> Ok, +1 for CocoonBean. Let's keep Cocoon.java as is.
Ok, but this is just the tip of the refactoring.
Ok :-/ , let me write it here first.
Take Cocoon src/java/org/apache/cocoon/.
Remove all the implementation in
acting
generation
matching
reading
selection
serialization
and make a src/components/componentname/org/apache/cocoon/* hierarchy
where you put them.
Make a single componentname called common for the common components that
do not depend on other jars.
Move also the webapps packages
Now we have in the src/java/org/apache/cocoon/*
acting/Action.java
generation/Generator.java
matching/Matcher.java
reading/Reder.java
selection/Selector.java
serialization/Serializer.java
Which is plain stupid, so we can simply make them in a package called
components.
Then we need to show the layers in Cocoon as packages.
so we will have
components (we have already moved the interfaces)
pipelines (we should move here the pipelines)
sitemaps
Then the util package, the existence of which always makes me uneasy, in
every project I see.
I propose to move this to Jakarta Commons, where it already has been
voted positively to make XML.Apache members possible to work in the sandbox.
Then we have the current /components, that need to be split into real
Cocoon-Avalon components or ones used by Sitemap Components.
The latter should go along with the
src/components/componentname/org/apache/cocoon/components/*
naming scheme, or similar.
The Cocoon system components into services, and switch from Composable
to Serviceable.
Finally we need to move all frontends to a cocoon/frontends or similar,
that will have Main.java, renamed to Commandline.java, CocoonTask.java,
CocoonServlet.java, etc (so remove Cocoon/servlet in the Process).
finally it will be something like:
components (only interfaces)
pipelines (interfaces+an impl package)
sitemap (interfaces+an impl package)
environment (interfaces+ impl package)
frontends (only implementations and also CocoonBean)
Cocoon.java
i18n and caching goes into the serviceable stuff.
Then we need to formalize the Source stuff, and separate cleanly the
localiation stage from the Generation stage.
And then see how to interoperate with Morphos, or simply inglobate it.
This would be the first run, then there are other things to do like
switch to Fortress/Merlin, clean the lifecycle interface and expose less
components and more services.
Oh, and then make blocks ;-)
This is what is in my head, see if it makes sense.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Vadim Gritsenko wrote:
> >>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> >
> > <snip/>
> >
> >>Now, has anyone easily used Cocoon out of a Servlet environment?
> >
> >
> > Ant to build docs - yes. Offline generation is another one used by
some
> > people.
>
> Ha. *easily* I said.
> Peter Donald ov Avalon is not the last programmer on earth, yet he
> doesn't know yet that with Cocoon CLI you can supply a list of URLs to
> preocess and *not* crawl. I'm 100% sure it's not his fault.
Because (IIRC) there is no docs to it. And refactoring, remodularizing,
forresting, etc will not help this situation - as Andrew pointed out.
And I cannot not to agree with him.
> And how about embedding Cocoon in other apps?
>
> >>We need a _CocoonBean_, that becomes the core entry point.
> >>You give it a sitemap, input, and it processes the output. Simple as
> >
> > that.
> >
> > What's wrong with Cocoon.java? It *is* the entry point. If you don't
> > like something in it - let's fix it, why start another /bean/?
>
> Simply because Cocoon.java is not an easy entry point.
> Look how Main.java calls it, and you will understand how it's not
> user-friendly.
Cocoon c = new Cocoon();
c.setLogger(log);
c.contextualize(appContext);
c.setLogKitManager(logKitManager);
c.initialize();
FileSavingEnvironment env =
new FileSavingEnvironment(deparameterizedURI,
context,
attributes,
parameters,
links,
stream,
log);
c.process(env);
c.dispose();
Not one line, yes, but not impossible, too... The complexity here is
that Cocoon is a Component.
> We can fix that instead of making a bean, this is just an
implementation
> issue. I just thoght that creating a bean would break less stuff that
> now is depending on the "old" Cocoon.java.
Ok, +1 for CocoonBean. Let's keep Cocoon.java as is.
Vadim
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon
Organization (Cocoon plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
>
> <snip/>
>
>>Now, has anyone easily used Cocoon out of a Servlet environment?
>
>
> Ant to build docs - yes. Offline generation is another one used by some
> people.
Ha. *easily* I said.
Peter Donald ov Avalon is not the last programmer on earth, yet he
doesn't know yet that with Cocoon CLI you can supply a list of URLs to
preocess and *not* crawl. I'm 100% sure it's not his fault.
And how about embedding Cocoon in other apps?
>>We need a _CocoonBean_, that becomes the core entry point.
>>You give it a sitemap, input, and it processes the output. Simple as
>
> that.
>
> What's wrong with Cocoon.java? It *is* the entry point. If you don't
> like something in it - let's fix it, why start another /bean/?
Simply because Cocoon.java is not an easy entry point.
Look how Main.java calls it, and you will understand how it's not
user-friendly.
We can fix that instead of making a bean, this is just an implementation
issue. I just thoght that creating a bean would break less stuff that
now is depending on the "old" Cocoon.java.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
<snip/>
> Now, has anyone easily used Cocoon out of a Servlet environment?
Ant to build docs - yes. Offline generation is another one used by some
people.
> We need a _CocoonBean_, that becomes the core entry point.
> You give it a sitemap, input, and it processes the output. Simple as
that.
What's wrong with Cocoon.java? It *is* the entry point. If you don't
like something in it - let's fix it, why start another /bean/?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization
(Cocoon plugins))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Cocoon is simple conceptually.
Cocoon is a beast implementation-wise.
Why?
It's monolithic.
So?
Let's modularize it :-)
-oOo-
To get back to a simple Cocoon, we need to define what Cocoon is.
---------------------
What is Cocoon?
---------------------
Cocoon is a resource processing engine based on XML and written in Java.
/Eh? wasn't it a web application server?/
It's mainly used as such, but it's more general in use.
We can schematize Cocoon as a black box that recieves inputs from an
environment, processes these inputs via XML, and returns resources to
the caller.
These resources can be XML files, HTML files, Excel files, other files,
XML or SQL databases, Web forms, Web services, and whatever can be
transformed in XML for processing. Also non-XMLable resources can be
processed by Cocoon, but the most flexible way passes from XML format.
---------------------
What is the core?
---------------------
Now, has anyone easily used Cocoon out of a Servlet environment?
We need a _CocoonBean_, that becomes the core entry point.
You give it a sitemap, input, and it processes the output. Simple as that.
The Cocoon core is layered in two, the pipelines and the sitemap
selection-action stuff.
---------------------------
What can we do about it?
---------------------------
1) Please take a look at Morphos in jakarta-commons-sandbox.
It's a project that defines pipelines and stages to transform objects
into other objects.
I have already ported the poi HSSF there as a Morpher.
This can be the pipeline part of the core.
2) Use the pipelines into a Sitemap processing system, with
the CocoonBean as the entry-point.
3) Move all implementations in indipendent sub-projects.
4) Make the environments all use the CocoonBean.
5) Separate and document the location phase from the generation phase,
via sources.
Mind me, these are *conceptual* possibilities, on implementations there
will be much yet to decide; also, all this must be done mostly via
refactoring, not via rewriting.
I am using the free4apache Refactorit and it works well :-)
"Groups are allowed to create a branch for release cycles, etc. They are
expected to merge completely back with the main branch as soon as their
release cycle is complete."
If nobody objects, I will branch on 7 August 2002 and start refactoring.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization (Cocoon plugins)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bertrand Delacretaz wrote:
> On Monday 05 August 2002 09:41, Carsten Ziegeler wrote:
>
>>. . .
>>we should try to build a minimal Cocoon or core Cocoon if you
>>prefer and put everything else into additional modules (read: not blocks).
>>By modules I simply mean different directories in the CVS in order to
>>optionally build them.
>>. . .
>
>
> It would be great if these modules could be pluggable at runtime, simply by
> copying the required jars in the right places. Users won't like having to
> recompile Cocoon just to activate different options IMHO.
+1
> I don't know Cocoon internals or Avalon in much detail, but maybe the
> following scenario could be implemented simply and help users locate and add
> the required functionality when they need it:
>
> 1) create an XML map of modules, classnames and URLs that is distributed with
> Cocoon, example:
>
> <plugin-module
> name="xslt-xalan"
> class="org.apache.cocooon.wrappers.XalanWrapper"
> download-url="http://xml.apache.org/cocoon/dist/modules/xalan"
> download-file="cocoon-xalan-plugin.2.0.3.jar"
> />
nice idea
> 2) when a Component is requested from the Sitemap and is not available, a
> custom ClassLoader (or a catch of the ClassNotFoundException) uses the
> above map to let users know how to activate it, something like:
>
> CocoonPluginNotFoundException:
> The "xslt-xalan" plugin (requested by blablabla...) is not present in your
> Cocoon configuration. To activate it, download file
> "cocoon-xalan-plugin.2.0.3.jar" from
> "http://xml.apache.org/cocoon/dist/modules/xalan", copy this jar to the
> WEB-INF/lib subdirectory of your Cocoon installation and restart Cocoon
>
> I don't know how well this fits your plans, but it might help distributing a
> minimal Cooon while making it easy for users to install what they need.
Also this can be done, but the most important thing is now getting the
reorganization done, then what you envision could become reality :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Friday 16 August 2002 16:59, Giacomo Pati wrote:
>. . .
> Wasn't my explanation of a skip/access/webmail block recently enough?
FYI I have added your example to the "blocks use cases" page at CocoDocoWiki:
http://outerthought.net/wiki/Wiki.jsp?page=BlocksUseCases
Hopefully having several examples/wishlists there will help.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
>
> On Mon, 19 Aug 2002, Carsten Ziegeler wrote:
>
> >
> > Giacomo Pati wrote:
> > > >
> > > > I'm still looking for a real example that makes use of a
> > > > 'skin block' or a 'portal block' or something like that -
> or in other
> > > > words, an example which really uses all the features (and
> ideas) of the
> > > > blocks concept and not only a part of it.
> > >
> > > Wasn't my explanation of a skip/access/webmail block recently enough?
> > >
> > Sorry, must have missed that - do you have a pointer available?
>
> Look at
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102941595120561&w=2
>
Thanks for the pointer, Giacomo.
But I must insist, that this example is far too vague for me: we have
three cobs and they all live forever happy together. point.
But how does this really look like in the sitemap?
How does the communication between the cobs take place?
Does it really work? Is it practical?
What is the drawback, perhaps performance?
I know, creating such an example is a lot of work, but currently without
that, I can't judge if blocks are really usefull. And this could help
in showing the difference between blocks and modules.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Giacomo Pati <gi...@apache.org>.
On Mon, 19 Aug 2002, Carsten Ziegeler wrote:
>
> Giacomo Pati wrote:
> > >
> > > I'm still looking for a real example that makes use of a
> > > 'skin block' or a 'portal block' or something like that - or in other
> > > words, an example which really uses all the features (and ideas) of the
> > > blocks concept and not only a part of it.
> >
> > Wasn't my explanation of a skip/access/webmail block recently enough?
> >
> Sorry, must have missed that - do you have a pointer available?
Look at
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102941595120561&w=2
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
> >
> > I'm still looking for a real example that makes use of a
> > 'skin block' or a 'portal block' or something like that - or in other
> > words, an example which really uses all the features (and ideas) of the
> > blocks concept and not only a part of it.
>
> Wasn't my explanation of a skip/access/webmail block recently enough?
>
Sorry, must have missed that - do you have a pointer available?
Thanks,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 16 Aug 2002, Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote:
> >
> > On Friday 16 August 2002 07:58, Carsten Ziegeler wrote:
> > >. . .
> > > The blocks RT sounds great, but I'm also interested in a real example
> > > which shows the usage of blocks
> > >. . .
> >
> > I think you were talking about the inner working of Blocks, but
> > from a user
> > point of view I have written a (dream?) use-case over at CocoDocoWiki:
> > http://outerthought.net/wiki/Wiki.jsp?page=BlocksUseCases - maybe such
> > examples help reaching a common understanding?
> >
> Hmm, ok, I think this is actually the problem about blocks - everyone
> understands it in a different way - although we refer to the same RT.
>
> I think, what you describe is more a 'module feature' and not so much
> the 'big blocks concept' - although your wish list should be possible
> with the blocks concept.
>
> I'm still looking for a real example that makes use of a
> 'skin block' or a 'portal block' or something like that - or in other
> words, an example which really uses all the features (and ideas) of the
> blocks concept and not only a part of it.
Wasn't my explanation of a skip/access/webmail block recently enough?
Giacomo
>
> > (And sorry I cannot help about the fueling stations at this time
> > - maybe you
> > could move to Australia, they have them on the other side there ;-)
> >
> ROTFL
>
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
>
> On Friday 16 August 2002 07:58, Carsten Ziegeler wrote:
> >. . .
> > The blocks RT sounds great, but I'm also interested in a real example
> > which shows the usage of blocks
> >. . .
>
> I think you were talking about the inner working of Blocks, but
> from a user
> point of view I have written a (dream?) use-case over at CocoDocoWiki:
> http://outerthought.net/wiki/Wiki.jsp?page=BlocksUseCases - maybe such
> examples help reaching a common understanding?
>
Hmm, ok, I think this is actually the problem about blocks - everyone
understands it in a different way - although we refer to the same RT.
I think, what you describe is more a 'module feature' and not so much
the 'big blocks concept' - although your wish list should be possible
with the blocks concept.
I'm still looking for a real example that makes use of a
'skin block' or a 'portal block' or something like that - or in other
words, an example which really uses all the features (and ideas) of the
blocks concept and not only a part of it.
> (And sorry I cannot help about the fueling stations at this time
> - maybe you
> could move to Australia, they have them on the other side there ;-)
>
ROTFL
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Friday 16 August 2002 07:58, Carsten Ziegeler wrote:
>. . .
> The blocks RT sounds great, but I'm also interested in a real example
> which shows the usage of blocks
>. . .
I think you were talking about the inner working of Blocks, but from a user
point of view I have written a (dream?) use-case over at CocoDocoWiki:
http://outerthought.net/wiki/Wiki.jsp?page=BlocksUseCases - maybe such
examples help reaching a common understanding?
(And sorry I cannot help about the fueling stations at this time - maybe you
could move to Australia, they have them on the other side there ;-)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Andrew C. Oliver wrote:
>
> As I understand it Blocks are a solution to world hunger, documentation,
> complexity, the meaning of life and why
> the local bars and taxi companies in many college towns close
> simultaneously at 2:00am.
>
And does it also answer the question "Why are fueling stations always on
the wrong site of the street?" - This is a real world problem, I faced
too often in the last days.
> I'd like to see Blocks matched to WHAT they solve (Show cause and
> effect), totally what they are, how they match
> to the *blocks* implemented by other projects (Like James I
> believe)...etc.
>
The blocks RT sounds great, but I'm also interested in a real example
which shows the usage of blocks - the current description is for me
a little bit vague. It doesn't detail how communication between different
blocks really takes place etc.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
+1 -- -
As I understand it Blocks are a solution to world hunger, documentation,
complexity, the meaning of life and why
the local bars and taxi companies in many college towns close
simultaneously at 2:00am.
I'd like to see Blocks matched to WHAT they solve (Show cause and
effect), totally what they are, how they match
to the *blocks* implemented by other projects (Like James I believe)...etc.
-Andy
Leigh Dodds wrote:
>>This was one of the core issues Cocoon Blocks should solve in the end.>
>>Giacomo
>>
>>
>
>As an irregular member of this list, I keep seeing 'Blocks' being mentioned
>(usually as the solution to all kinds of problems! :)
>
>Can anyone point me to some documentation, list discussion threads, or
>even scratchpad stuff that describes/demonstrates what Blocks actually
>are?
>
>I'd like to get this into the Wiki.
>
>Cheers,
>
>L.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
But WHAT problems does it solve? Can we drill down into a bit more detail?
-andy
Bertrand Delacretaz wrote:
>On Monday 12 August 2002 12:13, Leigh Dodds wrote:
>
>
>>Can anyone point me to some documentation, list discussion threads, or
>>even scratchpad stuff that describes/demonstrates what Blocks actually
>>are?
>>
>>
>
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>might be a good starting point.
>
>-Bertrand
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 12 August 2002 12:13, Leigh Dodds wrote:
> Can anyone point me to some documentation, list discussion threads, or
> even scratchpad stuff that describes/demonstrates what Blocks actually
> are?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
might be a good starting point.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by Giacomo Pati <gi...@apache.org>.
On Mon, 12 Aug 2002, Leigh Dodds wrote:
> > This was one of the core issues Cocoon Blocks should solve in the end.>
> > Giacomo
>
> As an irregular member of this list, I keep seeing 'Blocks' being mentioned
> (usually as the solution to all kinds of problems! :)
>
> Can anyone point me to some documentation, list discussion threads, or
> even scratchpad stuff that describes/demonstrates what Blocks actually
> are?
One major point is that Cocoon scales good from the sitemap point of view
(root-sitemap -> sub-sitemap -> ... -> sub-sitemap) but does not on the
Component level (one single cocoon.xconf). Everybody which ever tried to
integrate a Cocoon application which comes with its own Avalon Components
into an already running Cocoon system knows what I am talking about.
You need to merge those new Components into the cocoon.xconf file for
every new application you'd like to deploy in the same Cocoon system and
this can grow into a maintainance nightmare.
The other point Cocoon Blocks (COB) will solve is modularisation. Consider
the following.
1. There is a COB interface defined about skinning application data
of defined XSchemas (navigations, menues, content) by transformations
(i.e. XSLT) into something else (i.e. HTML)
2. There is a COB interface defined about accessing mail messages which
generates defined XSchemas of mail messages and mail folders from mail
stores like IMAP, POP, mboxes or "write your own"
3. There is a COB which offers an WebMail application which depends on
- a skinning COB
- a mail message accessing COB
Now, when someone likes to deploy the WebMailCOB it uses the Cocoon COB
management application which asks for a URI to the COB to deploy. As a COB
will have meta data inside, the management console will be able to ask for
configuration data for the COB and also knows of unresolved dependancies
to other COBs. So the deployer of the WebMailCOB will be asked where the
dependant skin and access COBs are. Now, the management console could
offer implementations for them from a well known site like cob.apache.org
(URL will be configurable of course) which have been registered there. Now
you can select the Christmas skin COB and the IMAP access COB from the
list and configure them to have your WebMail ready and running.
And now you will be free to use other skin COBs in terms of minutes or you
can write your own to achieve "corporate identity". You have your mails
stored in a database and there is no COB for it? Write your own and have
them be served by the WebMailCOB.
So, Cocoon Blocks will not be "the solution to all kinds of problems" as
you might have heared. But it will ease deployment of several "modules"
into one single Cocoon system.
Stefano and I also used the term "naked Cocoon" which sould be a war file
that comes with nothing but what is needed to run the COB management
application. This enables users to start with it and deploy COBs to have
something running by Cocoon.
Hope this and the link Bertrand mentioned in an other mail in this thread
will help understand what Cocoon Blocks should solve.
Giacomo
> I'd like to get this into the Wiki.
>
> Cheers,
>
> L.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Cocoon Blocks
Posted by Leigh Dodds <ld...@ingenta.com>.
> This was one of the core issues Cocoon Blocks should solve in the end.>
> Giacomo
As an irregular member of this list, I keep seeing 'Blocks' being mentioned
(usually as the solution to all kinds of problems! :)
Can anyone point me to some documentation, list discussion threads, or
even scratchpad stuff that describes/demonstrates what Blocks actually
are?
I'd like to get this into the Wiki.
Cheers,
L.
--
Leigh Dodds
http://weblogs.userland.com/eclectic
"Pluralitas non est ponenda sine necessitate" -- William of Ockham
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization (Cocoon plugins)
Posted by Giacomo Pati <gi...@apache.org>.
This was one of the core issues Cocoon Blocks should solve in the end.
Giacomo
On Mon, 5 Aug 2002, Bertrand Delacretaz wrote:
> On Monday 05 August 2002 09:41, Carsten Ziegeler wrote:
> >. . .
> > we should try to build a minimal Cocoon or core Cocoon if you
> > prefer and put everything else into additional modules (read: not blocks).
> > By modules I simply mean different directories in the CVS in order to
> > optionally build them.
> >. . .
>
> It would be great if these modules could be pluggable at runtime, simply by
> copying the required jars in the right places. Users won't like having to
> recompile Cocoon just to activate different options IMHO.
>
> I don't know Cocoon internals or Avalon in much detail, but maybe the
> following scenario could be implemented simply and help users locate and add
> the required functionality when they need it:
>
> 1) create an XML map of modules, classnames and URLs that is distributed with
> Cocoon, example:
>
> <plugin-module
> name="xslt-xalan"
> class="org.apache.cocooon.wrappers.XalanWrapper"
> download-url="http://xml.apache.org/cocoon/dist/modules/xalan"
> download-file="cocoon-xalan-plugin.2.0.3.jar"
> />
>
> 2) when a Component is requested from the Sitemap and is not available, a
> custom ClassLoader (or a catch of the ClassNotFoundException) uses the
> above map to let users know how to activate it, something like:
>
> CocoonPluginNotFoundException:
> The "xslt-xalan" plugin (requested by blablabla...) is not present in your
> Cocoon configuration. To activate it, download file
> "cocoon-xalan-plugin.2.0.3.jar" from
> "http://xml.apache.org/cocoon/dist/modules/xalan", copy this jar to the
> WEB-INF/lib subdirectory of your Cocoon installation and restart Cocoon
>
> I don't know how well this fits your plans, but it might help distributing a
> minimal Cooon while making it easy for users to install what they need.
>
> Just my 2 cents.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization (Cocoon plugins)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 05 August 2002 09:41, Carsten Ziegeler wrote:
>. . .
> we should try to build a minimal Cocoon or core Cocoon if you
> prefer and put everything else into additional modules (read: not blocks).
> By modules I simply mean different directories in the CVS in order to
> optionally build them.
>. . .
It would be great if these modules could be pluggable at runtime, simply by
copying the required jars in the right places. Users won't like having to
recompile Cocoon just to activate different options IMHO.
I don't know Cocoon internals or Avalon in much detail, but maybe the
following scenario could be implemented simply and help users locate and add
the required functionality when they need it:
1) create an XML map of modules, classnames and URLs that is distributed with
Cocoon, example:
<plugin-module
name="xslt-xalan"
class="org.apache.cocooon.wrappers.XalanWrapper"
download-url="http://xml.apache.org/cocoon/dist/modules/xalan"
download-file="cocoon-xalan-plugin.2.0.3.jar"
/>
2) when a Component is requested from the Sitemap and is not available, a
custom ClassLoader (or a catch of the ClassNotFoundException) uses the
above map to let users know how to activate it, something like:
CocoonPluginNotFoundException:
The "xslt-xalan" plugin (requested by blablabla...) is not present in your
Cocoon configuration. To activate it, download file
"cocoon-xalan-plugin.2.0.3.jar" from
"http://xml.apache.org/cocoon/dist/modules/xalan", copy this jar to the
WEB-INF/lib subdirectory of your Cocoon installation and restart Cocoon
I don't know how well this fits your plans, but it might help distributing a
minimal Cooon while making it easy for users to install what they need.
Just my 2 cents.
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal] Cocoon Organization
Posted by Stephan Michels <st...@apache.org>.
> Now, I'm pretty sure, that some might now stand up and say: "Hey, Carsten,
> you know what? Cocoon is open source, so if you see a need, you can
> contribute and fix it." Well, that's the individual approach we were
> following in the last months. And does it really work? Or someone will
> say "Hey, it's alpha, what do you expect?"...
>
> And one final note:
> Just do a simple performance test: create a pipeline reading an xml file
> transform this in two steps with two xslt transformers and serialize it
> to html (or xml if you want). Do a stress test on the same machine
> using Cocoon 2.0, 2.0.1, 2.0.2, 2.0.3 and 2.1-dev. (I don't know
> the answer to this test, but I would bet a book on the result).
A simple wget job, which I tried, breaks a Cocoon instance mit a
OutOfMemoryException. I had also problems with NPE from the
AbstractCachingProcessingPipeline with the ValidityObjects. The commit
from Huber prevents the NPE, but didn't solves the problem, I think.
So, I totally agree with your comments.
> So, whew, you see I had some time to prepare this email...and now
> the flame-war can begin...
>
> But summarizing this: +1 on Berins idea.
+1.
I took some of my time to remove the deprecated classes and methods, like
the Loggable IF. At the moment I try to change the implementation to
use the Excalibur LoggerManager instead of the Logkitmanager.
There are also the deprecated SourceHandler classes. In the past I have
rewritten the XMLDBSource to use the Excalibur Source interfaces, which
could went from the scratchpad into the main trunk.
I hope through these changes we can remove the deprecated classes, to
reduce the count of classes and execution time.
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal] Cocoon Organization
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi everyone,
I also thought about this problem in the last weeks (during some
mountain climbing...) - does anyone remember Stefano's email
about the "thermal death"? If not, search the archive and read it.
Yes, Berin is absolutely right - Cocoon is way too big. And it's
getting bigger and bigger. For usual web applications I guess
you always only need let's say 20% of Cocoon - it's not always
the same parts you need but you will never need everything of
Cocoon at once (ok, never say never, I know).
When we made our donation for the authentication and the portal
framework, I tried to separate them as much as possible. You can
build and use Cocoon without them and later additionally plug
them in. (At least this is the way it should work ;) )
For other "parts" like FOP serialization etc this is also possible.
But what for some "more core areas" like flowmaps or input modules?
And I fear there are other things which only (currently) a minority
really needs (and yes, add the authentication and portal frameworks
to this list).
In the last months the answer to this problem was always: blocks!
So making Cocoon (just) one step complexer makes it more handable
and easier to understand...really? If you look at the problems
the average user of Cocoon has, then you see that most of them
have problems understanding the complexity of Cocoon and getting
simply started. IMHO this can't be solved by just adding another
complexity layer. (This is not a -1 vote for blocks).
Let's have a look at what had happened over the last weeks/months:
several individuals added more and more features, like the authentication
framework, the portal framework, the form handling, the flow maps etc.
Each individual did not really care about the community, he only wanted
to get this cool feature working. And don't get me wrong, this includes
myself. We also started the "documentation project" and we "fought" with
others who claimed about the poor documentation and Cocoon being too
complex.
In addition we are getting more and more RTs, patches and bug reports which
all get more or less lost (or again simply add more complexity).
So currently I see us as a very motivated group of individuals all doing
their job (very good by the way) but not considering to act on a more
community base. For example - to not offend others, I take myself as an
example - the portal framework: In order to get it nicely working with
some very cool portal/configuration features, I needed some other new
features
besides the portal framework in Cocoon. This includes the
RequestLifecycle, the ConfigurableSitemapComponents and some other minor
things. Who of you knows what these concepts are? Did I ask someone, if this
really makes sense? Are they documented well? etc.
Now I think we really did some mistakes (and yes, this again includes
myself).
To proof this, here are some questions (and please, they are not meant to be
answered):
- Who of the Cocoon community knows how the portal framework works?
- Who of the Cocoon community knows how the authentication framework works?
- What's the status in form handling?
- Do we need input modules?
- Do we have memory leaks?
- Is the caching really working?
- Does Cocoon work with JDK 1.4?
- What has to be done for the next release, 2.0.4 or 2.1?
But the most important question is: who needs all these new features?
Shouldn't we focus on getting a even more stable release and more
documentation instead? Who needs a portal framework inside Cocoon, who needs
input modules and who needs blocks?
Let's take the blocks concept as another example. We have the really great
RT from Stefano and Giacomo, but look how many have responded to it. Do they
not care about blocks? Couldn't they follow the RT? Are blocks really
necessary?
I personally didn't answer the blocks RT, because I feel that it is not the
concept I (= Individual!) was looking for, but I can't express how it could
be better.
Or flowmaps? What is their use? If I didn't understand the sitemap, how will
I ever learn about flowmaps?
Ok, I know, one answer to this will be, if you don't want to use blocks or
flowmaps, you don't have to. But how does this work? Will we state: "Cocoon
has
the sitemap, flowmaps and blocks. But don't worry, if this is too
complex for you, just use only the sitemap and forget about the others, you
don't
need them...". Well...
Many users already claim, Cocoon is too complex. And we say: it will get
easier, because we add more cool features, like a portal framework, flowmaps
and blocks to it! Now, I don't believe this and I fear the usual user will
not believe this, too.
Stefano already pointed at this in his thread about the "termal death of
Cocoon."
When he wrote that, I thought, "hmm, perhaps he's right - perhaps not, ah
wait,
how can I get this authentication thing working, hm, let's see..." - Now I
know,
he is right - if we go on following this road, I promise, we will have a
termal
death of Cocoon more sooner than later. And I think, the current blocks
discussion does not help in this aspect.
So what can we do about it? Try to act more like a team and let's more
listening
to the user needs. The documentation effort is one step in this direction,
but
personally I think there is a problem there, too. New documentation features
are currently delayed until forrest is ready! So, instead of focusing on the
real problem, a new construction area has been build up (forrest) which has
to be
completed beforehand! This is not very helpfull.
But let's come back, to what we can do.
First of all, a feature stop! I don't mean an RT stop.
Second, thinking of SoC (ok, perhaps not the right context to use this
term) - we should try to build a minimal Cocoon or core Cocoon if you prefer
and put everything else into additional modules (read: not blocks). By
modules I simply mean different directories in the CVS in order to
optionally build them. Let's remove the authentication framework from the
core, the form handling, the input modules, the flow map, the fop serializer
etc - simply everything which is not necessary to run Cocoon.
Third, let's identify the issues for the upcomming releases.
Fourth, let's search for volunteers for the open issues, for bug fixing and
for testing!
Fifth, discuss the available patches and open RTs and make proposal
documents out of them.
Or putting it in other words: Let's not forget the users needs over all
this cool new features and RTs.
Now, I'm pretty sure, that some might now stand up and say: "Hey, Carsten,
you know what? Cocoon is open source, so if you see a need, you can
contribute and fix it." Well, that's the individual approach we were
following in the last months. And does it really work? Or someone will
say "Hey, it's alpha, what do you expect?"...
And one final note:
Just do a simple performance test: create a pipeline reading an xml file
transform this in two steps with two xslt transformers and serialize it
to html (or xml if you want). Do a stress test on the same machine
using Cocoon 2.0, 2.0.1, 2.0.2, 2.0.3 and 2.1-dev. (I don't know
the answer to this test, but I would bet a book on the result).
So, whew, you see I had some time to prepare this email...and now
the flame-war can begin...
But summarizing this: +1 on Berins idea.
Carsten
Berin Loritsch wrote:
>
>
> Currently Cocoon is 1.5 MB in size. That is a huge jar. In Cocoon
> there
> are the core files, the servlet compatibility files, the CLI
> compatibility
> files, and hundreds of components.
>
> The fact that we as a community are thriving is excellent. However, as
> a
> project, Cocoon is feeling quite heavy. Esp. since there are features
> in
> Cocoon that not everyone needs. I proposed this a while back, but I am
> going to propose it again.
>
> We should split Cocoon into core development and component development
> efforts, much like Avalon does with Framework and Excalibur. That will
> allow the components to be packaged in jars that serve a similar
> purpose.
> Things like all the database related components should be in their own
> mini-project. Each mini-project has its own documentation, and its own
> life. It also allows each mini-project to determine whether it is ready
> for prime-time or not. At every release, the core cocoon does not have
> to worry about which components it has to move into scratchpad. Also
> each set of components has a little focused mini-community so the docs
> get upgraded in a focused manner.
>
> I have already seen the benefits of how this works in Excalibur--now
> that
> we are going through systematically.
>
> When I am generating a site, I don't want to have to include the portal
> components or the DB and auth components. Those don't need to be there
> for the site.
>
> Keep in mind that the mini-projects are all part of the cocoon umbrella,
> and they foster functioning communities within the larger Cocoon
> community,
> not detract from it.
>
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal] Cocoon Organization
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Currently Cocoon is 1.5 MB in size. That is a huge jar.
(OT) You ought to work for BEA for a while - their jar is 38Mb ;)
> In Cocoon there
> are the core files, the servlet compatibility files, the CLI
> compatibility files,
CLI: 25432 bytes
Servlet: 36325 bytes
Do you *really* feel that these are candidates for separation?
(I don't feel comfortable imagining myriads (>5) of small (~10-30Kb)
jars)
> and hundreds of components.
Possible candidates here are:
POI serializer: ~160Kb
XSP: ~130Kb
The rest is either really small or belongs to the core.
> The fact that we as a community are thriving is excellent. However,
as
> a
> project, Cocoon is feeling quite heavy. Esp. since there are features
> in
> Cocoon that not everyone needs. I proposed this a while back, but I
am
> going to propose it again.
>
> We should split Cocoon into core development and component development
> efforts, much like Avalon does with Framework and Excalibur. That
will
> allow the components to be packaged in jars that serve a similar
> purpose.
> Things like all the database related components should be in their own
> mini-project.
I do not have anything against database stuff in separate jar.
> Each mini-project has its own documentation, and its own
> life. It also allows each mini-project to determine whether it is
ready
> for prime-time or not. At every release, the core cocoon does not
have
> to worry about which components it has to move into scratchpad. Also
> each set of components has a little focused mini-community so the docs
> get upgraded in a focused manner.
>
> I have already seen the benefits of how this works in Excalibur--now
> that we are going through systematically.
>
> When I am generating a site, I don't want to have to include the
portal
> components or the DB and auth components. Those don't need to be
there
> for the site.
>
> Keep in mind that the mini-projects are all part of the cocoon
umbrella,
> and they foster functioning communities within the larger Cocoon
> community, not detract from it.
What do you think about Cocoon applications subprojects, proposed here
recently?
Vadim
>
> "They that give up essential liberty to obtain a little temporary
safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> Sounds a good idea - but *please* lets make sure it's still easy to
> download and build everything. I don't think I'm alone in finding
> Avalon building hard to get to grips with.
+1
>
> Stuart.
>
> Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck
> (Adolos)
> Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD
> 65AF
> ------------------------------------------------------------------------
> -
> Stuart Roebuck
> stuart.roebuck@adolos.com
> Systems Architect Java, XML, MacOS X, XP,
> etc.
> ADOLOS
> <http://www.adolos.com/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] Cocoon Organization
Posted by Stuart Roebuck <st...@adolos.co.uk>.
On Wednesday, July 31, 2002, at 02:27 pm, Berin Loritsch wrote:
> Currently Cocoon is 1.5 MB in size. That is a huge jar. In Cocoon
> there
> are the core files, the servlet compatibility files, the CLI
> compatibility
> files, and hundreds of components.
>
> The fact that we as a community are thriving is excellent. However, as
> a
> project, Cocoon is feeling quite heavy. Esp. since there are features
> in
> Cocoon that not everyone needs. I proposed this a while back, but I am
> going to propose it again.
>
> We should split Cocoon into core development and component development
> efforts, much like Avalon does with Framework and Excalibur. That will
> allow the components to be packaged in jars that serve a similar
> purpose.
Sounds a good idea - but *please* lets make sure it's still easy to
download and build everything. I don't think I'm alone in finding
Avalon building hard to get to grips with.
Stuart.
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck
(Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD
65AF
------------------------------------------------------------------------
-
Stuart Roebuck
stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS
<http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org