commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: Initiating commons projects (was [Betwixt] Mapping Beans to Beans)
Date Mon, 04 Oct 2004 04:51:34 GMT
See intermixed.


On Mon, 04 Oct 2004 10:40:04 +1300, Simon Kitching
<simon@ecnetwork.co.nz> wrote:
> On Mon, 2004-10-04 at 11:19, robert burrell donkin wrote:
> > On 29 Sep 2004, at 04:11, Brian Pugh wrote:
> >
> > > I know this thread is a few weeks old, but I just came across it and I
> > > find myself needing exactly this kind of a framework for mapping beans
> > > to beans.  I am very "enthused by this idea" and would be willing to
> > > actively participate on a project to create such a framework.  Robert,
> > > are you implying that this is something you might see being done as an
> > > apache project?
> >
> > dunno.
> >
> > it depends.
> >
> > this kind of thing would definitely fit well within the commons.
> > however, successful commons components do require a critical mass of
> > ASF committer energy. sometimes, it can be easier to build a community
> > elsewhere where the rules are different. i don't really have the spare
> > energy to push this through the sandbox by myself.
> >
> > > Would others be interested in such a project if an attempt was made to
> > > create one?
> >
> > that's the big question :)
> 
> This is just my personal opinion, but I don't think that it is a good
> idea for commons to encourage the creation of new projects just because
> "it's a cool idea".
> 
> Commons has traditionally been a place where creation of code has been
> driven by the specific needs of one or more projects. For example
> Digester grew out of tomcat,

s/tomcat/Struts/

Digester was factored out of Struts (along with BeanUtils).  Tomcat
adopted it later, in place of some Tomcat-specific technology for
parsing web.xml and server.xml files -- which, in turn, was my
original motiviation for quite a few ideas in Digester :-).

> BeanUtils grew out of (or at least was
> strongly driven by) struts, lang and collections have been driven by a
> whole number of different projects etc.
> 
> Having a real and immediate user of new code ensures that the project is
> grounded in reality; people complain if the design gets too abstract or
> develops other flaws, because they need to *use* it. It also ensures
> that there are people who have a desire to maintain that code in the
> future.
> 
> I'm not trying to discourage the idea of coding for fun, or the idea of
> following up an interesting concept to see where it might go and what it
> might be useful for. However I would discourage doing this as an
> apache-commons project; Sourceforge or similar seems a much better venue
> for that sort of thing. An abandoned project on Sourceforge is no big
> deal; an abandoned project in commons doesn't look so good.
> 
> The commons sandbox isn't really a good place for general "software
> research", because the barriers to entry for interested people are too
> high. When the people involved are already part of the commons community
> this is less of an issue, but I think even stuff like Craig's "chains"
> module might fare better initially as a sourceforge project.

Actually, the charter of Commons Sandbox was for existing Jakarta
committers to have just such an opportunity -- to play with a new
idea, *or* to factor out some potentially reuable code, and *then* see
if a community could be built around it.  This has been successful for
some packages and unsuccessful for others, but the success rate has
actually been higher than I expected -- and *much* higher than the
success rate for something started at SourceForge and then followed by
an attempted incubation within Apache.  That barrier is simply too
high for small scale packages like most of the things you see in
Commons.

As such, [chain] was exactly within the charter (whether or not there
were ulterior motives to use it in Struts :-).

> IMHO, the sandbox is much more suited to experimenting with new
> implementations of existing commons concepts, or with holding code that
> is in the process of being moved from some existing non-commons project
> into a standalone library hosted by commons.
> 
> In the specific case of a "Beans to Beans" project, I would be in favour
> of hosting it at sourceforge initially. Maybe "commons-dev" could then
> be subscribed to the sourceforge project dev list, so that commons
> developers are kept aware of the project?

If this project is proposed by (or will be participated in by)
existing Jakarta committers, it makes perfect sense to do it in the
sandbox.  To me, whether or not it's a refactoring sort of issue is
not the relevant decision factor.

> 
> Regards,
> 
> Simon
> 

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message