Antonio Gallardo wrote:
>
> I mean, committer right. Is this posible?
>
> AFAIK, currently, each Cocoon committer has this rights:
>
> avalon-components
> avalon-excalibur
> avalon-sandbox
>
Ah, I see - hmm, don't know, I think we have not thought about it yet.
I will bring this point up as soo
Carsten Ziegeler dijo:
> Antonio Gallardo wrote:
>>
>>
>> Can I jump there? I am waiting to the Excalibur TLP setup to
>> go there. I will be glad to help there too.
>>
> Great news!
> It's a usual Apache open source project, so everyone can be
> part of it.
I mean, committer right. Is this posibl
Antonio Gallardo wrote:
>
>
> Can I jump there? I am waiting to the Excalibur TLP setup to
> go there. I will be glad to help there too.
>
Great news!
It's a usual Apache open source project, so everyone can be
part of it.
It will take some more days until the project is setup :(
Carsten
Carsten Ziegeler dijo:
> Pier Fumagalli wrote:
>>
>> SNIP GOOD EXPLANATION
>>
>>
>> This is more or less the status at the moment, so as you can
>> see, there is _still_ a lot of stuff to be done and thought of...
>>
>> I'm using VNU's project as a guinea pig, to figure out all
>> logical bugs that
Pier Fumagalli wrote:
>
> There are some core problems with the Avalon APIs which are
> orthogonal to blocks deployment...
>
> As a first, all selections are based on real-java-objects
> (tell me how to "require" a block that has no components,
> like a Forrest Skin and I'll be happy).
>
> Se
Pier Fumagalli wrote:
>
> SNIP GOOD EXPLANATION
>
>
> This is more or less the status at the moment, so as you can
> see, there is _still_ a lot of stuff to be done and thought of...
>
> I'm using VNU's project as a guinea pig, to figure out all
> logical bugs that might lie in the kernel, but
Antonio Gallardo <[EMAIL PROTECTED]> writes:
> Hi:
>
> Thanks to all for the answers. All posts helped a lot to go
> out of my confusion.
Ok, I'll bite, what did you decide?
Antonio Gallardo <[EMAIL PROTECTED]> asks:
> Hi:
>
> I need to accept I am lost in the component containers.
>
> Cocoon is migrating to a new container architecture. The
> question remaining in my mind is: How to develop components
> right now?
Good question, I was just wondering this myself
Pier Fumagalli wrote:
[...]
I guess I got this wrong - isn't this distinction based on
the difference between compile time / runtime? My component
will use a logger and a configuration in any case, but maybe
it doesn't know which services it will need later on. When it
"requires" each other block i
On 3 Jun 2004, at 13:16, Andreas Hartmann wrote:
Second of all (but I think this is solvable) component selection is
kinda weird and goes totally against the IOC principles.
A block should require another block, it should not by any means
"select" a block as we do now with component selectors)..
Antonio Gallardo wrote:
Andreas Hartmann dijo:
I'm sorry to join the discussion without any knowledge
about the blocks concept, but I'm interested in learning them.
Could somebody give me a short pointer to a useful resource?
http://wiki.cocoondev.org/Wiki.jsp?page=BlockIntroduction
http://wiki.co
Andreas Hartmann dijo:
> I'm sorry to join the discussion without any knowledge
> about the blocks concept, but I'm interested in learning them.
> Could somebody give me a short pointer to a useful resource?
http://wiki.cocoondev.org/Wiki.jsp?page=BlockIntroduction
http://wiki.cocoondev.org/Wiki.j
Pier Fumagalli wrote:
[...]
As a first, all selections are based on real-java-objects (tell me how
to "require" a block that has no components, like a Forrest Skin and
I'll be happy).
I'm sorry to join the discussion without any knowledge
about the blocks concept, but I'm interested in learning t
On 3 Jun 2004, at 07:30, Gianugo Rabellino wrote:
Anyway, the thing is we are considering moving towards a container
that doesn't follow even Framework's specs. But in that case, be
assured that there will be some kind of compatibility.
On 3 Jun 2004, at 07:40, Carsten Ziegeler wrote:
I don't wan
As I'm one of the people who did pick up the "container challenge"
(twice now, first with Avalon, and now with my take on the Cocoon
Kernel), I ought to give an answer...
There are two core problems that "real blocks" are trying to solve, and
both of them are not rocket science.
The first prob
Carsten Ziegeler dijo:
> Sylvain Wallez wrote:
>>
>> You have to consider two very different things:
>> - the Avalon framework APIs (LogEnabled, Serviceable,
>> Configurable, etc.)
>> - the container that implements the framework behaviour
>>
>> Although the container implementation may change, the
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
You have to consider two very different things:
- the Avalon framework APIs (LogEnabled, Serviceable,
Configurable, etc.)
- the container that implements the framework behaviour
Although the container implementation may change, there's a
strong co
Le 3 juin 04, à 09:22, Antonio Gallardo a écrit :
...Yep. I told switch, because it was not clear if all of us will
accept to
drop the Rhino merge effort...
Is anybody actually working on this merge?
(apart from the work done on clearing out the licensing issues)
As "he who does the work decides",
Steven Noels dijo:
> On 03 Jun 2004, at 08:41, Antonio Gallardo wrote:
>
>> Yep. The Sylvain idea sound great! Can we switch the Rhino merge for
>> this
>> new task?
>
> Do you mean 'drop' instead of 'switch'?
Yep. I told switch, because it was not clear if all of us will accept to
drop the Rhino
Bertrand Delacretaz dijo:
> Le 3 juin 04, à 08:41, Antonio Gallardo a écrit :
>
>> ...Yep. The Sylvain idea sound great! Can we switch the Rhino merge
>> for this
>> new task?
>
> Well, if you have the resources I'd say: go for it!
I don't have the resources right now. :(
But, since it is a very
On 03 Jun 2004, at 08:41, Antonio Gallardo wrote:
Yep. The Sylvain idea sound great! Can we switch the Rhino merge for
this
new task?
Do you mean 'drop' instead of 'switch'?
I'm all +1 for continuing on the research path of
webcontinuations. If Java continuations have a more stable foundation
to
Le 3 juin 04, à 08:41, Antonio Gallardo a écrit :
...Yep. The Sylvain idea sound great! Can we switch the Rhino merge
for this
new task?
Well, if you have the resources I'd say: go for it!
-Bertrand
Bertrand Delacretaz wrote:
Le 3 juin 04, à 08:26, Sylvain Wallez a écrit :
- Flow/JS suffers from the legal situation of Rhino+cont and the
difficulty to merge the fork into the Mozilla trunk. I suggested as a
solution to use JavaFlow to instrument Rhino-generated bytecode. That
would lead t
Bertrand Delacretaz dijo:
> Le 3 juin 04, à 08:26, Sylvain Wallez a écrit :
>> - Flow/JS suffers from the legal situation of Rhino+cont and the
>> difficulty to merge the fork into the Mozilla trunk. I suggested as a
>> solution to use JavaFlow to instrument Rhino-generated bytecode. That
>> wo
Hi:
Thanks to all for the answers. All posts helped a lot to go out of my
confusion.
Best Regards,
Antonio Gallardo
Sylvain Wallez wrote:
>
> You have to consider two very different things:
> - the Avalon framework APIs (LogEnabled, Serviceable,
> Configurable, etc.)
> - the container that implements the framework behaviour
>
> Although the container implementation may change, there's a
> strong commitment t
Le 3 juin 04, à 08:26, Sylvain Wallez a écrit :
- Flow/JS suffers from the legal situation of Rhino+cont and the
difficulty to merge the fork into the Mozilla trunk. I suggested as a
solution to use JavaFlow to instrument Rhino-generated bytecode. That
would lead to a unified code base allow
On Jun 3, 2004, at 7:31 AM, Antonio Gallardo wrote:
Cocoon is migrating to a new container architecture. The question
remaining in my mind is: How to develop components right now? In the
sense
that we don't want to write components for ECM, because it is almost
dead.
How to avoid to rewrite when
Antonio Gallardo wrote:
Hi:
I need to accept I am lost in the component containers.
Cocoon is migrating to a new container architecture. The question
remaining in my mind is: How to develop components right now? In the sense
that we don't want to write components for ECM, because it is almost dead.
Le 3 juin 04, à 07:31, Antonio Gallardo a écrit :
...Cocoon is migrating to a new container architecture...
Is it really? Don't get me wrong, there is great work being done in
this area, but IMHO this will take some time to actually materialize as
a release.
...The question
remaining in my mind
Hi:
I need to accept I am lost in the component containers.
Cocoon is migrating to a new container architecture. The question
remaining in my mind is: How to develop components right now? In the sense
that we don't want to write components for ECM, because it is almost dead.
How to avoid to rewri
31 matches
Mail list logo
