From: "Sylvain Wallez" <[EMAIL PROTECTED]>
> Nicola Ken Barozzi wrote:
>
> >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...
;-) Yes, didn't think about this.
> This leads to several project management questions :
These are very important questions that need IMO a very clear stance; it's
good you made this point clear.
IMHO it could be a good thing to add these to the Constitution, to use this
case as a guide to future issues, but it's just my opinion.
> - where is the limit between projects ?
Each project has a scope, that has to be as clear as possible. Before
accepting a donation, it should be seen if it fits in the scope. If not, the
community must decide to enhance the scope, or reject the donation. If the
donation is rejected, IMHO there should be given a practical alternative.
Just saying no is not constructive. I would reccommend to have already
possible outcomes like (for example):
- ask xml-commons or jakarta commons
- ask to make it a separate project
- ask to make a sub-project
- come back when there is a community
> - when should a component be considered independent from it's
> originating project ?
When it can stand on its own, as per community.
> - does implementing an interface mean this implementation belongs to the
> project hosting the interface ?
No. If it was so, SAX would be full of contributions ;-)
It could belong to any project *using* that interface.
If more projects use this interface, it's a good point in making it
separate.
If a single project uses the interface, but the contributions are more than
the project itself, it make sense to separate them also.
These rules could have helped in this case.
Both argumentations apply to xml-POI in Cocoon.
Since POI doesn't use that interface, it could not automatically host it.
> - who's responsible for maintaining donated code ?
The donor is the first candidate. If not, there must be a community around
it that will maintain it. If there is noone willing to maintain it, it
wouldn't live in any case.
> >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").
Cocoon optional and Cocoon contrib could solve this, as you outline.
But the possibility of having a module that can live also indipendently from
Cocoon intrigues me.
Cocoon optional could become a repository of all stuff that converts from-to
XML SAX. Something like "Cocoon Metamorphosis". Each Block could be used by
itself as a conversion tool or in Cocoon.
> In this process, we should also better organize packages to more easily
> isolate non-core components in the package tree.
Yup. It's easy to see what goes in optional, it's all the classes that have
an optional-warning already.
This would eliminate the need of the xconf tool in the main Cocoon build.
> >It seems to me as a fair solution for all.
> >
> Yep.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
