Just a guess: * Deploy a new relocation pom at the old coordinates with a bigger version. * Include this new relocation version.
Regards Mirko -- Sent from my mobile On Dec 12, 2013 1:26 PM, "Anders Hammar" <and...@hammar.net> wrote: > > Think some sort of "artifact-transformer" mechanism in Maven would be > >> really cool ("Map the following groupId to otherGroupId"). > > > > > > There is some discussion around this feature for a future POM model. Any > > year now. :-) > > > > Oh, I should prabably stress that this "discussion" is no promise for this > feature. It might require a change to the Maven repository structure. > > /Anders > > > > > > /Anders > > > > > > > >> But I guess something like that would fit into the same drawer as the > >> which to hace a "configuration-check" mechanism that allows a plugin to > >> validate the configuration used (Would really like to implement some > >> validator and "best-practice" validator component guiding users on how > to > >> use the plugin) > >> > >> Chris > >> > >> > >> ________________________________________ > >> Von: anders.g.ham...@gmail.com <anders.g.ham...@gmail.com> im Auftrag > >> von Anders Hammar <and...@hammar.net> > >> Gesendet: Donnerstag, 12. Dezember 2013 11:37 > >> An: Maven Users List > >> Betreff: Re: Painless way to update a frameworks group id? > >> > >> I don't think that will work. The "bad" deps are still used in compile > >> time > >> and only not used in runtime. > >> > >> The correct solution (until there are new releases that don't pull in > the > >> "bad" transitive deps) is to excluded them. And that probably can't be > >> automated in any other way than providing means to detect them (the > >> enforcer rule). > >> > >> What you could do is try this and release a beta or something and see > what > >> sort of problems people run into. Changing coordinates is always a > >> problem. > >> > >> My two cents, > >> /Anders > >> > >> > >> On Thu, Dec 12, 2013 at 11:24 AM, Christofer Dutz < > >> christofer.d...@c-ware.de > >> > wrote: > >> > >> > What do you think about this Option? > >> > > >> > I created a tool that mavenizes a non-maven Flex SDK and genereates > all > >> > sorts of maven artifacts ... one artifact that is generated is a > Special > >> > pom that contains only a dependency Management section that can be > used > >> to > >> > automatically configure the Versions of dependencies in the Flex SDK > >> ... I > >> > could automatically generate dependency manangement entries for the > old > >> > Group id that set the dependencies to "provided". So as soon as > someone > >> > imports that pom containing the dependencyManagement entries for the > >> good > >> > artifacts, the "exclude" entries are automatically in place. > >> > > >> > Chris > >> > > >> > > >> > ________________________________________ > >> > Von: anders.g.ham...@gmail.com <anders.g.ham...@gmail.com> im Auftrag > >> von > >> > Anders Hammar <and...@hammar.net> > >> > Gesendet: Donnerstag, 12. Dezember 2013 11:07 > >> > An: Maven Users List > >> > Betreff: Re: Painless way to update a frameworks group id? > >> > > >> > AFAIK there is not painless way to solve this. > >> > > >> > What you could add to the docs is instructions on how to use an > enforcer > >> > rule to ensure that no "bad" libs are pulled in by accident (if the > miss > >> > some exclusion). Use the banned deps [1] rule. > >> > > >> > /Anders > >> > > >> > [1] > >> > > http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html > >> > > >> > > >> > On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz > >> > <christofer.d...@c-ware.de>wrote: > >> > > >> > > Hi, > >> > > > >> > > > >> > > > >> > > I am the current maintainer of the Flexmojos Maven Plugin and > >> contributor > >> > > to the Apache Flex Project. > >> > > > >> > > Currently I am working on a new Version of Flexmojos which is able > to > >> > work > >> > > with Flex SDKs that have a groupId of org.apache.flex instead of the > >> old > >> > > com.adobe.flex. While building applications with the new groupId was > >> no > >> > big > >> > > Problem, we are now facing a Problem, that I don't quite know how to > >> > > elegantly solve it. > >> > > > >> > > > >> > > > >> > > Assuming I am building a Project and I switched the groupId of the > >> Flex > >> > > Framework to "org.apache.flex". As Long as I am building all > >> artifacts in > >> > > the Project this is fine. But as soon as I am using a Flex library > >> that > >> > was > >> > > built for com.apache.flex Maven correctly adds that artifacts > >> > dependencies > >> > > to the build. Unfortunately this way I have several artifacts in my > >> build > >> > > twice ... once with com.adobe.flex and once with org.apache.flex > >> groupId. > >> > > > >> > > > >> > > > >> > > Now I was suggesting to manually exclude Framework artifacts when > >> using > >> > an > >> > > external lib, but I would like to automate this. Therefore I > >> suggested to > >> > > add all the org.apache.flex artifacts as com.adobe.flex artifacts, > >> but to > >> > > set the scope on These to "provided". But it still sort of doesn't > >> feel > >> > > right. > >> > > > >> > > > >> > > > >> > > Any suggestions? Would be really happy to sort this out and make it > >> less > >> > > painfull for my users. > >> > > > >> > > > >> > > > >> > > Chris > >> > > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: users-h...@maven.apache.org > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > >