commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ronan KERDUDOU - VirageGroup" ...@viragegroup.com>
Subject RE: [VFS] Maven groupId problem?
Date Mon, 08 Nov 2010 13:57:50 GMT
Hi,

I'm not sure to understand all the problem because i don't use maven at all,
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


Mime
View raw message