The maven-plugin-testing-harness isn't that popular anymore by most Maven Developers. Even though it executes like a plugin, there's still a lot of stubbing required to make a test work. Hence the integration-tests with the maven-invoker-plugin which reflects much better the usage with Maven.
However, it would be great to fix these test, either as they are or transformed to IT's. And there's a third option: use the mock-repository-manager [1] The returning issue is that a Mojo requires a context provided by Maven to execute. With a unittest you need to prepare that context, with an integrationtest it is created for you. The businesslogic behind the mojo might be suitable to unittest, but not always. I realize I didn't really answer the question, but having those tests up and running again would be great. I would go for the option with the least amount of effort, which might indeed be improving the maven-plugin-testing-harness. I'd suggest to code your proposal, quite often that tells more than words and share your PR. Robert [1] https://www.mojohaus.org/mrm/index.html [https://www.mojohaus.org/mrm/index.html] On 12-12-2019 09:49:16, Maarten Mulders <[email protected]> wrote: Hi all, As I was working on MDEP-666 I noticed the test suite for the tree mojo is effectively disabled. This is also blocking progress on MDEP-435, as it's hard to verify it doesn't break anything. So I thought of re-enabling the test suite for the tree mojo. I found a way to make it work, but it requires changes to the way "stub" artifacts are created. Creating stub artifacts is done in the "ArtifactStubFactory" class, which comes from the maven-plugin-testing-harness module. That class has a method "getReleaseAndSnapshotArtifacts()" which creates and returns a sample "release" and "snapshot" artifact. (Side-note: I don't like getXXX methods that do more that returning something that's already there.) The "ArtifactStubFactory" class can be configured to also create (empty) files on disk matching the artifacts. Unfortunately, it will only create the artifact file itself (say test-group/test-artifact/1.0/test-artifact-1.0.jar), but not the corresponding POM (say, test-group/test-artifact/1.0/test-artifact-1.0.pom). Because of this, the "stub" artifacts can effectively not be resolved. I am thinking of extending the "ArtifactStubFactory" class. Next to a configuration flag to actually create the file on disk, I am proposing another configuration flag to actually create a corresponding POM file. By default, it would be false to maintain its current behaviour. What do you think of this idea? Cheers, Maarten --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
