cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: POI Serialization code committed
Date Tue, 12 Mar 2002 10:00:46 GMT
Nicola Ken Barozzi wrote:

>From: "Steven Noels" <stevenn@outerthought.org>
>
>>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:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message