We constantly have version selection problems where Maven's random
version selection bites us. This would almost always be solved if
Maven would select the greater of the two versions. Why doesn't Maven
do this instead of picking randomly?
To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

It doesn't pick randomly, it picks based on nearest, which is
undefined if there are two at the same level. However, this was
mucked with in 2.0.4 and seemed to get a bit worse.

I originally had it set to greater and there was much confusion
because you couldn't always see where the version was coming from
(you expected one, got another because it was "less visible"). I
think now that transitive deps are more familiar, this probably would
be received better.

The plan was always to (re-)introduce the conflict resolution
strategies to make this configurable in Maven 2.1.
- Brett

19/09/2006, at 12:58 AM, Mike Perham wrote:

We constantly have version selection problems where Maven's random
version selection bites us. This would almost always be solved if
Maven would select the greater of the two versions. Why doesn't Maven
do this instead of picking randomly?

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

That's too bad. I think deps at the same level should pick the
greater, not randomly. MNG-1577 would help a lot here.

I'm also finding that exclusions are insideous - I can't see where an
exclusion is coming from so I can't determine which module is
erroneously excluding a dep I need.

9/18/06, Brett Porter <brett (AT) apache (DOT) orgwrote:
It doesn't pick randomly, it picks based on nearest, which is
undefined if there are two at the same level. However, this was
mucked with in 2.0.4 and seemed to get a bit worse.

I originally had it set to greater and there was much confusion
because you couldn't always see where the version was coming from
(you expected one, got another because it was "less visible"). I
think now that transitive deps are more familiar, this probably would
be received better.

The plan was always to (re-)introduce the conflict resolution
strategies to make this configurable in Maven 2.1.

- Brett

19/09/2006, at 12:58 AM, Mike Perham wrote:

We constantly have version selection problems where Maven's random
version selection bites us. This would almost always be solved if
Maven would select the greater of the two versions. Why doesn't Maven
do this instead of picking randomly?

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
--

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

Mike,

I'm in the process of creating unit tests for the patch - which is a
good thing because the patch doesn't seem to be working quite the way it
needs to in all cases. Hopefully I'll have this done in the next couple
of days.

Ralph

Mike Perham wrote:
That's too bad. I think deps at the same level should pick the
greater, not randomly. MNG-1577 would help a lot here.

I'm also finding that exclusions are insideous - I can't see where an
exclusion is coming from so I can't determine which module is
erroneously excluding a dep I need.

9/18/06, Brett Porter <brett (AT) apache (DOT) orgwrote:
>It doesn't pick randomly, it picks based on nearest, which is
>undefined if there are two at the same level. However, this was
>mucked with in 2.0.4 and seemed to get a bit worse.
>>
>I originally had it set to greater and there was much confusion
>because you couldn't always see where the version was coming from
>(you expected one, got another because it was "less visible"). I
>think now that transitive deps are more familiar, this probably would
>be received better.
>>
>The plan was always to (re-)introduce the conflict resolution
>strategies to make this configurable in Maven 2.1.
>>
>- Brett
>>
>19/09/2006, at 12:58 AM, Mike Perham wrote:
>>
>We constantly have version selection problems where Maven's random
>version selection bites us. This would almost always be solved if
>Maven would select the greater of the two versions. Why doesn't Maven
>do this instead of picking randomly?
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
>>
>>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

I'm trying to run "mvn test
" from maven-project.
When I do I get No tests to run. This happens when I name any test case
in the project, not just that class. Is there something special I need
to do?

Thanks,
Ralph

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

Try this: mvn clean test -Dtest=MavenProjectTest

The test param isn't a classname with package but a pattern on files, so
should be ok too.

Emmanuel

Ralph Goers a :
I'm trying to run "mvn test
" from maven-project.
When I do I get No tests to run. This happens when I name any test case
in the project, not just that class. Is there something special I need
to do?

Thanks,
Ralph

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

Thanks, that worked. Either I'm dense or some better examples would
help. This syntax isn't intuitively obvious.

Next question. How do I do the equivalent of
-Dmaven.junit.jvmargs="" so that I can do debugging of the test?

Ralph

Emmanuel Venisse wrote:
Try this: mvn clean test -Dtest=MavenProjectTest

The test param isn't a classname with package but a pattern on files,
so should be ok too.

Emmanuel

Ralph Goers a :
>I'm trying to run "mvn test
>" from
>maven-project. When I do I get No tests to run. This happens when I
>name any test case in the project, not just that class. Is there
>something special I need to do?
>>
>Thanks,
>Ralph
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
>>
>>
>>
>>
>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

20/09/2006, at 2:56 PM, Ralph Goers wrote:

Thanks, that worked. Either I'm dense or some better examples
would help. This syntax isn't intuitively obvious.

I agree - it's not obvious. it's nifty to save typing, but I think
'.' notation should be made to work too. And the docs improved.

Next question. How do I do the equivalent of -
Dmaven.junit.jvmargs="" so that I can do debugging of the test?

That'll need a feature request - I thought we had it but it seems not
(surprising given we have env vars). There is an undocumented cheat
you can use though: -Dmaven.surefire.debug. This passes standard
debugging args to the forked VM (port 5005).

Cheers,
Brett

Ralph

Emmanuel Venisse wrote:
>Try this: mvn clean test -Dtest=MavenProjectTest
>>
>The test param isn't a classname with package but a pattern on
>files, so should be ok too.
>>
>Emmanuel
>>
>Ralph Goers a :
I'm trying to run "mvn test -
" from maven-
project. When I do I get No tests to run. This happens when I
name any test case in the project, not just that class. Is there
something special I need to do?

Thanks,
Ralph

-
To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org


>>
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
>>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

Thanks. Given that info I was able to find the patch where that was
implemented at
%3C20060501024223.98895.qmail (AT) minotaur (DOT) apache.org%3E.
That will work for me as it matches what I always do for IntelliJ.
However, it seems like this could simply be enhanced to check the value
returned from the System.getProperty and if it isn't empty to use that
instead of the hardcoded string.

Ralph

Brett Porter wrote:

20/09/2006, at 2:56 PM, Ralph Goers wrote:
>
>Thanks, that worked. Either I'm dense or some better examples would
>help. This syntax isn't intuitively obvious.
>
I agree - it's not obvious. it's nifty to save typing, but I think '.'
notation should be made to work too. And the docs improved.
>
>>
>Next question. How do I do the equivalent of
>-Dmaven.junit.jvmargs="" so that I can do debugging of the test?
>
That'll need a feature request - I thought we had it but it seems not
(surprising given we have env vars). There is an undocumented cheat
you can use though: -Dmaven.surefire.debug. This passes standard
debugging args to the forked VM (port 5005).

Cheers,
Brett
>
>>
>Ralph
>>
>Emmanuel Venisse wrote:
Try this: mvn clean test -Dtest=MavenProjectTest

The test param isn't a classname with package but a pattern on
files, so should be ok too.

Emmanuel

Ralph Goers a :
I'm trying to run "mvn test
" from
maven-project. When I do I get No tests to run. This happens when
I name any test case in the project, not just that class. Is there
something special I need to do?

Thanks,
Ralph

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
>

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

yes, also a good idea. Flagged - will JIRA unless you beat me to it :)

20/09/2006, at 3:19 PM, Ralph Goers wrote:

Thanks. Given that info I was able to find the patch where that was
implemented at
surefire-commits/200604.mbox/%
3C20060501024223.98895.qmail (AT) minotaur (DOT) apache.org%3E. That will
work for me as it matches what I always do for IntelliJ. However,
it seems like this could simply be enhanced to check the value
returned from the System.getProperty and if it isn't empty to use
that instead of the hardcoded string.

Ralph

Brett Porter wrote:
>>
>20/09/2006, at 2:56 PM, Ralph Goers wrote:
>>
Thanks, that worked. Either I'm dense or some better examples
would help. This syntax isn't intuitively obvious.
>>
>I agree - it's not obvious. it's nifty to save typing, but I think
>'.' notation should be made to work too. And the docs improved.
>>

Next question. How do I do the equivalent of -
Dmaven.junit.jvmargs="" so that I can do debugging of the test?
>>
>That'll need a feature request - I thought we had it but it seems
>not (surprising given we have env vars). There is an undocumented
>cheat you can use though: -Dmaven.surefire.debug. This passes
>standard debugging args to the forked VM (port 5005).
>>
>Cheers,
>Brett
>>

Ralph

Emmanuel Venisse wrote:
Try this: mvn clean test -Dtest=MavenProjectTest

The test param isn't a classname with package but a pattern on
files, so should be ok
too.

Emmanuel

Ralph Goers a :
I'm trying to run "mvn test -
" from maven-
project. When I do I get No tests to run. This happens when I
name any test case in the project, not just that class. Is
there something special I need to do?

Thanks,
Ralph

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

--
To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

-
To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
>>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org