commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [Commons Wiki] Update of "MavenGroupIDChange" by sebbapache
Date Sat, 13 Nov 2010 15:32:43 GMT
Sometimes you *can't* ensure that!  We've already discussed the whole
idea of "jar hell" (two different libraries on the classpath require
two different, binary incompatible versions of the same library) and
this isn't something you can resolve with the classes in the same
package.

On Sat, Nov 13, 2010 at 10:30 AM, Ralph Goers
<ralph.goers@dslextreme.com> wrote:
> Not really. If you can insure that only a single version of the artifact is on the classpath
then there is no need for package renaming.  The concept here is very similar to how packages
in RedHat or Debian versions of Linux work.  I will admit that without a tool like Maven
it would be much more difficult to manage these, but that is the value of using a smart tool
to do the build.
>
> Ralph
>
> On Nov 13, 2010, at 7:13 AM, James Carman wrote:
>
>> This stuff isn't just all about Maven.  The artifactId change is, but
>> the package name change is useful (and even required) in non-maven
>> environments, too.
>>
>> On Sat, Nov 13, 2010 at 10:09 AM, Ralph Goers
>> <ralph.goers@dslextreme.com> wrote:
>>> This is a great post.  Personally, I think the need to do this is completely
caused by Maven and I've been discussing this with them for years.  I will be writing up
a proposal on the Maven wiki which would eliminate the need to keep renaming packages and
artifacts.  Instead, artifacts would contain additional metadata they could use to describe
things like the version(s) of the API that they support, configuration versions, and other
attributes that might affect the user of the artifact. Then users of the artifact, in addition
to specifying the groupId and artifactId would specify the attributes and their versions that
they require. Maven could then use this information to insure that only a single version of
the artifact is present and that it meets the requirements of all the projects that list it
as a dependency.  If multiple projects specify the artifact with different metadata that
can't be resolved by any available version of the artifact then the build would fail.
>>>
>>> Ralph
>>>
>>> On Nov 13, 2010, at 6:32 AM, Apache Wiki wrote:
>>>
>>>> Dear Wiki user,
>>>>
>>>> You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
>>>>
>>>> The "MavenGroupIDChange" page has been changed by sebbapache.
>>>> http://wiki.apache.org/commons/MavenGroupIDChange?action=diff&rev1=3&rev2=4
>>>>
>>>> --------------------------------------------------
>>>>
>>>>  === Change of package name ===
>>>>  If the change from commons-foo:commons-foo to org.apache.commons:commons-foo
is accompanied by a change to the Java package name, e.g. to org.apache.commons.foo3, then
there will be no classpath issue, as both Maven and Java treat the artifacts as different.
>>>>
>>>> - However, the change of Java package name is neither binary nor source-compatible,
and can require a lot of work for users of Commons Foo. This may be acceptable if the new
version has major changes to the API, but not otherwise - why should users (who may not even
use Maven) be forced to change their code just to upgrade to the latest version (James Carman:
the user will thank us when they try to use a library that requires the older version, we
shouldn't discount this too mcuh.  This approach solves the "jar hell" issue)?
>>>> + There are two possible scenarios here
>>>> + * The new version of the code is binary incompatible with the old version.
>>>> + * The new version is binary compatible with the old version.
>>>>
>>>> + However, the change of Java package name is neither binary nor source-compatible,
and can require a lot of work for users of Commons Foo. This may be acceptable if the new
version has incompatible changes to the API, but not otherwise - why should users (who may
not even use Maven) be forced to change their code just to upgrade to the latest version (James
Carman: the user will thank us when they try to use a library that requires the older version,
we shouldn't discount this too much.  This approach solves the "jar hell" issue) (Sebb: there
is no "jar hell" if the versions are binary compatible)?
>>>> +
>>>> + For binary-compatible releases, the Java package name should NOT be changed,
as that causes unnecessary work for all users.
>>>> + It follows that the Maven groupID should not be changed either, unless
relocation POMs are guaranteed to work.
>>>> +
>>>> + As a concrete example, Logging uses the groupId commons-logging. Changing
the package name merely to allow the groupId to be changed would cause an awful lot of work,
for almost no benefit.
>>>> +
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message