Initiating commons projects (was [Betwixt] Mapping Beans to Beans)

[Simon Kitching <si...@ecnetwork.co.nz>]

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, 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.

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?

Regards,

Simon


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

Re: Initiating commons projects (was [Betwixt] Mapping Beans to Beans)

[Craig McClanahan <cr...@gmail.com>]

See intermixed.


On Mon, 04 Oct 2004 10:40:04 +1300, Simon Kitching
<si...@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

Re: Initiating commons projects (was [Betwixt] Mapping Beans to Beans)

[Brian Pugh <tr...@yahoo.com>]

As I mentioned in my original post, I could really use something like this very soon so I've been playing with some ideas over the past week.  I think it is something that would be reasonably useful for others, but it sounds like apache isn't the right place (at least to start out), so I opened a project here:
http://sourceforge.net/projects/jbeanmapper/
 
I haven't yet put anything up, but I'll try to in the next day or two.  If anyone is interested, please send comments/suggestions to the discussion forum for jbeanmapper over on sourceforge.
 
-Brian
 


Simon Kitching <si...@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, 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.

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?

Regards,

Simon


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



		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!