cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: [New build system] Status of samples
Date Fri, 28 Feb 2003 18:12:14 GMT

On Friday, February 28, 2003, at 02:44 PM, Stefano Mazzocchi wrote:

> Jeremy Quinn wrote:
>> On Friday, February 28, 2003, at 10:50 AM, Stefano Mazzocchi wrote:
>>> Finally, I think the Cocoon build should also allow you to build 
>>> your own cocoon web site. In this case, your stuff should becomes 
>>> nothing different from a microblock. (please, don't start using this 
>>> terminology, it sucks, it's just to give you the idea)
>> I completely agree. (but I have no suggestions for a solution, sorry)
> don't worry, we'll come up with a solution collaboratively.

I am confidant of that too ;)

>> One of the trickiest things to do with Cocoon is to update an 
>> existing webapp with a new version of the code and configs.
> Yep!
>> The configs pose the largest problem. 1) they change often, 2) you 
>> often have to modify them with your own datasources (etc.).
> A solution for this is already designed into the COB concept since 
> each COB (the real cocoon blocks, not the static poor-man version we 
> have today) will have their own sitemap, configurations and roles.
> And they will be exposed to those blocks that depend on these 
> transparently.
> But we need a much better avalon container to be able to support this 
> concept.

I remember the discussions.

>> While it is important to have a simple build, so you can see it works 
>> out of the box (as we have now), I am looking at the scenario whereby 
>> a user wants to update an existing cocoon installation with a fresh 
>> update from CVS, first for testing, then for production. Or wants to 
>> build an installation of samples.
>> so I see 4 common scenarios :
>> 1) a 'test' build and run (we have that and it's great!)
> yes, I wanted to reach this point first and I think I did.

agreed :)

>> 2) a 'samples' build and run
> This is the next thing to tackle.

There are lots of people on Users, wondering where the samples are.

I know you want to find the right way of doing it, and I applaud your 
efforts, but it is not going to happen overnight.

I don't know if it possible to make the samples work at all ATM. But if 
there is a way, it would be good to make a note about it in the 
install.txt file, as a short-term work around.

>> 3) an 'update' build and run (on an internal testing port)
>> 4) an 'update' build and run (on a production port)
> Without a complete redesign of the way Cocoon handles components and 
> internal dependencies this is going to be tricky to say the least. 
> Hacky for sure.

Yeah, I can only think of the hacks ATM ;)

All this work will pay off in many ways.

> During the last few months I thought about forking Cocoon and work on 
> my own tree until a new architecture for block loading was in place, 
> but I feared that this move would have created too much social 
> friction (been there, done that), so I'm choosing an evolutionary path 
> which might be rather annoying for those working on the tree (Carsten 
> already expressed his feelings about this) but keeps the community 
> together.

I am sure we are all glad you did not do that =:-O

> This evolutionary path goes thru creating a cleaner build system and 
> really factors things out on a dependency base.

The evolutionary path is good it is pragmatic.

I guessed some frustration on your part, was the trigger for you to 
tackle this. But then, that is how this community works ;)

> I do have an architectural solution that will solve *all* your 
> usability problems and I outlined it in my COB proposal.


> But I want to release Cocoon 2.1 before even attempting to do such a 
> major refactor.

So we need a temporary solution for various things.

> At that point, 2.1.x will solidify while the brave men between us will 
> tear everything apart and start over with Cocoon 2.2 on a new CVS 
> module.
> When I say "tear everythign apart" I don't want you to worry: cocoon 
> is so well architected internally that we can redesign everything 
> inside without having to touch *ANY* of the contracts with the > outside.
> This is why I see this as Cocoon 2.2 instead of 3.0: there will be 
> complete component-level back compatibility and your webapps will work 
> just fine.
> But this is the future.

Sounds good to me.

> For now, what we can do is to refactor things so they are cleaner.

Well, I'll keep on testing ;)

> For the 'update' scenario, we'll do some hacks for now while we work 
> on a serious solution for the next generation.
>> I am sorry I do not actually have any solutions, I am just thinking 
>> about what I reckon people want to be able to do easily.
> The solutions are already there, Jeremy, trust me.

I do ;)

regards Jeremy

View raw message