Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Subject: Re: POI Serialization code committed
From: "Andrew C. Oliver" <acoliver@apache.org>
To: cocoon-dev@xml.apache.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 12 Mar 2002 06:56:28 -0500
Message-Id: <1015934188.3880.1079.camel@linux2.superlinksoftware.com>
Mime-Version: 1.0


>>
>>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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org