You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Christofer Dutz <ch...@c-ware.de> on 2013/12/11 09:01:11 UTC
Painless way to update a frameworks group id?
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
AW: AW: Painless way to update a frameworks group id?
Posted by Christofer Dutz <ch...@c-ware.de>.
Ah ... I think I know where you are going.
So my Mavenizer would generate the correct artifacts and additionally would generate relocation poms for the old group id ... I think I'll have to look at that option.
Thanks for that.
Chris
-----Ursprüngliche Nachricht-----
Von: Mirko Friedenhagen [mailto:mfriedenhagen@gmail.com]
Gesendet: Samstag, 14. Dezember 2013 07:40
An: Maven Users List
Betreff: Re: AW: Painless way to update a frameworks group id?
Christofer,
this depends on your definition of "we" :-). In a company context with an internal repository manager you might deploy a "vendor" release into your patched thirdparty repository. Or tell your users to manually install the patched version. I did similar stuff for this strange m2e-maven-plugin-configuration-holder ( http://stackoverflow.com/questions/7905501/get-rid-of-pom-not-found-warning-for-org-eclipse-m2elifecycle-mapping
)
Regards Mirko
--
Sent from my mobile
On Dec 13, 2013 10:13 PM, "Christofer Dutz" <ch...@c-ware.de>
wrote:
> Good Idea ...
>
> Unfortunately as we are not allowed to publish the Adobe artifacts
> (Flash Player / Air libs) we decided not to publish the Flex artifacts at all.
> Then a redirect seems rather problematic. Currently each user has to
> locally deploy the Flex SDK using a special tool in order to be on the
> safe side :-(
>
> Chris
>
> -----Ursprüngliche Nachricht-----
> Von: Mirko Friedenhagen [mailto:mfriedenhagen@gmail.com]
> Gesendet: Freitag, 13. Dezember 2013 21:26
> An: Maven Users List
> Betreff: Re: Painless way to update a frameworks group id?
>
> 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" <an...@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.hammar@gmail.com <an...@gmail.com> im
> > >> Auftrag von Anders Hammar <an...@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.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 <an...@gmail.com> im
> > >> > Auftrag
> > >> von
> > >> > Anders Hammar <an...@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.h
> > tm
> > l
> > >> >
> > >> >
> > >> > On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz
> > >> > <ch...@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
> > >> >
> > >> >
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > >>
> > >>
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: AW: Painless way to update a frameworks group id?
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Christofer,
this depends on your definition of "we" :-). In a company context with an
internal repository manager you might deploy a "vendor" release into your
patched thirdparty repository. Or tell your users to manually install the
patched version. I did similar stuff for this strange
m2e-maven-plugin-configuration-holder (
http://stackoverflow.com/questions/7905501/get-rid-of-pom-not-found-warning-for-org-eclipse-m2elifecycle-mapping
)
Regards Mirko
--
Sent from my mobile
On Dec 13, 2013 10:13 PM, "Christofer Dutz" <ch...@c-ware.de>
wrote:
> Good Idea ...
>
> Unfortunately as we are not allowed to publish the Adobe artifacts (Flash
> Player / Air libs) we decided not to publish the Flex artifacts at all.
> Then a redirect seems rather problematic. Currently each user has to
> locally deploy the Flex SDK using a special tool in order to be on the safe
> side :-(
>
> Chris
>
> -----Ursprüngliche Nachricht-----
> Von: Mirko Friedenhagen [mailto:mfriedenhagen@gmail.com]
> Gesendet: Freitag, 13. Dezember 2013 21:26
> An: Maven Users List
> Betreff: Re: Painless way to update a frameworks group id?
>
> 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" <an...@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.hammar@gmail.com <an...@gmail.com> im
> > >> Auftrag von Anders Hammar <an...@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.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 <an...@gmail.com> im
> > >> > Auftrag
> > >> von
> > >> > Anders Hammar <an...@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.htm
> > l
> > >> >
> > >> >
> > >> > On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz
> > >> > <ch...@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
> > >> >
> > >> >
> > >>
> > >> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > >>
> > >>
> > >
> >
>
AW: Painless way to update a frameworks group id?
Posted by Christofer Dutz <ch...@c-ware.de>.
Good Idea ...
Unfortunately as we are not allowed to publish the Adobe artifacts (Flash Player / Air libs) we decided not to publish the Flex artifacts at all. Then a redirect seems rather problematic. Currently each user has to locally deploy the Flex SDK using a special tool in order to be on the safe side :-(
Chris
-----Ursprüngliche Nachricht-----
Von: Mirko Friedenhagen [mailto:mfriedenhagen@gmail.com]
Gesendet: Freitag, 13. Dezember 2013 21:26
An: Maven Users List
Betreff: Re: Painless way to update a frameworks group id?
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" <an...@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.hammar@gmail.com <an...@gmail.com> im
> >> Auftrag von Anders Hammar <an...@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.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 <an...@gmail.com> im
> >> > Auftrag
> >> von
> >> > Anders Hammar <an...@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.htm
> l
> >> >
> >> >
> >> > On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz
> >> > <ch...@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
> >> >
> >> >
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
Re: Painless way to update a frameworks group id?
Posted by Mirko Friedenhagen <mf...@gmail.com>.
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" <an...@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.hammar@gmail.com <an...@gmail.com> im Auftrag
> >> von Anders Hammar <an...@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.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 <an...@gmail.com> im Auftrag
> >> von
> >> > Anders Hammar <an...@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
> >> > <ch...@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
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
Re: Painless way to update a frameworks group id?
Posted by Anders Hammar <an...@hammar.net>.
> 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.hammar@gmail.com <an...@gmail.com> im Auftrag
>> von Anders Hammar <an...@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.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 <an...@gmail.com> im Auftrag
>> von
>> > Anders Hammar <an...@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
>> > <ch...@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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: Painless way to update a frameworks group id?
Posted by Anders Hammar <an...@hammar.net>.
>
> 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. :-)
/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.hammar@gmail.com <an...@gmail.com> im Auftrag von
> Anders Hammar <an...@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.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 <an...@gmail.com> im Auftrag
> von
> > Anders Hammar <an...@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
> > <ch...@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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
AW: Painless way to update a frameworks group id?
Posted by Christofer Dutz <ch...@c-ware.de>.
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.hammar@gmail.com <an...@gmail.com> im Auftrag von Anders Hammar <an...@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.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 <an...@gmail.com> im Auftrag von
> Anders Hammar <an...@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
> <ch...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Painless way to update a frameworks group id?
Posted by Anders Hammar <an...@hammar.net>.
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 <an...@gmail.com> im Auftrag von
> Anders Hammar <an...@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
> <ch...@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
>
>
AW: Painless way to update a frameworks group id?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <an...@gmail.com> im Auftrag von Anders Hammar <an...@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
<ch...@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
Re: Painless way to update a frameworks group id?
Posted by Anders Hammar <an...@hammar.net>.
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
<ch...@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
>