incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julius Davies" <>
Subject Re: maven repository
Date Fri, 30 May 2008 21:42:48 GMT
A general package renaming is going to be the least of your worries if
you're depending on lots of young immature jar files (and
automatically downloading newer versions)!  Many popular jars have
broken binary reverse-compatibility at some point (httpclient,
jfreechart, junit to name three).

To reply to Alan Cabrera, I don't think it's crazy.  I think it's more
crazy to depend on incubator jars and *not* expect some turbulence of
this kind!  I think the package renaming idea is pretty slick, and
appears to accomplish both of the goals James Carman identified, while
tolerating side-by-side presence of a pre-graduated and post-graduated
incubator jars in the classpath.

If you really don't want binary breakage, don't upgrade your jar.

On Fri, May 30, 2008 at 9:16 AM, James Carman
<> wrote:
> So, let's define the goals here:
> 1.  The ASF would like folks who want to use incubating projects to do
> so knowingly somehow.  This is somewhat of a CYA tactic so that people
> are acknowledging "yes, I understand this is not an 'official' ASF
> project, but I'd like to use it anyway."
> 2.  Incubating projects would like to be able to get releases in front
> of people so that they can build their community.



On Fri, May 30, 2008 at 2:23 PM, James Carman
<> wrote:
> On Fri, May 30, 2008 at 5:17 PM, Janne Jalkanen
> <> wrote:
>>> As an end user, I would _hate_ to have to change all of my code to
>>> reference a totally new package structure after the podling graduates.
>>>  That's a major pain...
>> With JSPWiki we have plenty of plugins and other extensions donated by
>> people over the years.  Every binary break means that we obsolete most of
>> this stuff (unless we can take the responsibility of recompiling
>> everything).  Every binary break means that we will have to answer questions
>> from people running obsolete software because they can't afford the cost of
>> the upgrade because they have money invested in the customizations.
>> So it's not only the pain of upgrading the package definitions; changing
>> packages issues a damaging blow to the ecosystem nurtured in the incubator.
>>  Sometimes the impact can be minimal; sometimes it could be rather bad.


Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)

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

View raw message