On 8 November 2010 13:57, Ronan KERDUDOU - VirageGroup <r...@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 > r...@viragegroup.com > www.viragegroup.com > > -----Message d'origine----- > De : sebb [mailto:seb...@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 > <henn...@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 <ja...@carmanconsulting.com> > wrote: >>> On Sun, Nov 7, 2010 at 9:43 PM, Henning Schmiedehausen >>> <henn...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
