Well I guess the enforcer Thing should be a good Option.
I was already telling the People to exclude and manually include the new
artifacts. So I guess I'll still stick to that and extend my Suggestion to add
an enforcer rule to notify users of such Problems.
Also I knew that changing the groupId would not be completely painless, but I
didn't want to force People to continue to call Flex artifacts com.adobe.flex
as the guys at Apache are doing the good and hard work. It's more a Thing of
ideals than technical neccessity :-)
Think some sort of "artifact-transformer" mechanism in Maven would be really
cool ("Map the following groupId to otherGroupId"). 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
