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
> >>
> >>
> >
>
