On 18 Oct 2004, at 10:57, Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is co
Carsten Ziegeler wrote:
...
The basic idea is to build an own version of ECM
+1
Rub a dub dub
http://www.joelonsoftware.com/printerFriendly/articles/fog000348.html
In Defense of Not-Invented-Here Syndrome
http://www.joelonsoftware.com/printerFriendly/articles/fog07.html
Things You Shoul
Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be b
Reinhard Poetz wrote:
Ralph Goers wrote:
I would suggest that new o.a.cocoon interfaces be used which, for the
time
being simply extend the existing interfaces. The use of the
avalon/excalibur interfaces should be deprecated. This will allow the
complete removal of Avalon/Excalibur in the future
Ralph Goers wrote:
I would suggest that new o.a.cocoon interfaces be used which, for the time
being simply extend the existing interfaces. The use of the
avalon/excalibur interfaces should be deprecated. This will allow the
complete removal of Avalon/Excalibur in the future.
Don't know, if this i
I would suggest that new o.a.cocoon interfaces be used which, for the time
being simply extend the existing interfaces. The use of the
avalon/excalibur interfaces should be deprecated. This will allow the
complete removal of Avalon/Excalibur in the future.
Ralph
Carsten Ziegeler said:
> Ralph
Ralph Goers wrote:
>
> I encourage Carsten to wholeheartedly undertake this task. I
> really only have two thoughts.
> 1. I don't think it is a good idea to keep the same package
> names for ECM if they are moved into Cocoon. That could be
> very confusing. I realize it would be a lot of wo
Carsten Ziegeler wrote:
I just started with this approach and could finish it in the next days
if people think it is worth going this way. It would give 2.2 more meat
as well.
But perhaps this idea is totally foolish?
Thoughts? Comments?
+1
Seem like a very reasonable way to go, we both takes ca
I encourage Carsten to wholeheartedly undertake this task. I really
only have two thoughts.
1. I don't think it is a good idea to keep the same package names for
ECM if they are moved into Cocoon. That could be very confusing. I
realize it would be a lot of work to rename existing classes tha
Carsten Ziegeler wrote:
Adding new things on top of an old one provides a smooth migration
path, as you can still use the old ones and one or two additional
ones.
If you have a compatibility layer this most often means that you
can either use this layer or the new functionality. So there isn't
a s
Sylvain Wallez wrote:
> As long as the compatibility layer remains, I don't see what
> invites people to migrate to new features. Is it just because
> new features will be available? Then having them because of
> an updated old container or because of a newer one with a
> legacy layer isn't
Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be b
On Monday 18 October 2004 20:48, Ugo Cei wrote:
> As we cannot depend on the Avalon community for mending some of these
> deficiencies, I heartily applaud Carsten's effort towards bringing that
> code inside, so we can at least try fixing them ourselves.
Small correction; ECM is in excalibur.apac
On Monday 18 October 2004 17:57, Carsten Ziegeler wrote:
> But perhaps this idea is totally foolish?
Not at all.
Very pragmatic, well balanced and sensible thing to do.
And it seems you have a lot of support, and if that support is translated in
to coding help, we are all grateful.
Cheers
Nicla
Il giorno 18/ott/04, alle 14:29, Vadim Gritsenko ha scritto:
And what is wrong with that approach (of just using it)? Beside
community issues there were no technical issues which would force us
to move people out of current component management infrastructure.
Right?
Personally, I think there ar
Vadim Gritsenko wrote:
>
> Sounds good with the only exception that I'm not sure about
> instrumentation vs JMX part. Anybody have ideas how Cocoon
> should be integrated with JMX? What management console we
> would use then?
>
I think this is an open topic. The first thing imho is to remove
t
Le 18 oct. 04, à 11:57, Carsten Ziegeler a écrit :
...I just started with this approach and could finish it in the next
days
if people think it is worth going this way. It would give 2.2 more meat
as well...
I like the idea of having our own version of ECM, and if you have code
already I'd say go
Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be b
Il giorno 18/ott/04, alle 14:14, Carsten Ziegeler ha scritto:
I totally agree, we should have tests. Now, I'm not sure what the
best way to do this is. As I already started :), I think finishing
this first phase, committing it, then adding tests, continuing is
at least for me a little bit easier.
B
Ugo Cei wrote:
>
> Il giorno 18/ott/04, alle 11:57, Carsten Ziegeler ha scritto:
>
> > The basic idea is to build an own version of ECM, which is:
> > grabbing the current ECM code, removing everything we don't
> need and
> > build a complete container in Cocoon that provides the minimum
> > f
Il giorno 18/ott/04, alle 11:57, Carsten Ziegeler ha scritto:
The basic idea is to build an own version of ECM, which is:
grabbing the current ECM code, removing everything we don't
need and build a complete container in Cocoon that provides
the minimum functionality.
Hmmm, I like it. But I wouldn'
On 18 Oct 2004, at 11:57, Carsten Ziegeler wrote:
Thoughts? Comments?
I like. Not for compatibility reasons, but merely for untying us from
the ECM knot. If and when we get to move Cocoon further along the road
of our own thing, at least we will have a stable baseline to fall back
to.
--
Steve
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be bad
if someone had to re
23 matches
Mail list logo
