Peter Donald wrote:
> At 01:20 1/3/01 -0800, [EMAIL PROTECTED] wrote:
> >> Avalons framework (via configuration methods usually). I much prefer to fix
> >> "fix" avalon than to create a new project to replace Avalon.
> >
> >I understand that. And I would agree - if library's goal would be only to
> >create components.
> >
> >But for few people it isn't - the components is just a mean to get to the
> >goals.
> >
> >Please understand I'm not arguing against "fixing" Avalon - and I'm sure
> >the library will give you an excelent oportunity to do that, and
> >componentize what is to be componentized.
> >
> >Again: my goal is a project where existing projects can cooperate. And in
> >order to succeed we need a neutral project. Avalon is far from that.
> >
> >As you said earlier, components will be a by-product - as projects share
> >code and it is componentized, some of it will reach the "product" level we
> >want for components.
> >
> >All your arguments would be right if the library would try only to create
> >components, but this is not the case - and it took us a lot of effort to
> >find a common point and proposals where all our goals can be met.
>
> I agree with the aims but maybe I should structure my objections
> differently ;)
>
> Lets assume for the moment that Jakarta-Forge has been built. It includes
> CJAN/bug-tracking/testing/gumping/gian-java-tree/alexandira/whatever. Each
> project can choose which components to share. For instance I look for to
> the Digester package from struts being packaged separately.
>
It's definitely on my list of useful code to contribute. There are also some
variations on the same theme in other projects that will contribute ideas or
alternative implementations.
>
> The question arises where is that component? Is that component still in
> struts but is "published" to JakartaForge?
I would view the mechanics of the process like this:
* Component XYZ gets approved for inclusion in the library
project, by whatever means is needed.
* Source code from the originating project would be
cleaned of any remaining project dependencies and
imported into the library CVS repository.
* The originating project would replace its existing implementation
of that particular code with wrappers around the new shared
logic (because, at a minimum, the package name changed -- in
many cases there will also be functional changes due to the
cleanup).
* Over time, the package wrapper would be deprecated, and the
shared library component would be used directly.
> Personally I would +1 that
> because it leaves it in the hands of those most capable of maintaining it.
It's also the only way to benefit from viewpoints other than those of the
originating project's developers.
>
> Overtime it may reach such a high status that it is promoted to have
> separate mailing lists etc. Other projects can declare a dependency on
> digester.jar and gump will automatically detect when incompatible changes
> are made. Eventually it may become a top level jakarta project if there
> becomes a need. Lets call this "The Gathering" as CJAN components are
> gathered from projects. If we adopt this approach then I don't see any need
> for any project besides the infrastructure one ;)
>
I'm not as confident as some on this list that any component like a Digester or DB
connection pool would ever grow to the status of a "top level" project. I think
there is a level of functional complexity, and size of developer community, that
distinguishes a "project" from a "component". For many of the components we're
talking about, can you imagine that even the three developer minimum can be
reached, after the original burst of interest dies down? I can't.
We need a place where a "set" of components can live, and hope to build a
community of developers that care about more than just the components that they
originally wrote (even though their primary focus will stay on those).
>
> What I believe you are advocating is creating a new CVS to which this
> component is added (ie moved out of struts into another CVS). This new CVS
> could also act as a breeding ground for new components??? It is this aspect
> that I believe should be within Avalon. Creation and sharing of components
> was one of the things Avalon was setup to do (admittedly it failed but
> ...8]).
>
> I am not sure why you believe that Avalon would not be neutral. I believe
> the majority of the committers would be happy to help develope JavaBean
> style components etc. I have no problem components not conforming to the
> Avalon-Framework (as long as they are in another CVS) and I believe the
> others would agree.
>
As I said in the previous message, I am concerned about the possible *perception*
of non-neutrality. Even if I believe that this is a non-issue, is that going to
be true for everyone? Is there a compelling reason that the component library
piece *should* be named Avalon, other than the fact that it was in the original
(admittedly failed) vision?
>
> You may say my concerns are not real or I am splitting hairs ;) In the long
> run if all goes well then I say we do split it off into it's own project
> (or even own domain - ala jpan.apache.org). However at the moment there is
> too much overlap with Avalon. I agree that the charter of Avalon should be
> reduced (in time) and library-dev should take over some of it.
>
> For the moment how about developing under Avalon and as soon as it is
> obvious that the project can stand on it's own two feet and its goals are
> being met (ie framework agnostic). It is split off to form it's own project
> and Avalons charter is amended. Not to be a nay-sayer but I have been
> involved in many projects that have tried to do the similar (kinda my
> thing) and it wasn't until I cam across ant and avalon that I saw it
> working. (I assume it also happens in taglibs but I don't use jsp).
>
There is a very practical reason why I would dislike any potentially temporary
move -- package names. I never ever ever want to have to change them again.
If we go to an Avalon-based environment (org.apache.avalon.digester) and then at
some point graduate to an agora project (org.apache.agora.digester) or even its
own top level project (org.apache.digester), the effort to deal with those changes
is disruptive (and non-backwards-compatible), and totally wasted.
I want package names and organizational structures for shared components that are
"right" (to the maximum extent we can achieve that) now and forever more. I want
to create fully qualified package names for these components that survive any
organizational change that we might make later. It's going to be hard enough
overcoming peoples's "not invented here" attitudes to get them to use shared
components in the first place -- they don't need this possible disincentive.
>
> Most projects that attempt this work for a little while until people
> realize how "boring"/"difficult" working on infrastructure can be. At that
> point it tends to stagnate. I really don't want to see another one of these
> projects happen ;) Especially when it could be me who ends up having to
> support any orphaned components ;)
>
If we succeed in having library components that are used in one or more projects,
I don't think there is much risk of orphans -- the more likely future I see is
conflict over future directions for those components. But the projects that *do*
use them have a vested interest in maintaining them (I will certainly care just as
much about a shared Digester as a Struts-hosted one, for example, because Struts
needs it).
If a component isn't used, then I guess it must not have been all that worthwhile
in the first place ...
>
> Cheers,
>
> Pete
>
Craig
