Grails Maven Plugin

Grails Maven plugin does not do anything with test scoped dependencies.

Details

  • Type: Sub-task Sub-task
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0.1
  • Component/s: None
  • Labels:
    None

Issue Links

Activity

Hide
Jon Barksdale added a comment -

The maven plugin seems to completely ignore test scoped dependencies when running the grails tests. It should add them to the classpath when running tests, if no other time.

Show
Jon Barksdale added a comment - The maven plugin seems to completely ignore test scoped dependencies when running the grails tests. It should add them to the classpath when running tests, if no other time.
Hide
Jonathan Pearlin added a comment -

This issue is because the main mojo (AbstractGrailsMojo) only adds runtime dependencies (and system dependencies if specified) to the classpath when executing a target. Since test artifacts are not runtime artifacts, anything scoped as test in the POM file does not get added. I have attached a patch to this issue with a fix to allow test-scoped libraries to be added to the classpath when a "test" target is executed. I have also verified that these dependencies do not end up in the packaged WAR file when using Maven.

Show
Jonathan Pearlin added a comment - This issue is because the main mojo (AbstractGrailsMojo) only adds runtime dependencies (and system dependencies if specified) to the classpath when executing a target. Since test artifacts are not runtime artifacts, anything scoped as test in the POM file does not get added. I have attached a patch to this issue with a fix to allow test-scoped libraries to be added to the classpath when a "test" target is executed. I have also verified that these dependencies do not end up in the packaged WAR file when using Maven.
Hide
Jonathan Pearlin added a comment -

Proposed patch fix for test-scoped dependencies.

Show
Jonathan Pearlin added a comment - Proposed patch fix for test-scoped dependencies.
Hide
Jonathan Pearlin added a comment -

Ignore the attached patch. I performed some further testing and found that the current Grails Maven plugin does correctly honor the test scoped dependencies for unit tests (I know that this was broken in the 1.2.x version of the plugin). I created a simple Grails application that I built with Maven. The project had a unit test class generated by Grails when I created a domain class. In the test, I used a couple of methods from both JUnit 4 and Commons Lang 2.5. These dependencies were marked as "test" scope in my POM file. The project built correctly using Maven, passed all unit tests and did NOT include the test scoped dependencies in the WAR file as expected. Therefore, my conclusion is that the previous patch can be disregarded and this issue should be marked as fixed.

Show
Jonathan Pearlin added a comment - Ignore the attached patch. I performed some further testing and found that the current Grails Maven plugin does correctly honor the test scoped dependencies for unit tests (I know that this was broken in the 1.2.x version of the plugin). I created a simple Grails application that I built with Maven. The project had a unit test class generated by Grails when I created a domain class. In the test, I used a couple of methods from both JUnit 4 and Commons Lang 2.5. These dependencies were marked as "test" scope in my POM file. The project built correctly using Maven, passed all unit tests and did NOT include the test scoped dependencies in the WAR file as expected. Therefore, my conclusion is that the previous patch can be disregarded and this issue should be marked as fixed.
Hide
Richard Vowles added a comment -

No it can't. The code most definitely does not support test dependencies.

Show
Richard Vowles added a comment - No it can't. The code most definitely does not support test dependencies.
Hide
Richard Vowles added a comment -

I have fixed this here. http://rvowl.es/qItG2f

Show
Richard Vowles added a comment - I have fixed this here. http://rvowl.es/qItG2f
Hide
Peter Ledbrook added a comment -

Is there an example project that demonstrates this issue? And if someone provides one, can it readily be added to the Maven test suite?

Show
Peter Ledbrook added a comment - Is there an example project that demonstrates this issue? And if someone provides one, can it readily be added to the Maven test suite?
Hide
Jonathan Pearlin added a comment -

I am not sure that there is an issue (or I am not understanding the stated problem). I retested this (again) with the 1.3.7 plugin using the following scenario:

1) Created a POM file for my project and included org.easymock:easymock:3.0 as a test scoped dependency (something not already included in the Grails dependencies).
2) Created a unit test in the "test\unit" folder that extends GrailsUnitTestCase.
3) Created a test method in said unit test class and had it instantiate the org.easymock.Capture class, so that it has a compile time dependency on the EasyMock library that is test scoped (and obviously imported it in the .groovy file).
4) Build the project using: mvn clean package
5) Looked at the output to verify that the test passed and that the build (compilation) was successful.

Therefore, this does NOT appear to be an issue with Grails unit tests executed via Maven, if you let it get picked up via the default test phase in the life cycle. I did not try using the Grails Maven TestApp goal(mvn grails:test-app) – though I doubt it will behave any differently. I suppose it is possible that the reporter meant integration tests (I do know that there are other issues relating to Grails trying to instantiate various Spring contexts multiple times when running the integration tests from Maven – this only seems to happen from Maven and not from the Grails command line). I can post the sample project, POM file, and test case if necessary to help resolve this issue.

Show
Jonathan Pearlin added a comment - I am not sure that there is an issue (or I am not understanding the stated problem). I retested this (again) with the 1.3.7 plugin using the following scenario: 1) Created a POM file for my project and included org.easymock:easymock:3.0 as a test scoped dependency (something not already included in the Grails dependencies). 2) Created a unit test in the "test\unit" folder that extends GrailsUnitTestCase. 3) Created a test method in said unit test class and had it instantiate the org.easymock.Capture class, so that it has a compile time dependency on the EasyMock library that is test scoped (and obviously imported it in the .groovy file). 4) Build the project using: mvn clean package 5) Looked at the output to verify that the test passed and that the build (compilation) was successful. Therefore, this does NOT appear to be an issue with Grails unit tests executed via Maven, if you let it get picked up via the default test phase in the life cycle. I did not try using the Grails Maven TestApp goal(mvn grails:test-app) – though I doubt it will behave any differently. I suppose it is possible that the reporter meant integration tests (I do know that there are other issues relating to Grails trying to instantiate various Spring contexts multiple times when running the integration tests from Maven – this only seems to happen from Maven and not from the Grails command line). I can post the sample project, POM file, and test case if necessary to help resolve this issue.
Hide
Peter Ledbrook added a comment -

I have to admit, I don't really understand what the issue is, hence I'm wary of automatically applying Richard's fix. One problem is that 'test' scope is not the same as 'runtime': some dependencies will be in 'runtime' that aren't in 'test' so the proposed fix will likely break some applications.

I can't quite remember what @requiresDependencyResolution does, but I think it populates the root class loader for Grails, allowing you to reference those classes from build and event scripts without using classLoader.loadClass(). So perhaps there are suitable workarounds?

Show
Peter Ledbrook added a comment - I have to admit, I don't really understand what the issue is, hence I'm wary of automatically applying Richard's fix. One problem is that 'test' scope is not the same as 'runtime': some dependencies will be in 'runtime' that aren't in 'test' so the proposed fix will likely break some applications. I can't quite remember what @requiresDependencyResolution does, but I think it populates the root class loader for Grails, allowing you to reference those classes from build and event scripts without using classLoader.loadClass(). So perhaps there are suitable workarounds?
Hide
Jonathan Pearlin added a comment -

The problem (as I understand it, which I will admit may not be correct) is that when Maven enters the test phase of execution and therefore executes the bound mojo (MvnTestMojo from the Grails Maven plugin), you get ClassNotFoundExceptions, as the claim is that "test" scoped dependencies are NOT being put on the classpath for the underlying execution of the Grails "TestApp" script. However, from both of my comments, I cannot reproduce this behavior (I can reproduce it if I leave out the dependency needed to compile the tests entirely, obviously). As far as I can tell, they are being added to the test classpath, Grails is able to see them, and they are NOT being added to the generated WAR file, which is the correct behavior. As I mentioned earlier, it is possible that the reporter(s) are using different Maven goals to execute, which is when the problem manifests itself (i.e. mvn grails:test-app instead of mvn clean package, etc). I did not test all of those cases and would like someone to give more details about what scenario is causing the issue. Therefore, I am not sure what the issue is, as the one I think it is, is not an issue or cannot be reproduced.

Show
Jonathan Pearlin added a comment - The problem (as I understand it, which I will admit may not be correct) is that when Maven enters the test phase of execution and therefore executes the bound mojo (MvnTestMojo from the Grails Maven plugin), you get ClassNotFoundExceptions, as the claim is that "test" scoped dependencies are NOT being put on the classpath for the underlying execution of the Grails "TestApp" script. However, from both of my comments, I cannot reproduce this behavior (I can reproduce it if I leave out the dependency needed to compile the tests entirely, obviously). As far as I can tell, they are being added to the test classpath, Grails is able to see them, and they are NOT being added to the generated WAR file, which is the correct behavior. As I mentioned earlier, it is possible that the reporter(s) are using different Maven goals to execute, which is when the problem manifests itself (i.e. mvn grails:test-app instead of mvn clean package, etc). I did not test all of those cases and would like someone to give more details about what scenario is causing the issue. Therefore, I am not sure what the issue is, as the one I think it is, is not an issue or cannot be reproduced.
Hide
Jon Barksdale added a comment -

Since I opened the ticket, I feel obligated to respond

I haven't looked at this since it was opened, 2 years ago. My company switched over to the using the grails scripts to build because it seemed painfully obvious that no work was being done on the maven plugin, and I no longer remember what the issue even was.

If Richard and others are still having this issue, then I will have to defer to them to provide current examples that display the error.

Sorry I can't be more help.

Show
Jon Barksdale added a comment - Since I opened the ticket, I feel obligated to respond I haven't looked at this since it was opened, 2 years ago. My company switched over to the using the grails scripts to build because it seemed painfully obvious that no work was being done on the maven plugin, and I no longer remember what the issue even was. If Richard and others are still having this issue, then I will have to defer to them to provide current examples that display the error. Sorry I can't be more help.

People

Vote (6)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved: