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:mfriedenha...@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" <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.h
> > tm
> > 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
> > >>
> > >>
> > >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to