Is this Maven 4 only?

Is this Maven 4 only?

Yes, I've created a 3.x branch to support Maven 3 plugins and master will support Maven 4 plugins. The goal is to split the plugins to ease maintenance, as the code will ultimately be quite different. See https://issues.apache.org/jira/browse/MPLUGIN-523. We should also drop the Maven 4.x support from the 3.x branch.

Is this Maven 4 only?

Yes, I've created a 3.x branch to support Maven 3 plugins and master will support Maven 4 plugins. The goal is to split the plugins to ease maintenance, as the code will ultimately be quite different. See https://issues.apache.org/jira/browse/MPLUGIN-523. We should also drop the Maven 4.x support from the 3.x branch.

I see. There is no way to have this in one branch with common modules and module per Maven version?

Is this Maven 4 only?

Yes, I've created a 3.x branch to support Maven 3 plugins and master will support Maven 4 plugins. The goal is to split the plugins to ease maintenance, as the code will ultimately be quite different. See https://issues.apache.org/jira/browse/MPLUGIN-523. We should also drop the Maven 4.x support from the 3.x branch.

I see. There is no way to have this in one branch with common modules and module per Maven version?

Sure, I suppose it's technically feasible, but instead of streamlining and making the code simpler, it will have the exact opposite effect.
The javadoc generator is now irrelevant, and for the annotation based generator, while I kept a single class for the alpha versions, it is becoming more problematic with beta-3, as the API seems to diverge a bit with the Maven 3 one. We currently generate a plugin.xml but this is a bit hacky as it assumes there's no difference between the 3.x and 4.x ones. We do have a writer which is generated in Maven 4 which we could use to write the plugin.xml (do we really need it btw ?). I was hoping to clean things and avoids lots of those hacks to make the code more robust.

Resolve #828