You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <ug...@apache.org> on 2004/07/20 23:35:45 UTC
The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
> think so too, just needs more wild thinking and somebody doing :-)
Since I'm getting more and more bored with my daytime job, I ended up
doing something:
http://wiki.apache.org/cocoon/ButterflyManifesto
Comments are welcome, flames > /dev/null.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 21/lug/04, alle 17:49, Marc Portier ha scritto:
> regarding the blocks issue however we will also need to cover
> classloading-shielding (spring doesn't do it afaik) and I'ld really
> like us to do that based on jars in a merlin-like repo (just like
> merlin does it)
>
> (actually I need something like that for my -not so boring- job by the
> end of this year somewhat)
>
>
> in any case, (as much as time allows) I'ld like to be following and
> helping out where appropriate, you're in the spot to arrange the
> agenda though...
Since Rod has offered his help, how about joining the spring dev list
and making our needs known there?
Ugo
--
Ugo Cei - http://beblogging.com/
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Marc Portier <mp...@outerthought.org>.
Ugo Cei wrote:
> Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
>
>> think so too, just needs more wild thinking and somebody doing :-)
>
>
> Since I'm getting more and more bored with my daytime job, I ended up
> doing something:
>
> http://wiki.apache.org/cocoon/ButterflyManifesto
>
> Comments are welcome, flames > /dev/null.
>
boredom is a great motivator!
given your earlier pro-spring posts I assume you want to (initially)
attack this from that angle?
regarding the blocks issue however we will also need to cover
classloading-shielding (spring doesn't do it afaik) and I'ld really like
us to do that based on jars in a merlin-like repo (just like merlin does
it)
(actually I need something like that for my -not so boring- job by the
end of this year somewhat)
in any case, (as much as time allows) I'ld like to be following and
helping out where appropriate, you're in the spot to arrange the agenda
though...
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
RE: How to document - need help with publishing
Posted by "Pavel.Vrecion" <Pa...@syntea.cz>.
I have created xml version of how-to document and I have post it through
Bugzilla.
Hopefully it is in the right format, now.
English is not my mother tongue. I would appreciate if somebody will check
my wordings. Any volunteers?
thnx
Pavel
------- Additional Comments From crossley@apache.org 2004-07-23 07:52
------- I cannot see the content unfortunately, because i do not work with
M$ word documents. The howto documents in Cocoon core documentation are in
xml format.
See the guidelines at
http://cocoon.apache.org/2.1/howto/howto-author-howto.html
If you cannot manage to do that, then perhaps you can encourage someone on
the users list to help. Provide the URL to this Bugzilla issue 30253.
Your other alternative is to add the content as a separate wiki page at
http://wiki.apache.org/cocoon/HowTos
RE: How to document - need help with publishing
Posted by David Crossley <cr...@apache.org>.
Pavel.Vrecion wrote:
> Thanx for help.
> It is clear, now.
>
> It took me some time to understand that in Bugzilla attachments can be added
> only after bug is submitted, and not as a part of submitting bug process.
> Steps for posting a new documentation are a little bit complex (for the
> first time), but on the other hand they are well described in Contribution
> how-to.
>
> But I would like to share my fresh experience of first-time contributor:
Thanks, this is excellent feedback.
> - logical starting point is http://cocoon.apache.org/ so you start here
> - then you find on the left side menu item named Community/Contributing,
> that's it, so click on it.
> - There is a chapter called "Contributions of Code and Documentation", so
> far so good, fast and straightforward
> - You find here some hints about writing internal cocoon documentations, but
> it seems that it is not your case. Then you find a link to Procedure for
> "Raising Development Issues". Here you get advice to join dev mailing list,
> or go to Bugzilla, where you find nothing obvious about document
> contributions.
Yeah sorry. Actually this whole section needs to be tidied sometime.
> - after reading Contribution how-to it is clear.
>
> The process works fine (from the user point of view) for bug reporting and
> probably for Cocoon code contributions. But for supportive and general
> purpose documentations the procedure is more hidden.
Well it should be the same procedure.
> I think that adding
> simple sentence to "Contributions of Code and Documentation" section,
> something like "If you want to contribute with tutorial, code snippet, case
> study or how-to, read ...", will help.
I have added some words to both of those sections of contrib.html
to try to help clarify. Also added a new task to Bugzilla to be
more clear about the whole procedure.
Thanks for your effort.
--
David Crossley
RE: How to document - need help with publishing
Posted by "Pavel.Vrecion" <Pa...@syntea.cz>.
Thanx for help.
It is clear, now.
It took me some time to understand that in Bugzilla attachments can be added
only after bug is submitted, and not as a part of submitting bug process.
Steps for posting a new documentation are a little bit complex (for the
first time), but on the other hand they are well described in Contribution
how-to.
But I would like to share my fresh experience of first-time contributor:
- logical starting point is http://cocoon.apache.org/ so you start here
- then you find on the left side menu item named Community/Contributing,
that's it, so click on it.
- There is a chapter called "Contributions of Code and Documentation", so
far so good, fast and straightforward
- You find here some hints about writing internal cocoon documentations, but
it seems that it is not your case. Then you find a link to Procedure for
"Raising Development Issues". Here you get advice to join dev mailing list,
or go to Bugzilla, where you find nothing obvious about document
contributions.
- after reading Contribution how-to it is clear.
The process works fine (from the user point of view) for bug reporting and
probably for Cocoon code contributions. But for supportive and general
purpose documentations the procedure is more hidden. I think that adding
simple sentence to "Contributions of Code and Documentation" section,
something like "If you want to contribute with tutorial, code snippet, case
study or how-to, read ...", will help.
Pavel Vrecion
-----Original Message-----
From: David Crossley [mailto:crossley@apache.org]
Sent: Thursday, July 22, 2004 11:30 AM
To: dev@cocoon.apache.org
Cc: Pavel.Vrecion
Subject: Re: How to document - need help with publishing
Pavel.Vrecion wrote:
> I know, that this subject is slightly off-topic for this mail list, but
...
No! It is right on topic, on either dev or user list.
Bear in mind that most devs also participate on the
user list.
> I wrote a how-to document, which will be good (if you agree with me) to be
> published on Cocoon web pages (Documentation - HOW-TO section).
> I have not found any obvious way, how to post my small contribution.
Then we had better fix our main documentation, because you
should be able to easily find out how. More below ...
> Nevertheless I have spent full day on it, and I do not want
> to throw it out of my window(s) :-).
> Can anybody help me to get it on Cocoon pages? I am lost.
> Please..
>
> Pavel Vrecion
>
> Document and example application are attached
Gee, please don't send attachments to the mailing list.
Didn't we already discuss how to contribute.
(I hope that i don't come across as angry, because i am not.
These are constructive comments.)
If you find Bugzilla difficult, then please see
http://cocoon.apache.org/2.1/howto/index.html#Contribution
(Sorry, certain How-To documents should be at a higher level
of the website.)
There are many reasons for *not* sending attachments to the
mailing list. Here are some ...
* The contribution will often get lost in the volume of other
topics and mailing.
* Every cocoon dev does not want or need a copy of the attachments
in their local mail archives.
* The issue tracker, Bugzilla, reminds us of the many jobs that
we need to do.
Finally, of course, thanks for your contribution.
--
David Crossley
Re: How to document - need help with publishing
Posted by David Crossley <cr...@apache.org>.
Pavel.Vrecion wrote:
> I know, that this subject is slightly off-topic for this mail list, but ...
No! It is right on topic, on either dev or user list.
Bear in mind that most devs also participate on the
user list.
> I wrote a how-to document, which will be good (if you agree with me) to be
> published on Cocoon web pages (Documentation - HOW-TO section).
> I have not found any obvious way, how to post my small contribution.
Then we had better fix our main documentation, because you
should be able to easily find out how. More below ...
> Nevertheless I have spent full day on it, and I do not want
> to throw it out of my window(s) :-).
> Can anybody help me to get it on Cocoon pages? I am lost.
> Please..
>
> Pavel Vrecion
>
> Document and example application are attached
Gee, please don't send attachments to the mailing list.
Didn't we already discuss how to contribute.
(I hope that i don't come across as angry, because i am not.
These are constructive comments.)
If you find Bugzilla difficult, then please see
http://cocoon.apache.org/2.1/howto/index.html#Contribution
(Sorry, certain How-To documents should be at a higher level
of the website.)
There are many reasons for *not* sending attachments to the
mailing list. Here are some ...
* The contribution will often get lost in the volume of other
topics and mailing.
* Every cocoon dev does not want or need a copy of the attachments
in their local mail archives.
* The issue tracker, Bugzilla, reminds us of the many jobs that
we need to do.
Finally, of course, thanks for your contribution.
--
David Crossley
How to document - need help with publishing
Posted by "Pavel.Vrecion" <Pa...@syntea.cz>.
I know, that this subject is slightly off-topic for this mail list, but ...
I wrote a how-to document, which will be good (if you agree with me) to be
published on Cocoon web pages (Documentation - HOW-TO section).
I have not found any obvious way, how to post my small contribution.
Nevertheless I have spent full day on it, and I do not want to throw it out
of my window(s) :-).
Can anybody help me to get it on Cocoon pages? I am lost.
Please..
Pavel Vrecion
Document and example application are attached
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 22/lug/04, alle 08:30, Reinhard Poetz ha scritto:
> I think it will be a question of doing it. If Ugo presents a
> functional prototyp of Spring that supports Real Blocks and which can
> be made backwards compatible to 2.1 sitemaps and flowscripts I
> wouldn't have arguments against it :-)
My aim is to implement a functional protoptype that supports sitemaps
and flowscripts. Implementing Real Blocks is the long-range target but
don't expect me to reach it by myself :-).
> Some words to the ButterflyManifesto: IMHO it has a clear focus on
> "technical excellence". The point missing (IMHO) is that we have a
> large user base with many, many applications running on Cocoon 2.x. It
> is very important to make their move to Cocoon NG as simple as
> possible so that they don't have to redo all the work. I think this
> means at least support for Sitemaps and Flowscripts and support for
> existing components in a legacy mode.
>
> (I know repeating this over and over again is boring but sometimes I
> have the feeling that this is forgotten ...)
It's not missing, it's explicitly set aside (1.4.4. Don't be dragged
down by backward compatibility). Now, I agree that some migration path
will have to be provided and the easier the better. But we shouldn't
let these considerations limit too much our creativity. All of this is
very very IMHO of course and the actual degree of backward
compatibility will have do be discussed in depth.
One thing that I'd like to see go away (or be supported only in
"legacy" mode) is the sitemap syntax. I'm fed up with pointy brackets,
can't we have less clutter? ;-)
Ugo
--
Ugo Cei - http://beblogging.com/
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
>Reinhard Poetz wrote:
>
>
>
>>I think it will be a question of doing it.
>>
>>
>:)
>
>
>
>>If Ugo presents a
>>functional prototyp of Spring that supports Real Blocks and
>>which can be made backwards compatible to 2.1 sitemaps and
>>flowscripts I wouldn't have arguments against it :-)
>>
>>
>>
>Yepp.
>
>
>
>>Is anyone else working on an alternative these days?
>>(Carsten, Pier ???)
>>
>>
>
>No, not me, my focus was to implement everything else we wanted
>to have for 2.2 except blocks; but it seems that even the innocent
>looking VPCs are way too complicated :(
>
>
Just do it ;-) and then we can talk about all those details like should
we throw an exception if an action tries to redirect or not.
--
Reinhard
RE: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
> I think it will be a question of doing it.
:)
> If Ugo presents a
> functional prototyp of Spring that supports Real Blocks and
> which can be made backwards compatible to 2.1 sitemaps and
> flowscripts I wouldn't have arguments against it :-)
>
Yepp.
> Is anyone else working on an alternative these days?
> (Carsten, Pier ???)
No, not me, my focus was to implement everything else we wanted
to have for 2.2 except blocks; but it seems that even the innocent
looking VPCs are way too complicated :(
Carsten
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Reinhard Poetz <re...@apache.org>.
Stefano Mazzocchi wrote:
> Ugo Cei wrote:
>
>> Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
>>
>>> think so too, just needs more wild thinking and somebody doing :-)
>>
>>
>>
>> Since I'm getting more and more bored with my daytime job, I ended up
>> doing something:
>>
>> http://wiki.apache.org/cocoon/ButterflyManifesto
>>
>> Comments are welcome, flames > /dev/null.
>
>
> Avalon is dying (and I'm personally trying to killing it faster) and
> this status is hurting us (see the stall of the cocoon 2.2 evolution),
> so I agree with sentiments here that we must do something.
>
> Changing container is a back-incompatible thing, even if, obviously,
> we can sandbox existing components into avalon sandbox (as proposed
> already) so our users should be worried since we care for them.
>
> You are proposing Springs which is a rather simple, bean based,
> dependency-injection based framework.
>
> Alternatives are:
>
> - Kernel (written by Pier and designed by Pier and myself)
> - Merlin
> - Geronimo Container (also compatible with Springs, from what I hear)
> - Fortress
>
> My (obviously biased) view is that cocoon is both a production
> software and a research project, depending on other communities for
> our critical foundations turned out to be dangerous.
>
> So, the question is: what do we buy in using somebody else's code
> instead of maintaining our own?
>
> For sure it doesn't save us energy, we already have that container build.
>
> For sure it doesn't increase our ability to innovate, since any
> changes have to go thru another mail list (which, in the Spring case,
> is not even ASF controlled).
>
> For sure it doesn't help us with reusability of code, since we reuse
> libraries over their interfaces (JCP-standardized or not) and wrap
> them on our own little pipeline abstractions.
>
> Result, I'm -1 on Spring because we can't control it and -0.5 on
> Merlin/Fortress/Geronimo because they are other communities with other
> interests.
>
> I say we write our stuff and be done with it once and forever.
>
I think it will be a question of doing it. If Ugo presents a functional
prototyp of Spring that supports Real Blocks and which can be made
backwards compatible to 2.1 sitemaps and flowscripts I wouldn't have
arguments against it :-)
Is anyone else working on an alternative these days? (Carsten, Pier ???)
Some words to the ButterflyManifesto: IMHO it has a clear focus on
"technical excellence". The point missing (IMHO) is that we have a large
user base with many, many applications running on Cocoon 2.x. It is very
important to make their move to Cocoon NG as simple as possible so that
they don't have to redo all the work. I think this means at least
support for Sitemaps and Flowscripts and support for existing components
in a legacy mode.
(I know repeating this over and over again is boring but sometimes I
have the feeling that this is forgotten ...)
--
Reinhard
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Steven Noels <st...@outerthought.org>.
On 22 Jul 2004, at 21:52, Sylvain Wallez wrote:
> My opinion is that what refrains us to move is that the container
> contract is deeply engraved in every component in our code base.
> Whatever solution we choose, we must take greate care to hide as much
> as
> possible the chosen container in the lower levels layers of the Cocoon
> system. Higher level layers, those hosting user-written components,
> should be POJOs, using whatever IoC type 2/3 container best suits our
> needs.
>
> Now what should be that container? I share your fears about "foreign"
> containers. Avalon already did much harm, and it is inside the ASF.
(playing the ball, not the man, as always shooting in diverse
directions)
I've been skimreading several megabytes of rather diverse ASF mailing
lists upon my return from a bliss-like holiday, and I cannot refrain
myself from thinking that the term "Avalon harm" is being coined these
days as some sort of "see?" argument in a whole lot of discussions, but
most of the time not related at all to technical matters (compared with
Ugo's and other folks' purely technical interest in Spring).
I'm the King of Pet Peeves, but I think we shouldn't let every single
discussion evolve into a "what the ASF thinks is good for itself == its
users", which becomes patronizing very fast. Folks have vested opinions
about component containers, but that shouldn't make them afraid to
witness the evident opportunity of a from-scratch rewrite, with a
shortcut path by using an outside component framework rather than
thinking we need something very special. I hope Ugo and his sorry job
situation endure in many more nice RTs. :-)
I for myself think these kind of discussions might finally evolve into
a real future of Cocoon... while the community is great at always, we
have been wrestling with a code/installed base that frightens people to
contribute anything but minor tweaks and patches, and frankly, we
haven't been very innovative at all in the post-flow era - tossing the
blocks ball around as if we all hope that somebody else is interested
enough to tackle it instead.
Besides, I think we should be modest and prudent in our judgement of
outside-ASF OSS projects. I had my share of live Spring advocacy in the
past few months, and they seem to be bright and nice folks IMHO.
Please mind that my state of mind is definitely bliss-like ATM - blame
it on the French sun.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
<snip/>
> Result, I'm -1 on Spring because we can't control it and -0.5 on
> Merlin/Fortress/Geronimo because they are other communities with other
> interests.
>
> I say we write our stuff and be done with it once and forever.
My opinion is that what refrains us to move is that the container
contract is deeply engraved in every component in our code base.
Whatever solution we choose, we must take greate care to hide as much as
possible the chosen container in the lower levels layers of the Cocoon
system. Higher level layers, those hosting user-written components,
should be POJOs, using whatever IoC type 2/3 container best suits our needs.
Now what should be that container? I share your fears about "foreign"
containers. Avalon already did much harm, and it is inside the ASF.
Spring currently looks like a friendly project, both socially and
technically, but what if its direction evolves to something that's
incompatible with our needs?
Or we can have this layered architecture allowing end-user components
(those defined by a block) to be hosted in pluggable containers. AFAIU,
this is what is allowed by the Spring MBean in Geronimo.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 22/lug/04, alle 03:10, peter royal ha scritto:
> have you considered picocontainer at all? i would *LOVE* to see the
> core shuffled about. i want to be able to nest the containment of
> cocoon's core objects in order to share them between multiple cocoon
> instances, and being built upon an open container platform helps that
> a lot.
To be honest, I chose Spring because I use it all day in my job, the
reason being that I have been using Hibernate for some time and Spring
has *awesome* integration with Hibernate. But if you look at the code I
wrote, the only dependencies on Spring are in the test classes and that
is just because it takes less code to have collaborators injected by
Spring before testing a bean than it is to inject them by hand. As of
now, I think you can deploy them in picocontainer without changing a
single line of code (assuming you are ready to do setter-based
injection as opposed to constructor-based).
>
> Really, I'm +1 on pushing the platform forward, whichever direction it
> is. Its the progress that's important :)
> -pete
>
Yeah!
Ugo
--
Ugo Cei - http://beblogging.com/
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by peter royal <pr...@apache.org>.
On Jul 21, 2004, at 7:28 PM, Stefano Mazzocchi wrote:
> Ugo Cei wrote:
>> Since I'm getting more and more bored with my daytime job, I ended up
>> doing something:
>> http://wiki.apache.org/cocoon/ButterflyManifesto
>> Comments are welcome, flames > /dev/null.
have you considered picocontainer at all? i would *LOVE* to see the
core shuffled about. i want to be able to nest the containment of
cocoon's core objects in order to share them between multiple cocoon
instances, and being built upon an open container platform helps that a
lot.
> You are proposing Springs which is a rather simple, bean based,
> dependency-injection based framework.
>
> Alternatives are:
>
> - Kernel (written by Pier and designed by Pier and myself)
> - Merlin
> - Geronimo Container (also compatible with Springs, from what I hear)
> - Fortress
- Pico/Nanocontainer
> My (obviously biased) view is that cocoon is both a production
> software and a research project, depending on other communities for
> our critical foundations turned out to be dangerous.
>
> So, the question is: what do we buy in using somebody else's code
> instead of maintaining our own?
I would prefer to see somebody else's code. I think it depends on what
one's view of cocoon is.
Is it:
A) An application framework that you run as a servlet
B) A set of components that you can integrate into your application
I take view B, and thus the ease with which Cocoon can be integrated
into larger platforms is critical.
We have this with Avalon today. If you use the sevak component from
avalon, <http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/sevak/>, you
can make a servlet Servicable. You can then run your sevak component
inside of Phoenix, and voila, you can have cocoon components look up
Phoenix blocks!
By going with an "open" container platform ("open" being that the
license is compatible and it is just a container / component contract,
explicitly designed for reuse), ease of integration with other
component systems is that much easier.
While we can do that with our own container, I think it comes down to
which is more work:
* Maintaining your own container
* Dealing with an external containers development priorities and
community
With avalon, the latter has been more work. I don't think a sour avalon
experience should turn us away from looking at containers from other
normal communities.
Really, I'm +1 on pushing the platform forward, whichever direction it
is. Its the progress that's important :)
-pete
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Marc Portier wrote:
> Stefano Mazzocchi wrote:
>
>> For sure it doesn't save us energy, we already have that container build.
>
> Cost of building is a fraction of the cost of maintaining?
dude, have you ever tried to change anything in the avalon framework?
--
Stefano.
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Marc Portier <mp...@outerthought.org>.
Stefano Mazzocchi wrote:
> Ugo Cei wrote:
>
>> Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
>>
>>> think so too, just needs more wild thinking and somebody doing :-)
>>
>>
>>
>> Since I'm getting more and more bored with my daytime job, I ended up
>> doing something:
>>
>> http://wiki.apache.org/cocoon/ButterflyManifesto
>>
>> Comments are welcome, flames > /dev/null.
>
>
> Avalon is dying (and I'm personally trying to killing it faster) and
> this status is hurting us (see the stall of the cocoon 2.2 evolution),
> so I agree with sentiments here that we must do something.
>
> Changing container is a back-incompatible thing, even if, obviously, we
> can sandbox existing components into avalon sandbox (as proposed
> already) so our users should be worried since we care for them.
>
> You are proposing Springs which is a rather simple, bean based,
> dependency-injection based framework.
>
as such it's only doing one thing (well)
which means that by itself it's probably not going to be 'enough' as a
base for all features our components, and groups of components (blocks?)
might need
> Alternatives are:
>
> - Kernel (written by Pier and designed by Pier and myself)
> - Merlin
> - Geronimo Container (also compatible with Springs, from what I hear)
> - Fortress
>
> My (obviously biased) view is that cocoon is both a production software
> and a research project, depending on other communities for our critical
> foundations turned out to be dangerous.
>
uh?
this sounds like the avalon experience is suddenly extended to the whole
world
$ du -sk lib
13782 lib
the sum of avalon and excalibur jars in there is a bit over 800k
> So, the question is: what do we buy in using somebody else's code
> instead of maintaining our own?
>
Some prove of the reuse pudding maybe? Surely that reuse think is more
beneficial then just the feeling of good common sense?
(By the way: in my head reuse is measured by the ability to throw stuff
away without jeopardizing the rest)
> For sure it doesn't save us energy, we already have that container build.
>
Cost of building is a fraction of the cost of maintaining?
(Mind though that spring's core is some 200k, so yeah, it does not look
like an awful lot of work, but turned around it seems decreasingly
interesting to forcefully redo it either?)
> For sure it doesn't increase our ability to innovate, since any changes
> have to go thru another mail list (which, in the Spring case, is not
> even ASF controlled).
>
<jokingly>
I'm probably missing something about the subtle way ASF is controlling
what I'm saying here? Ignorance is bliss, so please don't tell me :-)
</jokingly>
Cluetrain: it (including innovation!) is about conversations, you simply
don't control where they happen... borders are in our minds
As for innovation discussed on mailinglists: we will could admit that we
haven't always been eagerly receptive to our internal blend of
innovation? Reversing the argument we might question if dipping into a
pool of people with a somewhat different mindset couldn't be really
refreshing and nurturing the innovation more then limitiing it. At least
I would be curious enough to find out.
> For sure it doesn't help us with reusability of code, since we reuse
> libraries over their interfaces (JCP-standardized or not) and wrap them
> on our own little pipeline abstractions.
>
Hm, in my head it's not only about our own code, it's also about the
additional code our endusers are writing, no?
Mind you: not the custom pipeline-components or other extensions on
proper cocoon api's (people opting for those will hapilly take some
cocoon dependency for granted) but the actual business code that needs
to be blended in (more and more since our growing webapp dev support).
Today we're advocating to do that through wrapping in avalon components?
I know writing a service wrapper that allows to hook up in avalon isn't
a big deal, but the none-intrusiveness of the new style of containers
(zaroo lines of wrapping?) make the ratio go to positive-infinite anyway
> Result, I'm -1 on Spring because we can't control it and -0.5 on
> Merlin/Fortress/Geronimo because they are other communities with other
> interests.
>
> I say we write our stuff and be done with it once and forever.
>
so what about 'less is more?'
and 'it's not about the code, but about the community?'
I honnestly find your upfront position in this (based on historic
frustration?) almost elitist.
In principle I'm probably not that far off from your feeling that we
shouldn't be too shy to go and build what we need and then bravely
support it. But in practice I see no benefit in redoing what others have
done, provided it's done well and doesn't require us to drag allong a
load of stuff we're not asking for.
Starting from Spring's core my expectations would be that there is still
more than enough stuff that we will need to add ourselves (which is
resonating with your arguments?)...
To conclude: Even if we later on would decide that spring's core would
need to be replaced by our own thingy than still, the quick benefits
IMHO would be
- starting from a spinning wheel rather then re-invent the concept
- broaden our horizon and pull in more views
- get into (and also infect) a more widespread mindshare
- get us started again (thx Ugo!)
Controlling our dependencies to external thingies is a continuous
concern, this will not be different this time, lessons from the past
should be applied.
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [butterfly] spring dependant tests (was Re: The Butterfly
Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Antonio Gallardo <ag...@agssa.net>.
Upayavira dijo:
> Nicola Ken Barozzi wrote:
>
>>
>>> What about a mailing list?
>>
>>
>> We're having an unpleasant discussion about creating mailing lists on
>> the community list... ugh
>>
>> IMO the right thing is to ask a vote for it, and then ask infra to set
>> it up as per the Cocoon PMC decision.
>>
> I don't want to see another mailing list. That would create a fork of
> Cocoon, which is _not_ what I understand you as trying to do.
>
> All discussion of Butterfly _must_ happen here, so that we all have some
> oversight over what is going on, whether we want to participate or not.
> (I'm sure we're all skilled enough at skipping irrelevant messages,
> aren't we!)
+1 for Upayavira proposal. We will discuss things here.
Best Regards,
Antonio Gallardo
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto
(was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Upayavira <uv...@upaya.co.uk>.
Nicola Ken Barozzi wrote:
>
>> What about a mailing list?
>
>
> We're having an unpleasant discussion about creating mailing lists on
> the community list... ugh
>
> IMO the right thing is to ask a vote for it, and then ask infra to set
> it up as per the Cocoon PMC decision.
>
I don't want to see another mailing list. That would create a fork of
Cocoon, which is _not_ what I understand you as trying to do.
All discussion of Butterfly _must_ happen here, so that we all have some
oversight over what is going on, whether we want to participate or not.
(I'm sure we're all skilled enough at skipping irrelevant messages,
aren't we!)
Regards, Upayavira
Re: [butterfly] spring dependant tests (was Re: The Butterfly
Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Dave Brondsema <da...@brondsema.net>.
On Thu, 22 Jul 2004, Ugo Cei wrote:
> Il giorno 22/lug/04, alle 15:17, Nicola Ken Barozzi ha scritto:
>
> > As I tried to explain, as a Cocoon committer you should be able to
> > experiment in a branch. As soon as the SVN conversion is over, you can
> > create a butterfly branch and all Cocooon committers can work there if
> > they want to.
>
> Pardon my ignorance, but doesn't a branch include all the sources from
> the main trunk when you create it? If so, it isn't appropriate, since I
> want to start from a clean slate.
>
It does. You would probably want to create a new directory as a peer to
'trunk'.
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto
(was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Il giorno 22/lug/04, alle 15:17, Nicola Ken Barozzi ha scritto:
>
>> As I tried to explain, as a Cocoon committer you should be able to
>> experiment in a branch. As soon as the SVN conversion is over, you can
>> create a butterfly branch and all Cocooon committers can work there if
>> they want to.
>
>
> Pardon my ignorance, but doesn't a branch include all the sources from
> the main trunk when you create it? If so, it isn't appropriate, since I
> want to start from a clean slate.
a branch in SVN is just a copy. up to you to decide what to copy. in
case of zero copy is just a "svn mkdir http://..."
>> IMO the right thing is to ask a vote for it, and then ask infra to set
>> it up as per the Cocoon PMC decision.
>
> OK, but unless someone objects, for the moment I think we can continue
> the discussion on this list, as Marc suggested.
+1
--
Stefano.
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 22/lug/04, alle 15:17, Nicola Ken Barozzi ha scritto:
> As I tried to explain, as a Cocoon committer you should be able to
> experiment in a branch. As soon as the SVN conversion is over, you can
> create a butterfly branch and all Cocooon committers can work there if
> they want to.
Pardon my ignorance, but doesn't a branch include all the sources from
the main trunk when you create it? If so, it isn't appropriate, since I
want to start from a clean slate.
> IMO the right thing is to ask a vote for it, and then ask infra to set
> it up as per the Cocoon PMC decision.
OK, but unless someone objects, for the moment I think we can continue
the discussion on this list, as Marc suggested.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto
(was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ugo Cei wrote:
> Il giorno 22/lug/04, alle 10:34, Marc Portier ha scritto:
>
>> still have to get into your actual code sample though, by the way:
>> could we arrange having a cvs somewhere?
>
> How about cocoondev.org? Is the migration over? I asked Steven some time
> ago about hosting the SpringPetstore block and he askde me to wait until
> August.
>
> Or would it be better to create a new module in the Apache CVS?
>
> I'd rather avoid SF, I've had unpleasant experiences in the past.
As I tried to explain, as a Cocoon committer you should be able to
experiment in a branch. As soon as the SVN conversion is over, you can
create a butterfly branch and all Cocooon committers can work there if
they want to.
> What about a mailing list?
We're having an unpleasant discussion about creating mailing lists on
the community list... ugh
IMO the right thing is to ask a vote for it, and then ask infra to set
it up as per the Cocoon PMC decision.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto
(was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Marc Portier wrote:
> I've been largely skimreading this list last couple of weeks so maybe
> I missed an important update on the svn switch for cocoon?
Yep.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109043692326007
Vadim
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 22/lug/04, alle 11:04, Marc Portier ha scritto:
> I've been largely skimreading this list last couple of weeks so maybe
> I missed an important update on the svn switch for cocoon?
> IIRC there was going to be a spot for these kind of efforts?
>
> In any case it would be nice to have something small-scale here and
> now.
OK, as a *temporary* solution while I get myself up-to-date on SVN, I
have setup a repository on my machine. If anybody wants CVS access
(over ssh only) drop me a line stating desired username and password
and I'll arange it ASAP.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto
(was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Marc Portier <mp...@outerthought.org>.
Ugo Cei wrote:
> Il giorno 22/lug/04, alle 10:34, Marc Portier ha scritto:
>
>> still have to get into your actual code sample though, by the way:
>> could we arrange having a cvs somewhere?
>
>
> How about cocoondev.org? Is the migration over? I asked Steven some time
> ago about hosting the SpringPetstore block and he askde me to wait until
> August.
>
there have been some upgrades on the machinery recently, but I remember
him making more serious shifting plans after his return from holidays...
I'm not into his planning in detail but I would guess this to mean mid
aug at the earliest
> Or would it be better to create a new module in the Apache CVS?
>
IMHO it belongs in the cocoon repo, no?
I've been largely skimreading this list last couple of weeks so maybe I
missed an important update on the svn switch for cocoon?
IIRC there was going to be a spot for these kind of efforts?
In any case it would be nice to have something small-scale here and now.
> I'd rather avoid SF, I've had unpleasant experiences in the past.
>
me too
> What about a mailing list?
>
I would not leave this spot unless (god forbid) people actually asked to
take it elsewhere
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 22/lug/04, alle 10:34, Marc Portier ha scritto:
> still have to get into your actual code sample though, by the way:
> could we arrange having a cvs somewhere?
How about cocoondev.org? Is the migration over? I asked Steven some
time ago about hosting the SpringPetstore block and he askde me to wait
until August.
Or would it be better to create a new module in the Apache CVS?
I'd rather avoid SF, I've had unpleasant experiences in the past.
What about a mailing list?
Ugo
--
Ugo Cei - http://beblogging.com/
[butterfly] spring dependant tests (was Re: The Butterfly Manifesto
(was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Marc Portier <mp...@outerthought.org>.
Ugo Cei wrote:
>
> (Note to self: rewrite unit tests so that they don't depend on
> BeanFactory).
>
yes and no:
I've seen myself do both: have tests that go on detail level and just
wire beans themselves in the setup()
but also: have tests that use the beanfactory to do so (using a stupid
base class that extends TestCase)
In short: I see no reason why not to have both, the latter help document
typical configuration settings for the bean wiring
still have to get into your actual code sample though, by the way: could
we arrange having a cvs somewhere?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 22/lug/04, alle 01:28, Stefano Mazzocchi ha scritto:
> I say we write our stuff and be done with it once and forever.
I agree with you on one thing here. Depending on an external community
for our foundations is a BIG risk. But I also want to balance risks
against benefits. Spring is actively developed, well documented, widely
used and thouroughly tested. Can you say the same of Kernel?
Now, I don't want this thread to escalate into a flame war of the kind
"my container is better than yours". I actually want to point out what
is the greatest benefit of Spring, in my mind. It is the fact that you
can write components that don't depend on it and yet be managed by it.
If you take a look at the small code sample that I wrote, you can
easily see that most of what I did consisted in *removing* things. I
removed all dependencies on Avalon, all of "extends AbstractLogEnabled
implements Serviceable, Poolable, Recyclable, Whateverable". I removed
looking up collaborators via a ServiceManager and instead injected them
(like the XMLParser) via a setter. And I did *not* substitute them with
Spring classes and interfaces.
So, what you're left with is a handful of beans that can be deployed in
Spring but, if Peter wants to deploy them in Pico/Nanocontainer
instead, fine. It should be easy. There are no dependencies on the
container (see also point 1.4.1 of the manifesto).
(Note to self: rewrite unit tests so that they don't depend on
BeanFactory).
To sum it up, Kernel is fine if it supports Type 2 and/or Type 3
Dependency Injection (that is constructor and/or setter based). It
would better if it had more tests, but hey. And it is fine if it moves
forward, but I won't be the one to move it, because I don't have
neither the expertise nor the time needed to write a container. I use
Spring in my daytime job for implementing applications, so my knowledge
of it is growing, and I have some time to rewrite some Cocoon
components to be compatible with a dependency-injection approach. If
this means, as I hope, that they can be deployed in Spring, Pico/Nano,
Hivemind or Kernel without changes, we can take some time to rehash all
the alternatives and decide which one is best. In the meantime, let's
fscking do something ;-).
Ugo
--
Ugo Cei - http://beblogging.com/
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Brian McCallister <mc...@forthillcompany.com>.
For what its worth, Spring is very much developed along the lines of an
ASF meritocracy, uses the ASL 2.0, has thriving developer and user
communities, and releases early and often.
Other than not being an ASF project, it is a model ASF project =)
-Brian
On Jul 22, 2004, at 10:10 PM, Antonio Gallardo wrote:
> Nicola Ken Barozzi dijo:
>> Stefano Mazzocchi wrote:
>> ...
>>> Result, I'm -1 on Spring because we can't control it and -0.5 on
>>> Merlin/Fortress/Geronimo because they are other communities with
>>> other
>>> interests.
>>
>> I agree but...
>>
>>> I say we write our stuff and be done with it once and forever.
>>
>> ... if he wants to try Spring, why stop him and others to _try_. It
>> seems he can't be persuaded otherwise, and who knows, maybe he's
>> right!
>
> Yep. I greee. Lets do a try with Spring. If the result is not good, we
> have not losed nothing.
>
> I know Spring is a buzzword now, but a test drive is not bad. ;-)
>
> Best Regards,
>
> Antonio Gallardo
>
>
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real
Blocks?)
Posted by Antonio Gallardo <ag...@agssa.net>.
Nicola Ken Barozzi dijo:
> Stefano Mazzocchi wrote:
> ...
>> Result, I'm -1 on Spring because we can't control it and -0.5 on
>> Merlin/Fortress/Geronimo because they are other communities with other
>> interests.
>
> I agree but...
>
>> I say we write our stuff and be done with it once and forever.
>
> ... if he wants to try Spring, why stop him and others to _try_. It
> seems he can't be persuaded otherwise, and who knows, maybe he's right!
Yep. I greee. Lets do a try with Spring. If the result is not good, we
have not losed nothing.
I know Spring is a buzzword now, but a test drive is not bad. ;-)
Best Regards,
Antonio Gallardo
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
...
> Result, I'm -1 on Spring because we can't control it and -0.5 on
> Merlin/Fortress/Geronimo because they are other communities with other
> interests.
I agree but...
> I say we write our stuff and be done with it once and forever.
... if he wants to try Spring, why stop him and others to _try_. It
seems he can't be persuaded otherwise, and who knows, maybe he's right!
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
>
>> think so too, just needs more wild thinking and somebody doing :-)
>
>
> Since I'm getting more and more bored with my daytime job, I ended up
> doing something:
>
> http://wiki.apache.org/cocoon/ButterflyManifesto
>
> Comments are welcome, flames > /dev/null.
Avalon is dying (and I'm personally trying to killing it faster) and
this status is hurting us (see the stall of the cocoon 2.2 evolution),
so I agree with sentiments here that we must do something.
Changing container is a back-incompatible thing, even if, obviously, we
can sandbox existing components into avalon sandbox (as proposed
already) so our users should be worried since we care for them.
You are proposing Springs which is a rather simple, bean based,
dependency-injection based framework.
Alternatives are:
- Kernel (written by Pier and designed by Pier and myself)
- Merlin
- Geronimo Container (also compatible with Springs, from what I hear)
- Fortress
My (obviously biased) view is that cocoon is both a production software
and a research project, depending on other communities for our critical
foundations turned out to be dangerous.
So, the question is: what do we buy in using somebody else's code
instead of maintaining our own?
For sure it doesn't save us energy, we already have that container build.
For sure it doesn't increase our ability to innovate, since any changes
have to go thru another mail list (which, in the Spring case, is not
even ASF controlled).
For sure it doesn't help us with reusability of code, since we reuse
libraries over their interfaces (JCP-standardized or not) and wrap them
on our own little pipeline abstractions.
Result, I'm -1 on Spring because we can't control it and -0.5 on
Merlin/Fortress/Geronimo because they are other communities with other
interests.
I say we write our stuff and be done with it once and forever.
--
Stefano.
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Jorg Heymans wrote:
> <snip>
>
>>
>> Ugo,
>>
>> tests help but don't really buy us anything: have a community that is
>> strong and diverse enough to do the regression testing for us.
>
>
> In a commercial world this would sound like :
> "Have enough customers that are willing to put up with the bugs we could
> (might) have caught with better unit-test coverage".
>
> That doesn't sound so positive anymore now does it?
Oh, whatever, you can choose to read my words one by one or to
understand my point. Up to you.
--
Stefano.
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Jorg Heymans <jh...@domek.be>.
>>> tests help but don't really buy us anything: have a community that is
>>> strong and diverse enough to do the regression testing for us.
>>
>>
>>
>> In a commercial world this would sound like :
>> "Have enough customers that are willing to put up with the bugs we
>> could (might) have caught with better unit-test coverage".
>>
>> That doesn't sound so positive anymore now does it?
>
>
>
> You're right, in a commercial world. But Cocoon is OS and one of the
> strengh of OS is testing by its community. The users always find bugs
> that the programmer who has to write a test would never have expected.
Right. And all community members use cocoon to manage their personal CD
collection?
> What we should try to achieve is that every bug fix is supported by a
> JUnit or Anteater test so that it can't happen twice.
Fully agree
Regards
Jorg
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> <snip>
>
>>
>> Ugo,
>>
>> tests help but don't really buy us anything: have a community that is
>> strong and diverse enough to do the regression testing for us.
>
>
> In a commercial world this would sound like :
> "Have enough customers that are willing to put up with the bugs we
> could (might) have caught with better unit-test coverage".
>
> That doesn't sound so positive anymore now does it?
You're right, in a commercial world. But Cocoon is OS and one of the
strengh of OS is testing by its community. The users always find bugs
that the programmer who has to write a test would never have expected.
What we should try to achieve is that every bug fix is supported by a
JUnit or Anteater test so that it can't happen twice.
--
Reinhard
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Jorg Heymans <jh...@domek.be>.
<snip>
>
> Ugo,
>
> tests help but don't really buy us anything: have a community that is
> strong and diverse enough to do the regression testing for us.
In a commercial world this would sound like :
"Have enough customers that are willing to put up with the bugs we could
(might) have caught with better unit-test coverage".
That doesn't sound so positive anymore now does it?
Regards
Jorg
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 22/lug/04, alle 12:20, Stefano Mazzocchi ha scritto:
> Avalon is not the reason why people didn't write tests for cocoon.
> This is an open source project and a do-ocracy: if you think tests are
> important, write them and contribute them. We never said "no, go away
> with your stupid tests".
It's one of the reasons. Ever tried testing a component by extending
ExcaliburTestCase (which is deprecated, btw, but there doesn't seem to
be a replacement)? It takes much more time than it should. I'm sure
people would write more tests if testability were a prominent
characteristic of the framework.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Jean-Claude Moissinac <mo...@enst.fr>.
Stefano Mazzocchi wrote:
> Ralph Goers wrote:
>
>>> Let's not mix concerns: cocoon has few tests, agreed, but this has
>>> nothing to do with the architecture.
>>
>>
>> It does in the sense that you can't prove that you haven't "broken" it.
>
>
> Avalon is not the reason why people didn't write tests for cocoon. This
> is an open source project and a do-ocracy: if you think tests are
> important, write them and contribute them. We never said "no, go away
> with your stupid tests".
>
> My point is not if tests are good or bad, my point is tests and
> architectural decisions are two orthogonal concerns and should be kept
> separate.
>
I think that, from a date, nothing was comited in Batik without a linked
test.
After a hard to decide process, it was accepted as a very effective
decision.
Jean-Claude
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Ralph Goers wrote:
>> Let's not mix concerns: cocoon has few tests, agreed, but this has
>> nothing to do with the architecture.
>
> It does in the sense that you can't prove that you haven't "broken" it.
Avalon is not the reason why people didn't write tests for cocoon. This
is an open source project and a do-ocracy: if you think tests are
important, write them and contribute them. We never said "no, go away
with your stupid tests".
My point is not if tests are good or bad, my point is tests and
architectural decisions are two orthogonal concerns and should be kept
separate.
--
Stefano.
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real
Blocks?)
Posted by Ralph Goers <Ra...@dslextreme.com>.
At 7/21/2004 04:18 PM, you wrote:
>Ugo,
>
>tests help but don't really buy us anything: have a community that is
>strong and diverse enough to do the regression testing for us.
I couldn't disagree more. Unit/functional tests help tremendously in
verifying that a new release is still compatible with the prior release -
or at least identifies how it is not. Even more important, this can be
known before the release is done instead of finding out from the user
community after it goes out. Although there are a large number of folks
who pull from CVS, I expect most download released versions under the
expectation that they have undergone more rigorous testing.
>Let's not mix concerns: cocoon has few tests, agreed, but this has nothing
>to do with the architecture.
It does in the sense that you can't prove that you haven't "broken" it.
>--
>Stefano.
>
>
Tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 22/lug/04, alle 01:18, Stefano Mazzocchi ha scritto:
> Ugo Cei wrote:
>> Agreed, but even if we cannot prove that code is correct with unit
>> tests alone, we can at least hope that - statistically - code that
>> has 100% test coverage will have less bugs than code that has 10%
>> test coverage. Unfortunately, my impression is that Cocoon is now at
>> the lower end of the spectrum.
>
> Ugo,
>
> tests help but don't really buy us anything: have a community that is
> strong and diverse enough to do the regression testing for us.
Ouch! I can't believe I'm reading this. I'm not going to try to
convince you that shifting the burden of testing from the shoulders of
lazy programmers onto those of unsuspecting users is a bad thing. I
want to be positive instead and tell you what tests do buy us:
- less recourse to debuggers
- better documentation
- enabling refactoring
- better design
- faster development
In the end it's a matter of confidence. You're developing better code
faster when you have the cconfiidence that, if you break something,
tests will tell you very quickly.
> Let's not mix concerns: cocoon has few tests, agreed, but this has
> nothing to do with the architecture.
I never meant that to imply that Cocoon's architecture is not good
because it has few tests. But I believe that having a wide test
coverage leads to designing components that are more amenable to
testing in isolation and thus less coupled. And I think we all agree
that loose coupling is a worthwhile objective.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Marc Portier <mp...@outerthought.org>.
Stefano Mazzocchi wrote:
> Ugo Cei wrote:
>
<snip />
>>
>> Agreed, but even if we cannot prove that code is correct with unit
>> tests alone, we can at least hope that - statistically - code that has
>> 100% test coverage will have less bugs than code that has 10% test
>> coverage. Unfortunately, my impression is that Cocoon is now at the
>> lower end of the spectrum.
>
>
> Ugo,
>
> tests help but don't really buy us anything: have a community that is
> strong and diverse enough to do the regression testing for us.
>
In all modesty, I think that community has better things to do: as I
understand TDD regarding bugs then if you spot a certain problem once
you make it into an automated test that runs automatically rather then
hoping the same guy will run through his tests with the next upgrade
we're just missing the culture here, and have been spoiled by a
community that doesn't mind (yet)
having a test harness and the culture to have problem-reports translated
into tighting it up even more seems to me a catalizator to even grow the
community based on it being is comforted by the fact that there is a
sure progress and no need to run through the old stuff over and over...
so I honestly think it will buy us something...
> Let's not mix concerns: cocoon has few tests, agreed, but this has
> nothing to do with the architecture.
>
dunno, web-projects in general have a tendency to lack good
testharnesses, in fact everything that deals with end-user screens
however in our case I'ld like to think allong the lines of Ugo: the
underlaying framework doesn't make setting up a testscenario really
easy: you need the whole thing up and running to test anything, as far
as I've seen spring at work it's implicity would less intrude into your
components, so there is less of an environment to build up in your
testcases to have them ran through some test-scenarios
those tests might be not true efull environment tests, but they'll
surely be able to spot a fair share of low level RTE's you should get
rid off
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Il giorno 21/lug/04, alle 13:37, Leo Sutic ha scritto:
>
>> 1. "Butterfly is an experiment aiming to implement a (simplified)
>> Cocoon clone but based on Spring instead of Hibernate" Don't you mean:
>> "based on Spring instead of Avalon"
>
>
> Of course. Typo corrected.
>
>> 2. "Strive for 100% unit test coverage" A bit of a red herring. You
>> don't want code coverage as much as state coverage. For example:
>>
>> /** Divides two numbers. If b == 0, returns 0. */
>> public static void divide (int a, int b) { return a/b; }
>>
>> Test:
>>
>> public void testDivide () { assert divide (4, 2) == 2 };
>>
>> Which doesn't test the case where b == 0.
>
>
> Agreed, but even if we cannot prove that code is correct with unit tests
> alone, we can at least hope that - statistically - code that has 100%
> test coverage will have less bugs than code that has 10% test coverage.
> Unfortunately, my impression is that Cocoon is now at the lower end of
> the spectrum.
Ugo,
tests help but don't really buy us anything: have a community that is
strong and diverse enough to do the regression testing for us.
Let's not mix concerns: cocoon has few tests, agreed, but this has
nothing to do with the architecture.
--
Stefano.
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 21/lug/04, alle 13:37, Leo Sutic ha scritto:
> 1. "Butterfly is an experiment aiming to implement a (simplified)
> Cocoon clone but based on Spring instead of Hibernate" Don't you mean:
> "based on Spring instead of Avalon"
Of course. Typo corrected.
> 2. "Strive for 100% unit test coverage" A bit of a red herring. You
> don't want code coverage as much as state coverage. For example:
>
> /** Divides two numbers. If b == 0, returns 0. */
> public static void divide (int a, int b) { return a/b; }
>
> Test:
>
> public void testDivide () { assert divide (4, 2) == 2 };
>
> Which doesn't test the case where b == 0.
Agreed, but even if we cannot prove that code is correct with unit
tests alone, we can at least hope that - statistically - code that has
100% test coverage will have less bugs than code that has 10% test
coverage. Unfortunately, my impression is that Cocoon is now at the
lower end of the spectrum.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Leo Sutic <le...@gmail.com>.
Ugo Cei wrote:
> Since I'm getting more and more bored with my daytime job, I ended up
> doing something:
>
> http://wiki.apache.org/cocoon/ButterflyManifesto
>
> Comments are welcome, flames > /dev/null.
Comments:
1. "Butterfly is an experiment aiming to implement a (simplified)
Cocoon clone but based on Spring instead of Hibernate" Don't you mean:
"based on Spring instead of Avalon"
2. "Strive for 100% unit test coverage" A bit of a red herring. You
don't want code coverage as much as state coverage. For example:
/** Divides two numbers. If b == 0, returns 0. */
public static void divide (int a, int b) { return a/b; }
Test:
public void testDivide () { assert divide (4, 2) == 2 };
Which doesn't test the case where b == 0.
/LS
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ugo Cei wrote:
> Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
>
>> think so too, just needs more wild thinking and somebody doing :-)
>
> Since I'm getting more and more bored with my daytime job, I ended up
> doing something:
>
> http://wiki.apache.org/cocoon/ButterflyManifesto
>
> Comments are welcome, flames > /dev/null.
This looks like an interesting "revolution" in Cocoon land :-)
If you want to do it, and it will be really interesting if you do, here
are some tips:
http://incubator.apache.org/learn/rules-for-revolutionaries.html
In particular, here are the relevant parts:
"
To allow this to happen, to allow revolutionaries to
co-exist with evolutionaries, I'm proposing the following
as official Jakarta policy:
1) Any committer has the right to go start a
revolution. They can establish a branch or seperate
whiteboard directory in which to go experiment with new
code seperate from the main trunk. The only
responsibility a committer has when they do this is to
inform the developer group what their intent is, to keep
the group updated on their progress, and allowing others
who want to help out to do so. The committer, and the
group of people who he/she has a attracted are free to
take any approaches they want to free of interference.
2) When a revolution is ready for prime time, the
committer proposes a merge to the -dev list. At that
time, the overall community evaluates whether or not the
code is ready to become part of, or to potentially
replace the, trunk. Suggestions may be made, changes may
be required. Once all issues have been taken care of and
the merge is approved, the new code becomes the trunk.
3) A revolution branch is unversioned. It doesn't have
any official version standing. This allows several
parallel tracks of development to occur with the final
authority of what eventually ends up on the trunk laying
with the entire community of committers.
4) The trunk is the official versioned line of the
project. All evolutionary minded people are welcome to
work on it to improve it. Evolutionary work is important
and should not stop as it is always unclear when any
particular revolution will be ready for prime time or
whether it will be officially accepted.
"
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------