Stefano,
Excellent points all.
I am still a bit unconvinced about the near to mid-term viability of a
single container, and I think that the issue of portability by contract is
important, but your argument about the community issues is quite compelling.
Is there any happy middle ground that basically creates a single sub-project
that is communally responsible for all official Avalon containers? That
should eliminate the one-man shop pet containers problem; pet containers can
be implemented elsewhere, and linked off-site. It would help to build a
community, and encourage cooperation and sharing. The container sub-project
would decide what (and how many) official containers are necessary, and
support them. This division separates technical issues from community
issues. The community issues need to be resolved now, but I believe that
technical issues may take longer. If the community is healthy, is the
latter really a problem? Others have pointed out that multiple containers
can be healthy for development.
Again, I don't have a problem with Peter's ubercontainer. My only two
issues are (1) that portability by contract not be lost, and (2) I just
don't think that the ubercontainer is going to develop all that quickly, so
I am looking at the pragmatic road rather than the glorious destination.
One other question, perhaps from ignorance. You appear to be saying that
Avalon Components ought to move to Jakarta Commons. I was under the
impression that Commons was for items that were fairly independent, whereas
Avalon Components require an Avalon Container. Would you please elucidate?
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
