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:[email protected]] 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" <[email protected]> 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: [email protected] <[email protected]> im > >> Auftrag von Anders Hammar <[email protected]> > >> 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 < > >> [email protected] > >> > 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: [email protected] <[email protected]> im > >> > Auftrag > >> von > >> > Anders Hammar <[email protected]> > >> > 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 > >> > <[email protected]>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: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > >> > >> ------------------------------------------------------------------- > >> -- To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > >
