Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Steven Noels]

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 Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Brian McCallister]

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: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Antonio Gallardo]

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: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Antonio Gallardo]

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?)

[Sylvain Wallez]

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 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: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Stefano Mazzocchi]

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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Dave Brondsema]

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 : [EMAIL PROTECTED]
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?))

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Jean-Claude Moissinac]

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: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Upayavira]

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?))

[Nicola Ken Barozzi]

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   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Jorg Heymans]

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: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Vadim Gritsenko]

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: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Stefano Mazzocchi]

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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Stefano Mazzocchi]

Jorg Heymans 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.

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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Stefano Mazzocchi]

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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Marc Portier]

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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

[butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Marc Portier]

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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Nicola Ken Barozzi]

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   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Marc Portier]

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).


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 :-)


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 benefit

Tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Reinhard Poetz]

Jorg Heymans 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.

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?)

[Jorg Heymans]

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?)

[Reinhard Poetz]

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?)

[Carsten Ziegeler]

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?)

[Reinhard Poetz]

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?)

[Ralph Goers]

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.

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[peter royal]

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, , 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?)

[Marc Portier]

Stefano Mazzocchi wrote:
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.

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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Stefano Mazzocchi]

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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Stefano Mazzocchi]

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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Ugo Cei]

Il giorno 21/lug/04, alle 23:29, Antonio Gallardo ha scritto:
The typo was because Ugo has Hibernate between eyebrow and eyebrow ;-)
Would you rather have OJB there? ;-) Oh by the way, the next version of 
Spring will have OJB support, so we could make a SpringPetstore version 
that supports both, if you want to help.

I think the idea is excelent. We need to polish it before start or not?
I have already started. There's some code attached to the wiki page for 
your pleasure, but nothing that cannot be completely redone if it's not 
good enough.

Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Antonio Gallardo]

Ugo Cei dijo:
> 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.

The typo was because Ugo has Hibernate between eyebrow and eyebrow ;-)

I think the idea is excelent. We need to polish it before start or not?

WDYT?

Best Regards,

Antonio Gallardo

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Marc Portier]

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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Leo Sutic]

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?)

[Nicola Ken Barozzi]

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   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)

[Ugo Cei]

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/


smime.p7s
Description: S/MIME cryptographic signature