commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [VFS] change of package name breaks Gump
Date Mon, 15 Nov 2010 01:34:43 GMT
On 15 November 2010 01:23, Ralph Goers <> wrote:
> On Nov 14, 2010, at 3:43 AM, sebb wrote:
>> On 14 November 2010 11:17, sebb <> wrote:
>>> The change of VFS package name has broken lots of Gump builds - which
>>> is to be expected.
>>> Looking at how this has been solved for other projects, one way to
>>> solve this is to create a branch for the VFS 1.x code and use that for
>>> the current VFS.
>>> Then we create a build for VFS 2.
>>> Gump does warn us that there are a lot of projects that depend on VFS
>>> directly or indirectly.
>>> All of these will have to be modified if they wish to use the next version.
>>> Maybe we need to revisit the API breakage?
>> I've created a tag from just before the package rename, and hopefully
>> succeeded in changing Gump to use that version of VFS.
>> This should give us a better idea of whether the API changes actually
>> affect any code that depends on VFS.
>> It may turn out that the API changes are in areas of code which are
>> not actually used externally, or maybe they are easy to fix.
> I'm not really sure how that helps. My understanding of Gump is that the intention is
to have projects find these sorts of breakage. What your change accomplishes is to allow other
projects to merrily roll along without realizing they have a looming problem.

Initially it is a temporary fix to see how whether API changes break
the other builds or not.

However, when there is a package change, Gump has to provide access to
the previous version, until such time as projects update to the new
For example as has been done with Jexl and Lang and Pool.

> I'd really like to not endlessly go on and on with doing this and that with VFS and never
getting a release out.  As requested I renamed the packages and changed the artifactId. Is
it done yet?

I'm sorry it seems to be taking so long.

However, a package name change is not something to be undertaken
lightly, as it affects all downstream users.

IMO it's important to ensure that the package change really is necessary.

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

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

View raw message