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" <christofer.d...@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:mfriedenha...@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" <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.htm > > l > > >> > > > >> > > > >> > 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 > > >> > > >> > > > > > >
