Just to be clear, you're trying to maintain the dynamic constraint and NOT replace them with the resolved version? I point this out since it's conventional to publish a resolved POM and not the range query. I do see the use-case for publishing with a range, but in general it's not what people what.
On Sun, Jun 29, 2014 at 6:37 PM, Adam Murdoch <adam.murd...@gradleware.com> wrote: > > On 30 Jun 2014, at 7:18 am, WonderCsabo <kozakcs...@gmail.com> wrote: > > I think we should specify the feature first. This > <http://ant.apache.org/ivy/history/2.1.0/ivyfile/dependency.html> is the > syntax for Ivy dependencies, and here > < > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges> > > is for Maven. > > - Dynamic versions are not know to Maven at all. How we could translate > them? Maybe go to maven central and find out the latest version? > > > Assuming we’re talking about ‘latest.<status>’ selectors, I can see a few > options: > > 1. Fail the conversion for anything that cannot be translated. > 2. Just copy across anything that cannot be translated. > 3. Replace with the version that currently matches the selector. This is > lossy. > 4. As for #3 but also retain the selector somewhere else in the pom, > similar to rev and revConstraint in Ivy. > 5. As for #3 but also generate some additional meta-data file that Gradle > would use. > > The ‘real’ solution here is #5, but for now I would go with #2, as this is > no worse than where we are now. > > We might also combine #1 or #2 with better options for tweaking the > outgoing dependencies before the pom.xml or ivy.xml is generated. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > CTO Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > > >
