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 <seb...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
