On 9/25/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > On Sat, 2005-09-24 at 04:31 +0000, John Fallows wrote: > > On 9/23/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > > On Fri, 2005-09-23 at 08:03 +0000, John Fallows wrote: > > > > I've created a custom compiler mojo that extends AbstractCompilerMojo > > > > from the maven-compiler-plugin. > > > > > > Is there a special reason for this? We where hoping that a new Compiler > > > implementation would suffice. The Compiler interface is defined in > > > plexus-compiler-api and you can select your own implementation by > > > setting the compilerId flag. > > [snip] > > In the snipped out part I understand what your issue is and agree that > it is a real issue. > > > Perhaps there is a better approach? > > The issue is not specific to mock objects, we could use the same thing > for our TCK type tests that we have for Maven SCM. See [1] for a issue > to follow (and vote for). I'm still not entirely sure how you would > separate out the tests for the artifacts itself and the reusable tests. > > Anyway, if you are mocking a Compiler implementation I'd be interested > to put that back into the Plexus repository.
We'd need to decide on the correct lifecycle phase binding for the "mock" compiler. Strictly speaking, the input to the test-compile phase should include the compiled mock classes as a dependency. Presumably the default directories for source and target would be src/mock/java and target/mock-classes. We'd also want to take care of mock resources, making sure they are copied from src/mock/resources to target/mock-classes. This is sounding more like an extension of the current m2 lifecycle. validate generate-sources process-sources generate-resources process-resources compile process-classes generate-mock-sources process-mock-sources generate-mock-resources process-mock-resources mock-compile generate-test-sources process-test-sources generate-test-resources process-test-resources test-compile test package integration-test verify install deploy > [1]: http://jira.codehaus.org/browse/MNG-932 Yes, I understand that it would be generally useful to deliver a subset of the unit test code as a JAR. The above proposal still stands though, although the name "mock" can be treated as a placeholder for that subset until we have a better name. Alternatively, is there any mileage in the idea of having completely separate sub-modules for main, mock, and test, all inside the api-module? Kind Regards, John Fallows Kind Regards, John Fallows.
