commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning Schmiedehausen <henn...@schmiedehausen.org>
Subject Re: [VFS] Maven groupId problem?
Date Tue, 09 Nov 2010 17:43:43 GMT
Remember, that I said "repackage to e.g. org.apache.commons.vfs2.*"
for that case and some people were opposed to that? This is why.

been there, done that, got the T-Shirt.

-h



On Mon, Nov 8, 2010 at 08:23, sebb <sebbaz@gmail.com> wrote:
> 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
>
>

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


Mime
View raw message