Hi, On 4/4/16 8:59 PM, Anders Hammar wrote:
Forwarding my last comment to the mailing list instead of discussing it on this specific ticket.
Good idea...prefered way...
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?
Sure make sense ...so i will add the behaviour to the jar-plugin...
/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)
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
