Re: Creating stub artifacts through ArtifactStubFactory

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Creating stub artifacts through ArtifactStubFactory

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.


[1] []

On 12-12-2019 09:49:16, Maarten Mulders <[hidden email]> 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?



To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]