commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: Blogging on Commons
Date Sun, 09 Nov 2008 16:06:53 GMT
Martin Cooper a écrit :
> Interesting post. Allow me to do some thinking out loud of my own. ;-)
> IMHO, in its earlier days, Commons worked well in that quite a few projects
> did "donate" parts of their code bases to Commons, thus seeding it and
> enhancing the commonality between those projects and promoting sharing
> beyond the ASF as well. In fact, I believe that it is actually Commons'
> success that has led to some of the problems that we see today, and some of
> the problems you blogged about.
> You see, we actually did two things with Commons, one of which we explicitly
> set out to do, and the other that I don't think we really thought about too
> much, at least at that time. The former is what you describe in your blog
> post - "a place for Jakarta [and later, other] projects to come together".
> Great idea, great initial execution, and I think many projects, Jakarta and
> otherwise, have benefited from that.
> The second thing we did was to expose these common pieces of code as ASF
> release artifacts, and to promote them as reusable components outside of the
> ASF. This was a fairly natural thing to do. After all, if the code is
> reusable across ASF projects, then it's probably reusable across non-ASF
> projects as well. However, I think it's the extent to which we have gone
> down this path that has led to many of the problems.
> For example, one of the reasons people don't want to bring things to Commons
> any more is because they have to buy in to the entire Commons enchilada.
> Consistent build systems, consistent web sites, consistent release criteria,
> and so on. This consistency is crucial when Commons is being promoted to the
> "outside world", because it allows consumers to understand what they will
> see / get from any given component. I believe it's a big part of what has
> made Commons a "brand" in and of itself, and for Commons as an
> externally-facing project, it's definitely a Good Thing (tm).
> However, this is a pain in the neck for the Commons developers, and it's a
> significant hurdle for someone bringing code to Commons from some other ASF
> project. Thinking back to when Struts broke out several chunks of code
> (BeanUtils, Digester, etc.) and moved them to the nascent Commons, that was
> straightforward because each component pretty much did its own thing back
> then. Would we have done the same thing if we'd had to go through today's
> shenanigans? I don't know, but it wouldn't have been the slam dunk that it
> was.
> What's the answer? I don't know. It would be kinda antisocial to "take
> Commons private" and make it "internal use only", although that might be the
> easiest way to relax the rules and make it easier for projects to "donate"
> parts of their code base. With such a model, we might even eliminate
> releases altogether and leave the onus on the consuming projects to
> determine the quality of whatever tag / revision they consume. There would
> be pressure, in some form, to release some of the pieces, and the question
> then becomes one of who would be willing to go through the extra steps to
> create a release out of an internal shared library, especially if that was
> not necessary for internal consumption.

I would strongly protest against such a move. Commons are used outside
of the ASF and are successful there. I even think [math] is used almost
only outside of ASF and not internally ... Commons appear also as low
level libraries for general use and this should not be stopped.

I have seen many projects that depend on a huge number of libraries. For
such projects, a reliable set of reusable components with consistent
look and feel is a sure gain.

Low level components are important and from my experience often need
specific development rules, very strict ones. The reason for that is
that you can never make any assumptions on how a low level component
will be called/integrated/reused from a random high level complete

I see the views expressed in both the original post and the previous
message as if high level applications were the only important thing and
low level components were second class "toys" to share but not to care
too much about. Is this really what you meant or did I misunderstood
your point ?


> No answers here, I'm afraid. Just some additional thoughts to add to the
> mix.
> --
> Martin Cooper
> On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <> wrote:
>> Apologies for writing this as a blog rather than an email - it felt
>> more natural and will pull in other opinions:
>> Hen
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message