maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mirko Friedenhagen <mfriedenha...@gmail.com>
Subject Re: AW: Painless way to update a frameworks group id?
Date Sat, 14 Dec 2013 06:40:23 GMT
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.dutz@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" <anders@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 <anders.g.hammar@gmail.com> im
> > >> Auftrag von Anders Hammar <anders@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 <anders.g.hammar@gmail.com> im
> > >> > Auftrag
> > >> von
> > >> > Anders Hammar <anders@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.dutz@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
> > >>
> > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message