On Sun, Jun 29, 2014 at 9:54 PM, Justin Ryan <quidr...@gmail.com> wrote:
> 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. > Yes, we're talking about http://issues.gradle.org/browse/GRADLE-1578: when a dependency contains a version range Gradle doesn't produce a valid POM for consumption by Maven. Replacing the 'version selector' with the actual resolved version used would be another feature, which would apply to publishing in both Ivy and Maven metadata formats. > > 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 >> >> >> >> > -- Darrell (Daz) DeBoer Principal Software Engineer, *Gradleware <http://gradleware.com>* Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
