[
https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354120#comment-354120
]
Robert Scholte commented on SUREFIRE-855:
-----------------------------------------
It's not worth adding a parameter just for 2.2.1. And you might call it an
improvement, but IMHO the expected behavior is using the jar, so I would
consider it a bug.
Instead of adding a parameter we could do 2 things:
- change the maven prerequisite to 3.0 for the maven-failsafe-plugin so it can
use the required improvements. Unlike surefire, which is part of most
lifecycles, for the failsafe plugin I think it is valid to do so if this
changes the behavior as expected without that many changes.
- use reflection to access the Maven 3 methods. We do this more often if we
want to support older versions but would like to use new functionality if
available.
> Allow failsafe to use actual jar file instead of target/classes
> ---------------------------------------------------------------
>
> Key: SUREFIRE-855
> URL: https://jira.codehaus.org/browse/SUREFIRE-855
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin
> Affects Versions: 2.12
> Reporter: Benson Margulies
> Priority: Critical
>
> I've got some code that calls Class.getPackage() to see the manifest. I want
> to test it. A seemingly logical scheme here would be to have failsafe put the
> actual packaged jar into the classpath instead of the unpacked directory --
> or some way to get the manifest copied across.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
