cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
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.

+1

> 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


Mime
View raw message