Github user barthel commented on the pull request:
https://github.com/apache/maven/pull/57#issuecomment-144993151
I closed this pull request and I come back soon with a less invasive filter
solution.
---
If your project is set up for it, you can reply to this email and have your
repl
Github user barthel closed the pull request at:
https://github.com/apache/maven/pull/57
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabl
Github user barthel commented on the pull request:
https://github.com/apache/maven/pull/57#issuecomment-120431206
My preferred strategy is to resolve only released versions within a version
range (```"onlyReleases"```). If a developer needs a SNAPSHOT version, it is
possible to insert
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/57#issuecomment-120428315
And so what strategy are you going to implement? I realized you've made it
a strategy but that doesn't negate potential for problematic issues. I'm just
trying to determin
Github user barthel commented on the pull request:
https://github.com/apache/maven/pull/57#issuecomment-120420443
The `org.eclipse.aether.resolution.VersionRangeRequest` contains the
artifact .
If you implement an odd/even version range resolver strategy only for your
artifac
Github user ifedorenko commented on the pull request:
https://github.com/apache/maven/pull/57#issuecomment-120415902
What will happen when projects using new/custom version range resolution
strategy are deployed to shared repository like Central? Won't this break
consumers of project
GitHub user barthel opened a pull request:
https://github.com/apache/maven/pull/57
MNG-3092: Add strategy based version range resolver.
The discussion on issue
[MNG-3092](https://issues.apache.org/jira/browse/MNG-3092) shows the seriously
needs of different kinds of version range r
