[jira] (MNG-5221) Default version of m-site-p does not work (no reports)
[ https://jira.codehaus.org/browse/MNG-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MNG-5221. - Resolution: Duplicate Fix Version/s: 3.0.4 Assignee: Olivier Lamy > Default version of m-site-p does not work (no reports) > -- > > Key: MNG-5221 > URL: https://jira.codehaus.org/browse/MNG-5221 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle, Sites & Reporting >Affects Versions: 3.0.3 > Environment: n/a >Reporter: Anders Hammar >Assignee: Olivier Lamy > Fix For: 3.0.4 > > > By default, v2.0.1 of maven-site-plugin is used. However, v3.0 of the > m-site-p is required to fully work with Maven 3.0.x. Thus, the site part does > not work out-of-the-box (no reports are generated) which is unfortunate as it > makes it unnecessary complicated for new users (and simple tests where you > don't want to do extensive configuration in the pom). > I ask for the default version of maven-site-plugin to be bumped to v3.0. -- 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] (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=287604#comment-287604
]
Marcin Cinik commented on SUREFIRE-770:
---
I'm facing the same issue. This is in my opinion not an issue with JPA. In any
situation, there is a configuration file which must be different for
testing/normal build, this problem occurs.
Let's say I have
src/main/resources/META-INF/ejb-jar.xml
src/test/resources/META-INF/ejb-jar.xml
those two files contain different configuration (for whatever reason - you can
imagine that I'm binding mock session beans instead of real ones). In this case
the plugin would create two directories
target/classes/META-INF/ejb-jar.xml
target/test-classes/META-INF/ejb-jar.xml
and include both files in the classpath which disables our embedded testing
app-server from resolving the right one.
I don't understand the rationale behind the last comment of Kristian Rosenvold:
{quote}
Complain to JPA about this issue
{quote}
Can you spotlight a bit what you meant ? It looks like it doesn't only concern
JPA...
> 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
> Labels: proposedWontFix
> Fix For: Backlog
>
>
> 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.
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] (MSITE-627) upgrade to reporting-exec 1.0.2
[ https://jira.codehaus.org/browse/MSITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Wipplinger updated MSITE-627: - Attachment: MSITE-627.tar.gz simple integration test which instantiates a sink in a maven report > upgrade to reporting-exec 1.0.2 > --- > > Key: MSITE-627 > URL: https://jira.codehaus.org/browse/MSITE-627 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Improvement >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1 > > Attachments: MSITE-627.tar.gz > > -- 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] (MPMD-134) Update to PMD 4.3 -- allow target to java 7
[ https://jira.codehaus.org/browse/MPMD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287608#comment-287608 ] Eric Barboni commented on MPMD-134: --- Hi Dennis, 2.7-SNAPSHOT working well with 1.7. Thanks a lot > Update to PMD 4.3 -- allow target to java 7 > --- > > Key: MPMD-134 > URL: https://jira.codehaus.org/browse/MPMD-134 > Project: Maven 2.x PMD Plugin > Issue Type: Wish > Components: PMD >Reporter: Eric Barboni >Assignee: Dennis Lundberg > Fix For: 2.7 > > Attachments: CpdReportGenerator.java > > > After patching some source file with new Java 7 diamond operator (i.e. new > HashMap<>()) all reports on this files are broken due to parsing error. > It would be nice to patch the next 2.7 plug-in with 4.3 PMD to support all > Java version grammar. -- 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] (MSITE-627) upgrade to reporting-exec 1.0.2
[ https://jira.codehaus.org/browse/MSITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSITE-627. -- Resolution: Fixed fixed r1228165 Thanks ! > upgrade to reporting-exec 1.0.2 > --- > > Key: MSITE-627 > URL: https://jira.codehaus.org/browse/MSITE-627 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Improvement >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1 > > Attachments: MSITE-627.tar.gz > > -- 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] (MECLIPSE-437) Ordering of .classpath entries when using a newer version of JARs already included in the JDK.
[ https://jira.codehaus.org/browse/MECLIPSE-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287621#comment-287621 ] Robert McEneaney commented on MECLIPSE-437: --- This fix has also broken our build. Shouldn't the plugin do the same thing that Eclipse itself does when creating a project, i.e. JRE classpathentry first, then dependent JARS? > Ordering of .classpath entries when using a newer version of JARs already > included in the JDK. > -- > > Key: MECLIPSE-437 > URL: https://jira.codehaus.org/browse/MECLIPSE-437 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: WinXP, Maven 2.0.7 >Reporter: Patrick Zeising >Assignee: nicolas de loof > Fix For: 2.6 > > > While using a newer version of JaxWS (https://jax-ws.dev.java.net/) than the > one supplied with JDK6 the generated .classpath file in my project directory > contains all relevant entries headed by the entry for the JRE container. > ---CODE--- > > > > >path="M2_REPO/commons-lang/commons-lang/2.3/commons-lang-2.3.jar" > sourcepath="M2_REPO/commons-lang/commons-lang/2.3/commons-lang-2.3-sources.jar"/> > >path="M2_REPO/dev/java/net/jaxws-api/2.1.1/jaxws-api-2.1.1.jar"/> > >path="M2_REPO/commons-logging/commons-logging/1.1/commons-logging-1.1.jar" > sourcepath="M2_REPO/commons-logging/commons-logging/1.1/commons-logging-1.1-sources.jar"/> > > ---/CODE--- > As long as the JRE_CONTAINER is mentioned and loaded first my project will > not compile in Eclipse since I am using operations unique to the newer > version of JaxWS. When I set the order of the classpath entries in Eclipse > manually (Properties - Java Build Path - Order and Export, setting the entry > for JRE_CONTAINER to the 'bottom') my project will compile of course. > Nicolas de Loof suggested the following in my post to the maven users mailing > list > (http://www.nabble.com/Maven2-Eclipse-Plugin---ordering-of-.classpath-entries-p16722527s177.html): > ---CITE--- > Maybe the eclipse plugin could detect java* and javax* groupIds and force > them as toplevel ? > This would require : > - improve EclipseConfigWriter to have a new getJavaApiDeps(), and remove > those deps from getDepsOrdered > - improve EclipseClasspathWriter to write getJavaApiDeps prior to the JRE > container. > ---/CITE--- -- 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] (MECLIPSE-437) Ordering of .classpath entries when using a newer version of JARs already included in the JDK.
[ https://jira.codehaus.org/browse/MECLIPSE-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287621#comment-287621 ] Robert McEneaney edited comment on MECLIPSE-437 at 1/6/12 8:42 AM: --- This fix has also broken our build in Eclipse. Shouldn't the plugin do the same thing that Eclipse itself does when creating a project, i.e. JRE classpathentry first, then dependent JARS? was (Author: formalshorts): This fix has also broken our build. Shouldn't the plugin do the same thing that Eclipse itself does when creating a project, i.e. JRE classpathentry first, then dependent JARS? > Ordering of .classpath entries when using a newer version of JARs already > included in the JDK. > -- > > Key: MECLIPSE-437 > URL: https://jira.codehaus.org/browse/MECLIPSE-437 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: WinXP, Maven 2.0.7 >Reporter: Patrick Zeising >Assignee: nicolas de loof > Fix For: 2.6 > > > While using a newer version of JaxWS (https://jax-ws.dev.java.net/) than the > one supplied with JDK6 the generated .classpath file in my project directory > contains all relevant entries headed by the entry for the JRE container. > ---CODE--- > > > > >path="M2_REPO/commons-lang/commons-lang/2.3/commons-lang-2.3.jar" > sourcepath="M2_REPO/commons-lang/commons-lang/2.3/commons-lang-2.3-sources.jar"/> > >path="M2_REPO/dev/java/net/jaxws-api/2.1.1/jaxws-api-2.1.1.jar"/> > >path="M2_REPO/commons-logging/commons-logging/1.1/commons-logging-1.1.jar" > sourcepath="M2_REPO/commons-logging/commons-logging/1.1/commons-logging-1.1-sources.jar"/> > > ---/CODE--- > As long as the JRE_CONTAINER is mentioned and loaded first my project will > not compile in Eclipse since I am using operations unique to the newer > version of JaxWS. When I set the order of the classpath entries in Eclipse > manually (Properties - Java Build Path - Order and Export, setting the entry > for JRE_CONTAINER to the 'bottom') my project will compile of course. > Nicolas de Loof suggested the following in my post to the maven users mailing > list > (http://www.nabble.com/Maven2-Eclipse-Plugin---ordering-of-.classpath-entries-p16722527s177.html): > ---CITE--- > Maybe the eclipse plugin could detect java* and javax* groupIds and force > them as toplevel ? > This would require : > - improve EclipseConfigWriter to have a new getJavaApiDeps(), and remove > those deps from getDepsOrdered > - improve EclipseClasspathWriter to write getJavaApiDeps prior to the JRE > container. > ---/CITE--- -- 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] (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=287640#comment-287640 ] Kristian Rosenvold commented on SUREFIRE-770: - The way this works is that when the tests are being run, the classpath for the /tests/ will be *before* the the classpath of the regular production files in the classpath. So even though there are multiple instances of the file, even the most brain damaged of tools should pick up the files in the correct classpath order. In a multi-module project only the "test" scope of the module being run is included in the classpath, which means that your test-scoped configuration needs to be in src/test/resources of the actual unit test project being run. If this sounds like a limitation you can build a separate jar file with test scope that contains these jar files. The linked stackoverflow post seems to indicate that JPA has somehow messed up this scheme. > 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 > Labels: proposedWontFix > Fix For: Backlog > > > 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. 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
