maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: Painless way to update a frameworks group id?
Date Fri, 13 Dec 2013 21:12:49 GMT
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
View raw message