Nicola Ken Barozzi wrote: >From: "Steven Noels" <[EMAIL PROTECTED]> > >>Andy wrote: >> >>>Steven wrote: >>> >>>>So I am all unofficial +1 for having a separate module for Cocoon >>>>contributions, where we can add the POI integration work, if enough >>>>people step up as a maintainer. >>>> >>>+1 if there are enough to justify it. >>> >>I hope the remainder of my arguments are not lost, however. This is >>suboptimal solution until POI admits it really should become part of >>their own codebase. Only the real Cocoon-specific classes should >>eventually go into the contrib section of Cocoon CVS. POI supporting XML >>is not in scope for Cocoon, neither. >> > >Cocoon is becoming overcrowded with optional components, and this is a fact. >For this, I think that we need a contrib section, which is optimal for >Cocoon IMHO. In the near future it will be the famous "Cocoon Blocks" >section. > >I'm +1 for this. I'm refactoring examples in this direction, and will commit >ASAP. >
+1 also. But IMO we should distinguish "contrib" and "optional" : - "contrib" means donated (and accepted) code that didn't find a better place, but is not actively maintained by the Cocoon team, - "optional" means code that is related to a third party library that is isn't core to Cocoon, and supported and maintained by the team. We have also to be very careful that these sections don't become a giant mess, and that they have good visibility so that users know what's inside. > >There is also a strong user need for XML serialization of POI formats, and >this is another fact. >I have the same feeling Sylvian has, that there is a need for xml >serialization outside Cocoon, and AFAIK noone argued against this need. >But we all should remember that POI is still in early stages in formats >other than Excel, and it has to stay tightly focused if it wants to grow >fast; this is how Andy and Marc made the project get to current level, and >it's a strategy that works. > >I understand that this XML conversion stuff is not a thing that only Cocoon >needs, but this can be said also to of cocoon contributions. > >All Cocoon Generators, Serializers and Transformers could be used out of >Cocoon, and IMHO this could make a cool project itself. > For generators, it has been shown that a lot of them can be designed as a Source. And Source has been moved to Avalon Excalibur. Cocoon is still using it's own source because Avalon source is not yet official, but the switch is likely to come in the forthcoming months. And then, Avalon people are likely to have the same feeling for Cocoon than Cocoon has today about the POI serializer... This leads to several project management questions : - where is the limit between projects ? - when should a component be considered independent from it's originating project ? - does implementing an interface mean this implementation belongs to the project hosting the interface ? - who's responsible for maintaining donated code ? What are people's thoughts on all this ? >I think that the best solution now is to make a contrib section, move there >all stuff that is not core Cocoon, and investigate on making wrappers to >make these Components act also autonomously. > >What do you think? > That's a good idea for Cocoon related-code. But we should avoid as much as possible the Cocoon CVS to become a host for XML-related code of other projects that has no dependency on Cocoon (yes, you can read "ContentHandler implementation for the POI serializer"). In this process, we should also better organize packages to more easily isolate non-core components in the package tree. >It seems to me as a fair solution for all. > Yep. Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
