Forwarding my last comment to the mailing list instead of discussing it on this specific ticket. It would go for any plugin parameter that we remove now when we bump a plugin to v3.0.0 and can afford breaking backwards compatibility.
Keeping the parameter as deprecated but having it issue an exception could simplify for the users. WDYT? /Anders ---------- Forwarded message ---------- From: Anders Hammar (JIRA) <[email protected]> Date: Mon, Apr 4, 2016 at 8:50 PM Subject: [jira] [Commented] (MJAR-210) Remove useDefaultManifestFile parameter To: [email protected] [ https://issues.apache.org/jira/browse/MJAR-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224801#comment-15224801 ] Anders Hammar commented on MJAR-210: ------------------------------------ Just an idea, should we keep params that we want to remove but mark them as deprecated and have them issue an exception with a good error message? To simplify for people upgrading and catch these breaking changes. > Remove useDefaultManifestFile parameter > --------------------------------------- > > Key: MJAR-210 > URL: https://issues.apache.org/jira/browse/MJAR-210 > Project: Maven JAR Plugin > Issue Type: Improvement > Affects Versions: 3.0.0 > Reporter: Karl Heinz Marbaise > Assignee: Karl Heinz Marbaise > Fix For: 3.0.0 > > > The following: > {code} > @Parameter( property = "maven.jar.useDefaultManifestFile", defaultValue = "false" ) > private boolean useDefaultManifestFile; > {code} > does not make sense in general, cause it can be handled via [MavenArchiver|http://maven.apache.org/shared/maven-archiver/index.html] configuration. So this should be completely removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
