Skip to content

Conversation

@slawekjaranowski
Copy link
Member

  • Next part
  • bump plugin-testing to 3.5.0
  • cleanups after parent

Following this checklist to help us incorporate your
contribution quickly and easily:

  • Your pull request should address just one issue, without pulling in other changes.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Each commit in the pull request should have a meaningful subject line and body.
    Note that commits might be squashed by a maintainer on merge.
  • Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.
    This may not always be possible but is a best-practice.
  • Run mvn verify to make sure basic checks pass.
    A more thorough check will be performed on your pull request automatically.
  • You have run the integration tests successfully (mvn -Prun-its verify).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

Copy link
Contributor

@sparsick sparsick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, please check if the following dependencies are still necessary:

    <dependency>
      <!-- support for JUnit 4 -->
      <groupId>org.junit.vintage</groupId>
      <artifactId>junit-vintage-engine</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.13.2</version>
      <scope>test</scope>
    </dependency>

Should we rename the test classes, so that they have a Test suffix?

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;

public class TestIncludeExcludeUnpackMojo extends AbstractDependencyMojoTestCase {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can AbstractDependencyMojoTestCase be deleted? IMHO after this refactoring it should be possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are still test based on it ...

}

public void assertMarkerFiles(Collection<ArtifactItem> items, boolean exist) {
private void assertMarkerFiles(UnpackMojo mojo, Collection<ArtifactItem> items, boolean exist) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it the same private method like in TestIncludeExcludeUnpackMojo? If we have more such assert method, we should move them to a separate Assertion class.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wil check after finish

@slawekjaranowski slawekjaranowski self-assigned this Jan 12, 2026
@slawekjaranowski slawekjaranowski marked this pull request as draft January 12, 2026 21:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants