+1
Thinking about it - I like the idea of a (for lack of a better name)
~/.m2/resolutions.xml that provides control over the resolver.
First thoughts that come to mind:
- missing or empty file - existing 2.x behaviour, -SNAPSHOTS resolved
across the board.
- profile based (optional?)
Maybe
Hervé BOUTEMY wrote:
Expected SNAPSHOT dependencies should be in the pom IMHO, since each bits of
build info should be there so that mvn compile is sufficient.
I agree that we need to aim for a short command line but I'm not
convinced the POM can help us here. To me, it looks like a valid
Benjamin Bentmann wrote:
I have no solution right now and need to think about this some more.
The approach that I could think of to sufficiently address this issue
requires quite some rework of the settings.xml or better a different
file in order to not break side-by-side use of Maven 2.x
On Sep 15, 2010, at 8:55 AM, Benjamin Bentmann wrote:
Benjamin Bentmann wrote:
I have no solution right now and need to think about this some more.
The approach that I could think of to sufficiently address this issue
requires quite some rework of the settings.xml or better a different
Le mercredi 15 septembre 2010, Benjamin Bentmann a écrit :
Hervé BOUTEMY wrote:
Expected SNAPSHOT dependencies should be in the pom IMHO, since each bits
of build info should be there so that mvn compile is sufficient.
I agree that we need to aim for a short command line but I'm not
Le mercredi 15 septembre 2010, Benjamin Bentmann a écrit :
Benjamin Bentmann wrote:
I have no solution right now and need to think about this some more.
The approach that I could think of to sufficiently address this issue
requires quite some rework of the settings.xml or better a different
On 14 September 2010 06:22, Hervé BOUTEMY herve.bout...@free.fr wrote:
So far I doubt that we can find any magic/heuristic that works for all
use cases. Hence I suggest that we go with some explicit configuration.
In detail, I propose a CLI option like
mvn goals --snapshot-versions
Stephen Connolly wrote:
perhaps a special property in the pom.xml too, to avoid CLI-only and
improve reproducibility?
would the release plugin therefore have to remote the property during a
release and then put it back in again also properties are not known
until after the model is
Hervé BOUTEMY wrote:
What would be the use case not covered by previous common case?
Well, I assumed it would be the common case that project gid:aid would
want to consume snapshots of other projects from the gid domain. But
that doesn't have to be the case, just because project A shares
Benjamin Bentmann wrote:
For the common case where one wants to consume snapshots of related
projects, [...] I suggest to have Maven derive a default value for
the -sv option by considering the groupIds of all snapshot projects in
the reactor as inclusions.
A detail that could be further
Both options would be nice, but I think I'm leaning more in against
including sub groups in the default set.
A different group is after all, a different group ( and probably a different
group for a reason ).
Mark
--
Pull me down under...
On Tue, Sep 14, 2010 at 10:18 PM, Benjamin Bentmann
Le mardi 14 septembre 2010, Benjamin Bentmann a écrit :
Stephen Connolly wrote:
perhaps a special property in the pom.xml too, to avoid CLI-only and
improve reproducibility?
would the release plugin therefore have to remote the property during a
release and then put it back in
Brian Fox wrote:
Two options come to mind:
1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere
2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be
considered kosher for resolution
Option 1 would probably require some form of POM change as I don't think
Having read this a few times I think it sounds solid. I like the default
inclusion of snapshot groups in the build as a default, this will help
existing users move along without really seeing any changes in their
behavior.
Would it be good to also log a warning note to the console to report the
So far I doubt that we can find any magic/heuristic that works for all
use cases. Hence I suggest that we go with some explicit configuration.
In detail, I propose a CLI option like
mvn goals --snapshot-versions gid,-gid:aid,*:aid
This is meant to give a comma-separated list of
I created a Wiki page to be able to share pointers:
http://docs.codehaus.org/display/MAVENUSER/SNAPSHOT+Resolution
regards,
Hervé
Le vendredi 03 septembre 2010, Mark Derricutt a écrit :
Any pointers to where in the code base I should start looking/hacking if I
wanted to try and write such a
I'd had a similar thought initially, but I've not really looked at the
internals of maven yet to know if there is such a distinct thing, or a
pluggable resolver ( I did see that the resolution was on the VersionRange
class so I suspect maybe there isn't ).
Mark
--
Pull me down under...
On Fri,
Forking this discussion:
On Thu, Sep 2, 2010 at 9:12 PM, Mark Derricutt m...@talios.com wrote:
Personally I'd still like to see some resolution to the problems introduced
by the version range resolution change ( no more -SNAPSHOT resolution except
for on the bounds ).
On one hand I applaud
Any pointers to where in the code base I should start looking/hacking if I
wanted to try and write such a patch?
As I'm the main one arguing for this improvement, I'm willing to at least
try and solve it :)
--
Pull me down under...
On Fri, Sep 3, 2010 at 1:27 PM, Brian Fox bri...@infinity.nu
I'm concerned by this fix too.
Here are my thought for now: the fix should not have been done in VersionRange
but in a version conflict resolution phase, since a range is a mathematical
notion we can't alter.
but I didn't have time yet to transform these thoughts in code...
Regards,
Hervé
20 matches
Mail list logo
