>> >>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. >>
I think I failed to express that properly. Thats what I was trying to get at. non-binding +1 >+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. +1 >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. +1 >> >>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... +1/+0 - My Avalon knowledge is limited. I'll probably go along with whomever contributes to the efforts decision. <snip/> >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? > +1 <snip/> >>It seems to me as a fair solution for all. >> >Yep. Agreed. -Andy -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
