Skip to content

Conversation

@Giovds
Copy link
Contributor

@Giovds Giovds commented Dec 12, 2025

Closes #333

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.

@Giovds
Copy link
Contributor Author

Giovds commented Jan 9, 2026

@elharo Since this JIRA ticket was originally your request, could you take a look?
@gnodet Can I ask you to review as well, as I know you've been working on the help plugin in the past?

@Giovds Giovds force-pushed the MPH-219-make-util-class-of-abstract-effective-mojo branch from fd07063 to c3e66f3 Compare January 9, 2026 12:09
*
* @author <a href="mailto:vincent.siveton@gmail.com">Vincent Siveton</a>
* @since 2.1
*/
public abstract class AbstractEffectiveMojo extends AbstractHelpMojo {
Copy link
Contributor

Choose a reason for hiding this comment

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

You can't remove existing public API. You need to deprecate this instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is this an agreement on all ASF repo's? I thought this was mainly for maven-core API's.

I don't know, but do ASF-plugins support extensions of plugin public API's, do people do this? A quick search on GitHub on this class only seems to result in forks.

Alternatively I can e.g. deprecate it and change the implementation to point to the new class.
When will it be removed, and does this require a new ticket?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Commit 042a98f could be reverted if it's decided to change it. Otherwise, the commit should revert the breaking change.

Copy link
Contributor

Choose a reason for hiding this comment

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

do ASF-plugins support extensions of plugin public API's, do people do this? A quick search on GitHub on this class only seems to result in forks.

My opinion is similar. This plugin is not library, and its API are goals and their parameters. I would not consider such change to require deprecation.

This class being public does not make it public API.

Copy link
Member

Choose a reason for hiding this comment

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

exactly - plugin is not library

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.

[MPH-219] AbstractEffectiveMojo should be a utility class

4 participants