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.
Glad you asked - it is symptomatic of a bigger issue to do with
delivering public mock objects for a public api.
Consider the following project layout:
project/
api-module/
src/
main/
test/
impl-module/
src/
main/
test/
Now consider that api-module defines a public Java API for general
consumption, whereas impl-module defines private Java implementation
that can change from release to release.
Many of the interfaces in api-module have associated mock objects used
by the api-module unit test code to test various api-module classes.
Naturally, many of the tests in impl-module also need to use the mock
objects defined by the api-module test code so there is a need for
some sort of mock object dependency.
However, the mock classes are not good candidates for their own
"mock-module" because of the following cyclic dependency.
api-module (test) -> mock-module (main) -> api-module (main)
and the alternative of
mock-module (test) -> mock-module (main) -> api-module (main)
moves the api unit tests into a different project, which allows the
api build to succeed even if the api unit tests fail.
So, I am attempting to keep the mocks for the public api in the
api-module as follows:
project/
api-module/
src/
main/
mock/
test/
impl-module/
src/
main/
test/
The reason for splitting the "mock" and "test" source groups is
because I need to deliver a JAR of mock api classes only, without
including the rest of the api unit test code.
The mock api JAR is for users consuming the api-module public API to
compile against when writing their own unit tests, so we don't want it
to be polluted with unit test code that they cannot safely depend upon
to remain stable between releases.
So, to achieve this purpose, I have written a "mock" plugin with the
following goals:
mock-process-resources (process-test-resources phase)
- copies src/mock/resources to target/mock-classes
- adds src/mock/java to test compilation sourcepath
mock-compile (test-compile phase)
- compiles src/mock/java to target/mock-classes
mock-package (package phase)
- creates a new artifact, called ${artifactId}-mock
- contents of artifact from target/mock-classes
- attaches it to the project for installation and deployment (not yet tested)
My first thought was to try to reuse the compiler plugin, but it just
didn't seem feasible using this approach.
Perhaps there is a better approach?
Kind Regards,
John Fallows.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
