commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [DISCUSS] Mission Statement for Commons...
Date Sun, 06 Oct 2013 20:11:39 GMT
Hi Christian,

Am 06.10.2013 21:44, schrieb Christian Grobmeier:
> James,
> thank you.
> I believe Commons is in a bad shape.
> Look at Commons Collections. Before 4 years somebody
> said Guava is more modern, he his answer seems to be widely accepted.
> This guy said we have no generics. What did we do in the past 4 years?
> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
> we haven't managed
> to officially release this? The last release is from 2008.
> I did consider to put my JSON component to Commons. But I didn't.
> Reason: I really need the component
> and I calculated how long it would take to release it here. I thought,
> it's not helping me
> to develop it here. I simply don't have the time.
> I thought a long while about it.
> We had discussions like: do we really need Generics? It works without!
> Do we really drop an outdated JDK? We might have users
> who run JDK 1.3! And so on. Finally this led us to the situation where
> almost all of our users seem to have JDK 1.3 and
> are not interested in generics - in 2013. The users who want modern
> features go to Guava. We maintain legacy code. And seriously, a lot of
> code works without generics. This is no reason to not include them.
> We discuss magic strings in the sandbox. Why? We don't need to discuss
> that. Before we release we can simply check Sonar. Safe the time to
> discuss. Fix it or leave it to Sonar to report it.
> We seem to think perfect documentation is more valuable then quick
> releases. Is it?
> We seem to be proud of our build. I am not. It's complex. It's no fun.
> Releases should be do-able in a short time, maybe
> even automated.
> It is so sad that lot of good features like Collections with Generics
> were blocked such a long time or drowning in discussions.
> I agree we should support old users. But if we don't have the manpower,
> we can't support them. They need to accept we are moving on. We are
> blocked with our backwards compatible ideas and innovation is far away.
> When I spoke to young developers about Commons they asked me if it still
> exists. Nobody of them is interested in our community.
> For the mission statement I would wish to see things like that:
> Commons Components…
> …are released quickly and often
> …do use modern JDKs and support old JDKs only as long as they are
> supported by Oracle
> …we make use of modern Java features when they are available
> …can be easily released
> …can be released without having 100% perfect documentation or perfect
> implementations
> …are build by Community who wants to learn, experiment and create new
> features more than by Community which wants to be backwards compatible
> for a long time
> …are allowed to release major versions with api breaks as they want
> Cheers
> Christian
I agree with many of your points. Another example is [csv] which is
about to be released for ages. Here, I think, the main impediment is
that we try to come up with a *perfect* API because due to our rules of
backwards compatibility it is so difficult to correct any mistakes later.

I still think that backwards compatibility is very important, but we
really should define a process which allows us to experiment with new APIs.

As a suggestion to improve this situation, could we agree on an alpha
release process allowing us to push releases with the aim of getting
community feedback? Where we explicitly state that incompatible changes
are possible (and likely)?

We did something similar with [collections] 4, but there were many
limitations (the release was not allowed to be uploaded to Maven central
for instance). If we did such experimental releases more often, there
would hopefully not be the fear of defining a broken API, and we would
see more releases.


> On 6 Oct 2013, at 20:30, James Carman wrote:
>> All,
>> The Apache Commons project seems to be languishing as of late and we
>> need some rejuvenation.  Perhaps we should try to define our mission
>> as a project.  What are our goals?  What do we want to accomplish?
>> Who are our users/customers?  What non-functional qualities do we want
>> our software to exhibit?  How do we want to conduct ourselves?  How
>> often do we want to do releases?  What else?
>> Sincerely,
>> James
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---
> @grobmeier
> GPG: 0xA5CC90DB
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message