[
https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352406#comment-352406
]
Robert Scholte commented on SUREFIRE-855:
-----------------------------------------
I've seen many developers struggling with Streams, resulting in code like this
(because they know {{Files}}, though not fully understand ;) ):
{code}
URL url = this.getClass().getResource( "/messages.properties" );
File file = new File( url.toURI() );
// now read file
{code}
As long as {{messages.properties}} is accessible as a File under
{{target/classes}} this will work, but as soon as it should be read as a
JarEntry, this code will fail.
Once the jar is available, that should always be the file used instead of the
classes-folder.
Current workaround is
{code:xml}
<configuration>
<classesDirectory>target/fake</classesDirectory>
<additionalClasspathElements>
<additionalClasspathElement>target/${project.build.finalName}.jar</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
{code}
> 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
>
> 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)
