Re: [RT] Building ECM++ for 2.2
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 Should Never Do, Part I http://www.joelonsoftware.com/printerFriendly/articles/fog69.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Building ECM++ for 2.2
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 compatibility. That's why I was talking to Stefano about implementing blocks in the current architecture... Although it's a sitemap hack (or at least, it won't provide the full flexibility that blocks _really_ require), it will give a migration path in which certain features could be shared between the current and possible future codebase, and easing the conversion from one platform to another... That's my 0.02£ Pier smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Building ECM++ for 2.2
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. /Steven -- 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: [RT] Building ECM++ for 2.2
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't like you grabbing the ECM, dropping things that aren't needed, changing names and showing us the finished work in a few days. I'd like us to express contracts in a set of interfaces and test-cases first. Then, step by step, copy code over from ECM to satisfy those tests, until we have a fully-tested container. I can help with this. WDYT? Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
RE: [RT] Building ECM++ for 2.2
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 functionality. Hmmm, I like it. But I wouldn't like you grabbing the ECM, dropping things that aren't needed, changing names and showing us the finished work in a few days. I'd like us to express contracts in a set of interfaces and test-cases first. Then, step by step, copy code over from ECM to satisfy those tests, until we have a fully-tested container. I can help with this. WDYT? 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. But we can do it in a diffent way if you like. I would suggest let's first see what others think of this idea in general. If we have consensus to continue this road we can think about how we can do this best. Ok? Carsten
Re: [RT] Building ECM++ for 2.2
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. But we can do it in a diffent way if you like. I would suggest let's first see what others think of this idea in general. If we have consensus to continue this road we can think about how we can do this best. Ok? OK. I don't mean to stop you if you are in that state of mind where you really can't stop yourself from coding like mad ;-). But as soon as you have some code that you aren't totally ashamed of, please put it in the whiteboard directory. I will try to look at it and see how I can help. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Building ECM++ for 2.2
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 bad if someone had to rewrite his complete application just to update from one version of Cocoon to another. I guess we all agree on this. Now reaching this goal can be done from two sides: a) The new version can have a compatibility layer. b) We can provide a smooth transition from version to version. It would be ideal if we would have both. But with a compatibility layer people tend to just use it without migrating their app. 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? I wondered what we can do to build a better transition and to get users moving away from our current approach to a newer version. A possible way would be to make minor improvements or modifications from version to version until we reach our goal. This could e.g. be done by building ECM++ for Cocoon 2.2. 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. This would be: - using the same configuration (roles and xconf) - provide support of the following avalon based interfaces: LogEnabled, Contextualizable, Parameterizable, Configurable, Serviceable, Disposable, Initializable, Startable Ok, sounds good. What could be the benefit of this? - no support for Composable, Component etc. anymore (so no proxies and wired wrapping anymore). - no LogKitManagable, RoleManager support etc. - no Instrumentation support - we could our own instrumentation (JMX?) - All the code for this container would be ours - only the marker interfaces are of course from Avalon. - We could easily add new features, like the selector handling or the DI from Fortress. Using Fortress is imho out of question as it does rely on too many third party code. By having our own container implementation we could add any support that we think that makes sense for providing a smooth migration path - whereever this path ends :) Now, doing this is fairly easy; it requires just a bunch of code and would reduce our depencies while giving us more flexibility. 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? 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? Vadim
Re: [RT] Building ECM++ for 2.2
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 for it! -Bertrand smime.p7s Description: S/MIME cryptographic signature
RE: [RT] Building ECM++ for 2.2
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 the dependency on instrumentation. We can later on discuss how to do it in a better way - being it readding it or using an alternative. Carsten
Re: [RT] Building ECM++ for 2.2
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 are technical issues as well. Developing components for the Avalon Excalibur platform is much harder that it should be. There are too many lifecycle interfaces and you're never sure which ones you should really implement and how. Having components depend on Avalon interfaces makes reuse harder. Testing is hard. Too many wheels are reinvented (think logging) but too few enterprise services are provided or effectively merged in the platform (transactions, for instance). Checked exceptions are the norm and therefore are widely abused. Then there are Cocoon-specific issues, which might be a consequence of using a certain platform, or maybe not. Things like preferring inheritance over composition, which leads to long inheritance chains, and (again) abusing checked exceptions. 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. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Building ECM++ for 2.2
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 Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+
Re: [RT] Building ECM++ for 2.2
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.apache.org, not Avalon. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+
Re: [RT] Building ECM++ for 2.2
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 bad
if someone had to rewrite his complete application just to
update from one version of Cocoon to another. I guess we
all agree on this. Now reaching this goal can be done
from two sides:
a) The new version can have a compatibility layer.
b) We can provide a smooth transition from version to version.
It would be ideal if we would have both. But with a compatibility
layer people tend to just use it without migrating their app.
snip/
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 very different in this
regard, except that new features are readily available in the second case.
That's why I'm in favor of adding a legacy layer to something new. I
started the avalonization of Spring a few hours ago and the more I dig,
the more the technical issues I felt I would hit disappear one after the
other. I have to stop for now as I have some urgent work to do for
tomorrow (a new training), but that's definitely the way I want to go
instead of adding new features on top of an old thing.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Building ECM++ for 2.2
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 very different in this regard, except that new features are readily available in the second case. That's why I'm in favor of adding a legacy layer to something new. I started the avalonization of Spring a few hours ago and the more I dig, the more the technical issues I felt I would hit disappear one after the other. I have to stop for now as I have some urgent work to do for tomorrow (a new training), but that's definitely the way I want to go instead of adding new features on top of an old thing. 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 smooth migration path in this case. Now, we don't have to add new functionality to the old one, but it is an option. And with this approach we are getting more independent from Avalon/Excalibur without loosing anything. Carsten
Re: [RT] Building ECM++ for 2.2
Carsten Ziegeler wrote:
snip/
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 smooth migration path in this case.
The purpose of a compatibility layer is to be able to use _both_ old and
new features at the same time, otherwise it would be rather useless.
Now, we don't have to add new functionality to the old one, but
it is an option. And with this approach we are getting more
independent from Avalon/Excalibur without loosing anything.
Yup. That's why I have nothing about forking ECM in our repo. But I hope
to prove it's actually even not necessary.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Building ECM++ for 2.2
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 that use those interfaces, but done on the proper release boundary I think it is the right thing to do. 2. JMX is the right way to go for instrumentation. Ralph
Re: [RT] Building ECM++ for 2.2
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 care about backward compability and opens the possiblity to add functionality to the old one or plug in new and sexier component containers. We also get a smoother migration plan if we eventually would like to get rid of the old way of doing stuff. /Daniel
RE: [RT] Building ECM++ for 2.2
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 work to rename existing classes that use those interfaces, but done on the proper release boundary I think it is the right thing to do. The implementation will get of course the o.a.cocoon package names, so everything will be renamed. If course the marker interfaces (Serviceable etc.) will not be renamed. Carsten
RE: [RT] Building ECM++ for 2.2
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 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 work to rename existing classes that use those interfaces, but done on the proper release boundary I think it is the right thing to do. The implementation will get of course the o.a.cocoon package names, so everything will be renamed. If course the marker interfaces (Serviceable etc.) will not be renamed. Carsten
Re: [RT] Building ECM++ for 2.2
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 is necessary at all. If we want to get rid of all those marker interface, we would have two different deprecated interfaces which will confuse more than it helps, IMHO. -- Reinhard
Re: [RT] Building ECM++ for 2.2
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.
Don't know, if this is necessary at all. If we want to get rid of all
those marker interface, we would have two different deprecated
interfaces which will confuse more than it helps, IMHO.
+1.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Building ECM++ for 2.2
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 bad if someone had to rewrite his complete application just to update from one version of Cocoon to another. I guess we all agree on this. Now reaching this goal can be done from two sides: a) The new version can have a compatibility layer. b) We can provide a smooth transition from version to version. It would be ideal if we would have both. But with a compatibility layer people tend to just use it without migrating their app. I wondered what we can do to build a better transition and to get users moving away from our current approach to a newer version. A possible way would be to make minor improvements or modifications from version to version until we reach our goal. This could e.g. be done by building ECM++ for Cocoon 2.2. 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. This would be: - using the same configuration (roles and xconf) - provide support of the following avalon based interfaces: LogEnabled, Contextualizable, Parameterizable, Configurable, Serviceable, Disposable, Initializable, Startable What could be the benefit of this? - no support for Composable, Component etc. anymore (so no proxies and wired wrapping anymore). - no LogKitManagable, RoleManager support etc. - no Instrumentation support - we could our own instrumentation (JMX?) - All the code for this container would be ours - only the marker interfaces are of course from Avalon. - We could easily add new features, like the selector handling or the DI from Fortress. Using Fortress is imho out of question as it does rely on too many third party code. By having our own container implementation we could add any support that we think that makes sense for providing a smooth migration path - whereever this path ends :) Now, doing this is fairly easy; it requires just a bunch of code and would reduce our depencies while giving us more flexibility. 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? +1000! the reasons to follow up right after in another RT -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
