[jira] Created: (SUREFIRE-770) persistence.xml in src/test/resources/META-INF is not taken into account
persistence.xml in src/test/resources/META-INF is not taken into account Key: SUREFIRE-770 URL: https://jira.codehaus.org/browse/SUREFIRE-770 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.9 Environment: Windows XP Reporter: Wolfgang Grossinger When i have a persistence.xml in /src/main/resources/META-INF and in /src/test/resources/META-INF the xml for the test is never used. I found a few issues how to fix this but nobody had an explanation why this behavior is as it is. For me this behavior is really strange (and I couldn't believe that this is not my fault and is really not working). It seem this has to do with classloading - in my opinion, the test classes and the test resources should have priority, otherwise the whole separation of main/test is useless. I hope, that there is no real reason why this is so at the moment, because this behavior is really strange and absolutely against what the normal user would expect. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-770) persistence.xml in src/test/resources/META-INF is not taken into account
[ https://jira.codehaus.org/browse/SUREFIRE-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280878#comment-280878 ] Wolfgang Grossinger commented on SUREFIRE-770: -- Look at this link: http://stackoverflow.com/questions/385532/how-to-configure-jpa-for-testing-in-maven > persistence.xml in src/test/resources/META-INF is not taken into account > > > Key: SUREFIRE-770 > URL: https://jira.codehaus.org/browse/SUREFIRE-770 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.9 > Environment: Windows XP >Reporter: Wolfgang Grossinger > > When i have a persistence.xml in /src/main/resources/META-INF and in > /src/test/resources/META-INF the xml for the test is never used. I found a > few issues how to fix this but nobody had an explanation why this behavior is > as it is. For me this behavior is really strange (and I couldn't believe that > this is not my fault and is really not working). It seem this has to do with > classloading - in my opinion, the test classes and the test resources should > have priority, otherwise the whole separation of main/test is useless. I > hope, that there is no real reason why this is so at the moment, because this > behavior is really strange and absolutely against what the normal user would > expect. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-163) Weird result in multi-profile build
Wolfgang Grossinger created MEAR-163:
Summary: Weird result in multi-profile build
Key: MEAR-163
URL: https://jira.codehaus.org/browse/MEAR-163
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.8
Environment: Windows 7 64Bit; Java 6 / 32 Bit
Reporter: Wolfgang Grossinger
I configured my pom to create 2 separate EAR-files (with 2 different
classifiers) when a certain profile is active and get 2 weird things:
1.) I get a third 'normal' EAR-File too.
2.) I use true which has no effect, so at the end, I get 3
files with the same content and different names.
The config looks like:
org.apache.maven.plugins
maven-ear-plugin
web
package
ear
5
web-${zps.build.identifier}
true
ZPSWEB
at.gv.bmi
zps-gwt
/${zps.web.contextRoot}
at.gv.bmi
zps-integration
true
srv
package
ear
5
srv-${zps.build.identifier}
true
ZPSSRV
at.gv.bmi
zps-gwt
true
at.gv.bmi
zps-integration
/${zps.srv.contextRoot}
Regards,
Wolfgang
--
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
[jira] (MASSEMBLY-660) Creating a Zip doesn't work correctly
[ https://jira.codehaus.org/browse/MASSEMBLY-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wolfgang Grossinger updated MASSEMBLY-660: -- Attachment: (was: ZPS ProtocolUploader Handbuch.pdf) > Creating a Zip doesn't work correctly > - > > Key: MASSEMBLY-660 > URL: https://jira.codehaus.org/browse/MASSEMBLY-660 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows 7 64 Bit >Reporter: Wolfgang Grossinger >Assignee: Kristian Rosenvold > > We have a simple batch that is deployed in 2 Parts to Nexus: the .jar itself > and a .zip with configuration information which also includes the attached > .pdf. > After the deployment to Nexus, everything is correct so far (we can still > open the .pdf and the content is ok). > When we deploy the Batch to our Host-System, we load the dependencies from > Nexus, unpack them, prepare the config files for the according > Host-Environment and repack all again as a .zip-File. > - Unpackaging seems to be ok, we can still open the .pdf and read the > contents, but after repackaging the files, the .pdf is broken (the size is > still the same, we can open it but it is no longer possible to display the > content as it seems that one bit or so has changed. > - We checked also our Zip-Programs to be sure it is not because of a bug in > one of the programs but neither 7zip nor the Windows built in program was > able to produce a correct result. > -> this may not be a direct problem of the assembly plugin but of some libs, > the plugin uses. As we don't know which libs you use we just can report the > problem here, you may be able to switch to a newer lib or report the bug to > the right people :-) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-660) Creating a Zip doesn't work correctly
Wolfgang Grossinger created MASSEMBLY-660: - Summary: Creating a Zip doesn't work correctly Key: MASSEMBLY-660 URL: https://jira.codehaus.org/browse/MASSEMBLY-660 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Windows 7 64 Bit Reporter: Wolfgang Grossinger Attachments: ZPS ProtocolUploader Handbuch.pdf We have a simple batch that is deployed in 2 Parts to Nexus: the .jar itself and a .zip with configuration information which also includes the attached .pdf. After the deployment to Nexus, everything is correct so far (we can still open the .pdf and the content is ok). When we deploy the Batch to our Host-System, we load the dependencies from Nexus, unpack them, prepare the config files for the according Host-Environment and repack all again as a .zip-File. - Unpackaging seems to be ok, we can still open the .pdf and read the contents, but after repackaging the files, the .pdf is broken (the size is still the same, we can open it but it is no longer possible to display the content as it seems that one bit or so has changed. - We checked also our Zip-Programs to be sure it is not because of a bug in one of the programs but neither 7zip nor the Windows built in program was able to produce a correct result. -> this may not be a direct problem of the assembly plugin but of some libs, the plugin uses. As we don't know which libs you use we just can report the problem here, you may be able to switch to a newer lib or report the bug to the right people :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-660) Creating a Zip doesn't work correctly
[ https://jira.codehaus.org/browse/MASSEMBLY-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=329504#comment-329504 ] Wolfgang Grossinger commented on MASSEMBLY-660: --- During the creation of the test project, I found the bug, so you can close the ticket. The problem was, that during the step to deploy the .jar + config files, the config is filtered to prepare it for the correct environment where it is deployed to. This also included the .pdf, what was wrong. Maybe you can open another issue for resource filtering, because manipulating .pdf - Files during resource filtering seems to be quite crazy to me... Thank's for the great test case, I'm not sure if/when I would have found the mistake without you :-) > Creating a Zip doesn't work correctly > - > > Key: MASSEMBLY-660 > URL: https://jira.codehaus.org/browse/MASSEMBLY-660 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows 7 64 Bit >Reporter: Wolfgang Grossinger > Attachments: ZPS ProtocolUploader Handbuch.pdf > > > We have a simple batch that is deployed in 2 Parts to Nexus: the .jar itself > and a .zip with configuration information which also includes the attached > .pdf. > After the deployment to Nexus, everything is correct so far (we can still > open the .pdf and the content is ok). > When we deploy the Batch to our Host-System, we load the dependencies from > Nexus, unpack them, prepare the config files for the according > Host-Environment and repack all again as a .zip-File. > - Unpackaging seems to be ok, we can still open the .pdf and read the > contents, but after repackaging the files, the .pdf is broken (the size is > still the same, we can open it but it is no longer possible to display the > content as it seems that one bit or so has changed. > - We checked also our Zip-Programs to be sure it is not because of a bug in > one of the programs but neither 7zip nor the Windows built in program was > able to produce a correct result. > -> this may not be a direct problem of the assembly plugin but of some libs, > the plugin uses. As we don't know which libs you use we just can report the > problem here, you may be able to switch to a newer lib or report the bug to > the right people :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
