commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VFS] Maven groupId problem?
Date Mon, 08 Nov 2010 16:23:21 GMT
On 8 November 2010 13:57, Ronan KERDUDOU - VirageGroup
<rk@viragegroup.com> wrote:
> Hi,
>
> I'm not sure to understand all the problem because i don't use maven at all,

The problem is not only with Maven, although that does add other complications.

Suppose you have a project with two dependencies (A, B) on VFS 1.0.

A is updated to use some new feature in VFS 2.0 - B is not.

If VFS 2.0 is upwards compatible with 1.0 - no problem, both can use 2.0.

However, if VFS 2.0 is not compatible with 1.0 - suppose class C is
incompatible and is used by both A & B.
Then it is not possible to satisfy both requirements using a single classpath.
If you add both jars to the classpath, Java can only resolve class C
from one of them, so either A or B will fail.

AIUI, this is one of the motivations for OSGI.

> but is it possible to solve your problems by doing 2 releases with a fork :
> - VFS V2.0 with java 4 and compatible whith 1.1 (same package)
> - VFS2 V1.0 (or V.2.1) with java 5 and no backward compatibility and package
> change
>
> I personally have no problem to refactor my code when moving to VFS2.
>
> Regards,
>
> KERDUDOU Ronan
> VIRAGE Group (France)
> R&D : +33 (0)2 53 55 10 22
> rk@viragegroup.com
> www.viragegroup.com
>
> -----Message d'origine-----
> De : sebb [mailto:sebbaz@gmail.com]
> Envoyé : lundi 8 novembre 2010 04:24
> À : Commons Developers List
> Objet : Re: [VFS] Maven groupId problem?
>
> On 8 November 2010 03:08, Henning Schmiedehausen
> <henning@schmiedehausen.org> wrote:
>> I don't get it. Sorry. :-)
>>
>> So maven1 kind of added ad-hoc groups. They chose to use the same as
>> the artifactId as the groupId when they constituted that back in the
>> maven1 days. That turned out to be suboptimal. But some artifacts that
>> were in the maven1 tree (most of commons) ended up in the commons-*
>> locations.
>>
>> Pretty much everyone agrees that this was a mistake and these
>> artifacts should have been put into org.apache.commons. However, they
>> were not. Why should be stay locked into these mistakes forever?
>>
>> Maven offers a relocation mechanism. So we use it and put the new
>> releases into the more sane location which is
>> org.apache.commons:commons-vfs. Life goes on afterwards. Relocation
>> helps people to transition.
>
> But as far as I can ascertain, relocation does not solve all the
> problems of changes of group/artifact ids.
> This is because relocation is added to the old location - which may
> not always be examined.
>
> Anyway, relocation should only be used for compatible binaries.
> In this case we really don't want Maven to consider 1.0 and 2.0 as
> being different versions of the same code
>
>> I love backwards compatibility as the next guy, but we do have to move
>> on at some point. JDK 1.3 and Maven 1 are gone for five+ years now.
>> Everyone who is still using them will not upgrade anyway. Not
>> leveraging what exists in 2010 seems to wrong to me. Let's acknowledge
>> mistakes of the past and move on.
>>
>> +1 to org.apache.commons:* for all new releases. +1 to "JDK5+ (even
>> though I would prefer JDK6+) for all new releases.
>>
>> -h
>>
>> On Sun, Nov 7, 2010 at 18:48, James Carman <james@carmanconsulting.com>
> wrote:
>>> On Sun, Nov 7, 2010 at 9:43 PM, Henning Schmiedehausen
>>> <henning@schmiedehausen.org> wrote:
>>>> This is an old, buggy location and it should be cleaned up over time.
>>>> Being locked into the mistakes of the past because some tool can not
>>>> understand it, doesn't seem to be reasonable to me.
>>>>
>>>
>>> The cat's sort of out of the bag now.  It pisses people (well at least
>>> it does me) off when you start moving stuff around on them.  All of a
>>> sudden, you start seeing "blah blah moved to blah blah" in your build
>>> output.  VFS apparently wasn't a Maven 2 project at the time it was
>>> released.  The source distribution doesn't contain a pom.xml file.
>>> I'm more worried about how the tag is out of sync with the "official"
>>> released source.  That's not good.
>>>
>>> ---------------------------------------------------------------------
>>> 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