At 01:12 AM 6/21/2002 +0200, you wrote: > - it doesn't state that multiple implementations of the framework are >allowed to be hosted under the same project. > > - it doesn't state that the project should be dissected into different >sub-projects
Nor does it say what color our web pages should be or whether we should use centipede or maven or do X or Y. The community decides the charter by living it or not. Be careful not to confuse your opinions with the communitys opinions - just because you had initial idea does not mean it has not evolved since you departed. See the ant-dev reaction to JDD as an instructive example of the reaction that this sort of thinking can produce. >(NOTE: I think the whole turbine-like subprojecting has hurt Avalon >*a*lot* expecially in terms of political visibility around the ASF, >almost everybody at the top think that both Turbine and Avalon are >somewhat abusing sub-sub-projecting. I totally agree with them.) It arises because of the political climate at jakarta. It is only going to get "worse" overtime. Ant already has 3 CVSes I expect it to jump by another two within a year. Rather than letting darwin handle software selection, political barriers have been put up time and time again - so much so that I now recomend people go to sourceforge if they want to control their own projects or create sub-projects in Apache. I have heard several people say how bad this (or the closely related argument that the size of Jakarta is bad or that jakarta is broken) is but as yet no one (except Sam and Geir to a lesser extent) has ever stepped up to try and solve the causes for this behaviour. First of all, without clear guidelines and a solid way to enforce them, >transparent component portability is not possible. This is why we worked >hard to define all those empty marker interfaces (that nobody understood >until we had a working implementation of them, that took more than a >year!). Marker interfaces are a liability - while they exist there will never be inter-container compatability. The reason is that it will never be possible to encode all meta data as as marker interfaces. So you will end up with people encoding metadata into components code, into descriptors, into containers code etc. Not great for maintainability, makes it impossible to separate assembly from development etc etc. External per-component descriptors (or bytecode augmentation as of JDK1.6) is the only real solution but it has never been deemed acceptable by Cocoon developers - hence why it has never occured. That would need to be accepted before progress could be made. >What I'd like to see in the future of Avalon: > > 1) reunion: Avalon becomes Avalon. One thing. One distribution that >includes: > > - the framework interfaces > - the framework reference implementation > - the docs and examples It is technically possible but that has never been the issue. The issue is one of community. I have been told that cocoon community would never accept; * separation of jars into small jars * separation of metainfo from code * separation of assembly and developer roles * separation of directory service from resource management Mostly this has been on the grounds that "it is too complex". Yet now we have people from cocoon who are complaining that they live in "pattern hell" or that their system does not scale well or that ... All of these complaints are a direct result of the choices you made above. If you separate the features out then your "pattern hell" would disappear, and a large chunk of complexity would disapear. Luckily some Cocoon people (hi Leo!) have started to realize this and even described features for separating assembly from developer roles and called it a killer feature! However I am not part of the cocoon community and there is little I can do that will make you realize that violating SOC is bad. I really hope Leo implements his ideas soon because I am sure that once he has implemented it he will find out how insane it it is to merge the notion of resource manager and directory service. I suspect he will also be wishing for separation of metainfo sooner rather than later. However while people still insist that mixing concerns is a good thing then I doubt there can be just one container. It would be an absolutely fantastic thing to have one though. >we, as a >community, *DO* *NOT* have the right to create internal subprojects as >for the jakarta bylaws! Sure we do. >But how do you make them use Avalon? by giving users functionality! > >and what is the best functionality if not the ability to reuse prebuilt >components and create your own? This would be fantastic. There are several bits of cocoon already in excalibur that I would love to be able to use (monitor, xml stuff, sourceresolve stuff) and I know it would be a very very big draw card if I could use them un-altered. However I haven't been able to use them except by changing them in ways that would break them in context of cocoon. Anyhow if you really want this then you really need to consider whether you want to continue with the "discussions" regarding release(), and lookup() with roles as the merging of concerns will never be accepted as good practice and thus there will be no progress. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
