[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-855. - Resolution: Fixed commit 0eb85f7a2f971968a9293307616818a0d85f2ee8 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 Assignee: Tibor Digana Priority: Critical Fix For: 2.19 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358700#comment-358700 ] Tibor Digana commented on SUREFIRE-855: --- @Benson @Robert I have updated my GitHub PR with the solution. You may have a look. There is documentation update as well. I might be worth to write an additional IT for checking existing jar resources (properties, xml, etc.) via reading class loader resources. 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 Assignee: Tibor Digana Priority: Critical Fix For: 2.19 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-855: -- Fix Version/s: 2.19 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 Assignee: Tibor Digana Priority: Critical Fix For: 2.19 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358281#comment-358281 ] Tibor Digana commented on SUREFIRE-855: --- @Benson @Robert I have opened the GitHub PR for this issue. I guess we would be happy not using any additional ClassLoaders. https://github.com/apache/maven-surefire/pull/72 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 Assignee: Tibor Digana 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[
https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358282#comment-358282
]
Robert Scholte commented on SUREFIRE-855:
-
[~tibor17], it's much safer to use {{MavenProject.getArtifact().getFile()}}
which is the file being installed/deployed in the end.
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
Assignee: Tibor Digana
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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358284#comment-358284 ] Tibor Digana commented on SUREFIRE-855: --- @Robert thx. Don't worry this is not final. I am running the tests... 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 Assignee: Tibor Digana 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[
https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358229#comment-358229
]
Robert Scholte commented on SUREFIRE-855:
-
Can you control the classloaders? If so, how about adding a WarClassLoader,
which prefixes the name with {{/WEB-INF/classes/}}. Otherwise, only do it for
jars, which should cover most of the usecases.
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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358235#comment-358235 ] Tibor Digana commented on SUREFIRE-855: --- Alright this is possible with WarClassLoader. What about packaging=bundle which is usual in OSGi projects. Even if the content is related to JAR, the packaging=bundle may refer to any content. Are we able to recognize the binary content other way? 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358238#comment-358238 ] Robert Scholte commented on SUREFIRE-855: - I haven't worked with bundles, so I can't help you there. Maybe the answer lies within a OSGi container implementation itself. 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358239#comment-358239 ] Benson Margulies commented on SUREFIRE-855: --- I have recently been using pax-exam with failsafe to test OSGi bundles. You need to pass project.build.directory and project.version into the test as system properties, so that you can load the bundle by pathname. If you need other bundles from earlier in the reactor, you have to use the maven-dependency-plugin get them; if you use pax-aether, you end up with old versions. 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[
https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358268#comment-358268
]
Tibor Digana commented on SUREFIRE-855:
---
Benson, can you make a temporary workaround proposed by Robert? I want to know
if we break the current PAX users.
The fix seems to be quite doable.
Can somebody tell me if we have an artifact with EAR, WAR ClassLoaders in Maven
project?
I can get the JAR file path quite easily in order to fallback to JAR (if any
exists):
MavenProject#getModel().getBuild().getDirectory()
MavenProject#getModel().getBuild().getFinalName()
If the JAR file does not exist, I will fallback to
${project.build.outputDirectory}.
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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-855: - Assignee: Tibor Digana 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 Assignee: Tibor Digana 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358219#comment-358219 ] Tibor Digana commented on SUREFIRE-855: --- I think this can be fixed in 2.19. The only problem is packaging. For jar it's clear, but I guess the other (bundle, war, etc) should fallback to test-classes. Any idea? 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354051#comment-354051 ] Tibor Digana commented on SUREFIRE-855: --- @Robert This would have to be a new parameter in plugin due to backwards compatibility in 2.x. Or other option is to enable a changed behavior of surefire in 3.0 if and only if the build phase = package. What you think ? 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated SUREFIRE-855: Priority: Critical (was: Major) 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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[
https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
classesDirectorytarget/fake/classesDirectory
additionalClasspathElements
additionalClasspathElementtarget/${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)
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
Benson Margulies created SUREFIRE-855: - Summary: 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
