The value of src/core (or lack thereof)
Hi all, The src/core directory was initially created to clearly separate the development of ECM++ and ensure it had no dependencies of other parts of Cocoon. All went well until we added some fancy features like includes, variable expansion, etc, which led an increasing number of classes to move from src/java to src/core. Having e.g. classes in the o.a.c.environment packages spread over the two directories is somewhat confusing. What this shows is that although the Cocoon engine has very few dependencies on ECM++, ECM++ has an increasing number of dependencies on the Cocoon engine. Since we recently added support for other component containers _inside_ ECM++, what is now the real value of src/core? Not much IMO. So I propose to remove src/core and move all its content to src/java. WDYT? Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: The value of src/core (or lack thereof)
Sylvain Wallez wrote: Hi all, The src/core directory was initially created to clearly separate the development of ECM++ and ensure it had no dependencies of other parts of Cocoon. All went well until we added some fancy features like includes, variable expansion, etc, which led an increasing number of classes to move from src/java to src/core. Having e.g. classes in the o.a.c.environment packages spread over the two directories is somewhat confusing. What this shows is that although the Cocoon engine has very few dependencies on ECM++, ECM++ has an increasing number of dependencies on the Cocoon engine. Since we recently added support for other component containers _inside_ ECM++, what is now the real value of src/core? Not much IMO. So I propose to remove src/core and move all its content to src/java. WDYT? I think that I agree :) I have also thought about the separation between src/core and src/java lately as it have becoming increasingly unclear to me where the border should be with the recent aditions to core. IMO there would be a value in the separation, if we put what is needed for executing the sitemap engine and basic apis in core and nothing else. So that the core is the basic execution and component management mechanism for Cocoon. But I would assume that it would be quite a lot of work to get the border right and we have more important things to do, so for the moment it is probably better to merge the trees. I would assume that we will need to do some refactorings of the core parts of Cocoon when we start to develop the block manager, to get the right level of isolation between blocks. When we have done that, it might be clearer exactly what constitutes the core, and then we can maybe factor out the core to a separate jar, but right now the border seem to fuzzy to be worthwhile keeping IMHO. /Daniel
Re: The value of src/core (or lack thereof)
Bertrand Delacretaz wrote: Le 7 avr. 05, à 12:39, Sylvain Wallez a écrit : ...Since we recently added support for other component containers _inside_ ECM++, what is now the real value of src/core? Not much IMO. So I propose to remove src/core and move all its content to src/java... +1 Should we also deprecate the direct use of ECM++ in some way, and encourage people to use other containers at the application level? -Bertrand We should IMO not deprecate it in the meaning that we are going to stop support it. Considering the amount of user code that probably depends on the Avalon framework we should support it for a long time. But we could certainly encourage people to use other containers in our documentation, if we think that our support for that already is good enough (haven't tried it yet). /Daniel
Re: The value of src/core (or lack thereof)
Le 7 avr. 05, à 13:43, Daniel Fagerstrom a écrit : ...We should IMO not deprecate it in the meaning that we are going to stop support it. Considering the amount of user code that probably depends on the Avalon framework we should support it for a long time. But we could certainly encourage people to use other containers in our documentation, if we think that our support for that already is good enough (haven't tried it yet). 100% agreed, that's what I meant. I've been testing the new spring-app stuff, and using hivemind in other projects, and both work very well. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: The value of src/core (or lack thereof)
Daniel Fagerstrom wrote: Bertrand Delacretaz wrote: Le 7 avr. 05, à 12:39, Sylvain Wallez a écrit : ...Since we recently added support for other component containers _inside_ ECM++, what is now the real value of src/core? Not much IMO. So I propose to remove src/core and move all its content to src/java... +1 Should we also deprecate the direct use of ECM++ in some way, and encourage people to use other containers at the application level? -Bertrand We should IMO not deprecate it in the meaning that we are going to stop support it. Considering the amount of user code that probably depends on the Avalon framework we should support it for a long time. +1. Avalon interfaces are and will be for a long time important pieces of Cocoon, and we have in 2.2 our own implementation, that along with hosting user components is also the hosting infrastructure for other containers. So although user components may slowly move away from Avalon APIs, the container of container will have an increasingly important role. But we could certainly encourage people to use other containers in our documentation, if we think that our support for that already is good enough (haven't tried it yet). +1. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: The value of src/core (or lack thereof)
Sylvain Wallez wrote: So I propose to remove src/core and move all its content to src/java. +1 Vadim
Re: The value of src/core (or lack thereof)
Sylvain Wallez wrote: So I propose to remove src/core and move all its content to src/java. +1 --Tim Larson
Re: The value of src/core (or lack thereof)
Nathaniel Alfred wrote: Sylvain Wallez wrote: So I propose to remove src/core and move all its content to src/java. Good idea also on purely technical grounds. When importing a snapshot of the Cocoon sources as vendor branch into CVS one has to do some special gymnastics to avoid that the core directory falls victim to the implicit cvsignore rules on Unix. Aha! I already had problems when trying to name a directory cvs in a CVS repository (it was for the CVSSource) but never encountered this one! As there seems to be some general consensus, I'll do the move in the coming days except if someones raises an objection. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: The value of src/core (or lack thereof)
Sylvain Wallez wrote: Hi all, The src/core directory was initially created to clearly separate the development of ECM++ and ensure it had no dependencies of other parts of Cocoon. All went well until we added some fancy features like includes, variable expansion, etc, which led an increasing number of classes to move from src/java to src/core. Having e.g. classes in the o.a.c.environment packages spread over the two directories is somewhat confusing. What this shows is that although the Cocoon engine has very few dependencies on ECM++, ECM++ has an increasing number of dependencies on the Cocoon engine. Since we recently added support for other component containers _inside_ ECM++, what is now the real value of src/core? Not much IMO. So I propose to remove src/core and move all its content to src/java. WDYT? +1 -- Stefano.
Re: The value of src/core (or lack thereof)
So I propose to remove src/core and move all its content to src/java. WDYT? +1 -- Torsten signature.asc Description: OpenPGP digital signature
