maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: Painless way to update a frameworks group id?
Date Thu, 12 Dec 2013 10:37:10 GMT
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.dutz@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.hammar@gmail.com <anders.g.hammar@gmail.com> im Auftrag von
> Anders Hammar <anders@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.dutz@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message