Re: Inflexibility of --also-make w.r.t. unusual goals

[Jesse Glick <je...@oracle.com>]

On 10/02/2010 07:27 AM, Brett Porter wrote:
>> mvn -am -pl main run
>>
>> would automatically invoke just 'install' (or 'package') on the calculated dependencies.
>
> I don't agree that "install" on one and package on the dependencies would make sense - this would put something in the repository that potentially doesn't
> have its dependencies there, making it unusable by other projects.

You would rather install the dependencies, and run the selected project without its install phase, so the local repository would not be inconsistent. Or if the run goal 
could work with reactor artifacts, just compile or package on the dependencies would suffice, i.e. without anything getting installed in local.

Let me provide a simpler example using only standard jar packaging and its default plugins. If I have a tree of modules using snapshot dependencies internally, and wish 
to run unit tests on one of them while ensuring that the test classpath includes up-to-date class files from its snapshot dependencies, what should I run?

a. 'cd root/submodule; mvn test' will run tests for just submodule, but relies on JARs in the local repository for all the snapshot dependencies, which is no good; these 
JARs might be missing, or old.

b. 'cd root; mvn test' will run the tests for submodule correctly, but also tests in every other module.

c. 'cd root; mvn test -Dtest=sub/module/pkg/**' might run the right set of tests if you happen to have things in a particular package structure, but this is not general. 
Anyway Surefire will fail the build on upstream modules because it found no tests to execute.

d. 'cd root; mvn install -DskipTests -am -pl submodule; cd submodule; mvn test' will run just tests for submodule and with correct snapshot dependencies, but will be much 
slower as it builds JARs (and use of -DskipTests may be objectionable).

e. 'cd root; mvn test-compile -am -pl submodule; cd submodule; mvn test' will not work since the second Maven command is given no reactor, so it will not look up 
dependencies in target/classes but in the local repository.

There seems to be no decent solution using current --also-make. The solutions using the styles I proposed previously would look like:

1. mvn -am -pl submodule test-compile -then -pl submodule test

2. mvn --also-make-goals -pl submodule test-compile test

3. mvn --also-make-smart -pl submodule test [where test known to presuppose test-compile in dependents; compile would suffice if there were no deps on secondary test 
artifacts]

(An IDE user might ask the IDE to just run JUnit on submodule/src/test/java/**/*.java bypassing Maven and Surefire and using some IDE-specific compilation of dependencies 
from sources, if the IDE has been configured to run tests exactly the same way as the POM specifies Surefire should run them, but it would be best if command-line Maven 
could do this to begin with.)

Does the issue make sense now, and is it worth filing a JIRA ticket for this?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Inflexibility of --also-make w.r.t. unusual goals

[Jesse Glick <je...@oracle.com>]

On 04/05/2011 12:31 AM, Brett Porter wrote:
>> 2. mvn --also-make-goals -pl submodule test-compile test
>>
>> Does the issue make sense now, and is it worth filing a JIRA ticket for this?
>
> It makes sense.

Filed then: http://jira.codehaus.org/browse/MNG-5059

Not sure how it would be implemented, however. The current list of options is not just a superficial piece of logic in org.apache.maven.cli but seems baked into how 
MavenExecutionRequest is defined.

> I'm not sure how many people would use this - it's quite some entry complexity to gain a little more runtime efficiency.

I was thinking of using a feature like this from an IDE or other scripted environment, in which case a slightly more complex command is no obstacle.

> I've always thought the solution to these type of problems was to invest more effort in incremental builds (don't run tests if no code + dependencies changed).

That would be useful too, but requires work on the part of plugins (here, Surefire).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Inflexibility of --also-make w.r.t. unusual goals

[Brett Porter <br...@apache.org>]

On 05/04/2011, at 1:16 AM, Jesse Glick wrote:

> There seems to be no decent solution using current --also-make. The solutions using the styles I proposed previously would look like:
> 
> 1. mvn -am -pl submodule test-compile -then -pl submodule test
> 
> 2. mvn --also-make-goals -pl submodule test-compile test
> 
> 3. mvn --also-make-smart -pl submodule test [where test known to presuppose test-compile in dependents; compile would suffice if there were no deps on secondary test artifacts]
> 
> (An IDE user might ask the IDE to just run JUnit on submodule/src/test/java/**/*.java bypassing Maven and Surefire and using some IDE-specific compilation of dependencies from sources, if the IDE has been configured to run tests exactly the same way as the POM specifies Surefire should run them, but it would be best if command-line Maven could do this to begin with.)
> 
> Does the issue make sense now, and is it worth filing a JIRA ticket for this?

It makes sense. Of the solutions, 2 seems clearest, though the test-compile should sit with the --also-make-goals parameter. However, I'm not sure how many people would use this - it's quite some entry complexity to gain a little more runtime efficiency.

I've always thought the solution to these type of problems was to invest more effort in incremental builds (don't run tests if no code + dependencies changed).

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org