[jira] (MRESOURCES-120) Resource file is never overwritten
[
https://jira.codehaus.org/browse/MRESOURCES-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MRESOURCES-120.
--
Resolution: Won't Fix
Assignee: Karl-Heinz Marbaise
I will close the issue. If you have any objections / new informations (for
example tested with new version of maven-resources-plugin ) don't hesitate to
reopen the issue.
> Resource file is never overwritten
> --
>
> Key: MRESOURCES-120
> URL: https://jira.codehaus.org/browse/MRESOURCES-120
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 2.3
> Environment: Windows XP Professional SP3
> Maven 2.2.1
> jdk1.6.0_18
>Reporter: Mark Dolgov
>Assignee: Karl-Heinz Marbaise
>Priority: Minor
>
> I have the 2 resource files with the same name (config.properties) under
> following locations:
> Location 1: .../src/main/resources/config.properties (modification date
> 2009-11-25)
> Location 2: .../src/main/resources/envSpecific/test/config.properties
> (modification date 2009-12-21)
> During build, config.properties should be put under target/classes folder.
> My pom configuration (see excerpt below) makes it so that:
> 1. 'config.properties' file from location 1 is copied to target/classes;
> 2. 'config.properties' file from location 2 is copied to target/classes and
> overwrites the one from previous step.
> Maven really tries to do that, see maven output excerpt below.
> The PROBLEM: the file, copied in step 2, does NOT overwrite the one, copied
> in step 1.
> Though, it works, when I set plugin property 'overwrite' == true. But since
> files modification dates are different (see above), it should work with
> overwrite==false.
> Possible cause:
> I debugged the related code a bit, and found, that maven-resources-plugin
> uses plexus-utils-1.5.6.jar, and its FileUtils.class for copying.
> In FileUtils, starting line 2049 there is a following code block:
> {code:java}
> if ( to.lastModified() < from.lastModified() || overwrite )
> {
> copyFile( from, to );
> }
> {code}
> According debug,
> - variable 'to' references the file, which has been already copied to
> target/class folder (on step 1).
> - variable 'from' references the file from the source (location 2).
> In my environment to.lastModified()< from.lastModified() == false, because
> file referenced by 'to' has modification date, when it was copied to class
> folder.
> Possible solution:
> I guess, 'from' file should be compared not to the one in target/class
> folder, but to corresponding file from source (location 1), which was copied
> to class folder (step 1).
>
> Maven build configuration, related to resources:
> {code}
>
>
> src/main/resources
> true
>
> envSpecific/**/*
>
>
>
>
> ${basedir}/src/main/resources/envSpecific/${env}
> true
>
> **/*
>
>
>
> {code}
> Maven output (sorry, can't paste debug mode due security reasons, but it does
> not report any problems with copying):
> >mvn -Denv=test process-resources
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Election Results web module
> [INFO]task-segment: [process-resources]
> [INFO]
>
> [INFO] [resources:resources {execution: default-resources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 6 resources
> [INFO] Copying 1 resource
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> ---
> Another minor problem, is that even though (in debug mode) maven declares
> '[INFO] Copying 1 resource', but it never says, if succeeded or not.
> Sorry, if not a bug or duplicate.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-126) Cannot escape String in a filter value
[
https://jira.codehaus.org/browse/MRESOURCES-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MRESOURCES-126.
--
Resolution: Fixed
Assignee: Karl-Heinz Marbaise
After checking the Test project which has been provied by Olivier LE JACQUES
(Thanks for that) it looks that this issue has been fixed.
I have tested it with maven-resources-plugin 2.6 and 2.7 which works as
expected.
If you have any objections or new information etc please don't hesitate to
reopen the issue.
> Cannot escape String in a filter value
> --
>
> Key: MRESOURCES-126
> URL: https://jira.codehaus.org/browse/MRESOURCES-126
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: escape string
>Affects Versions: 2.3, 2.4, 2.4.1, 2.4.2, 2.4.3
>Reporter: Arnaud Heritier
>Assignee: Karl-Heinz Marbaise
> Attachments: MRESOURCES-126-IT.patch
>
>
> I have to filter a file. The value to inject to the file is foo/${name}. Thus
> in my resource I have @something@ and in my filter I would like to have
> something=foo/${name}
> I tried to use the escapeString option (\) and added in my filter I used :
> something=foo/\${name}
> I tested with various syntaxes and escape characters but it doesn't work.
> escapeString can be used to protect special characters in resources but not
> in filters. In filters properties are always resolved.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-185) Update version of plexus-utils to 3.0.18
[ https://jira.codehaus.org/browse/MRESOURCES-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MRESOURCES-185: --- Fix Version/s: 2.8 > Update version of plexus-utils to 3.0.18 > > > Key: MRESOURCES-185 > URL: https://jira.codehaus.org/browse/MRESOURCES-185 > Project: Maven Resources Plugin > Issue Type: Improvement >Affects Versions: backlog >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 2.8 > > > Upgrade plexus-utils from 3.0.15 to 3.0.18 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-185) Update version of plexus-utils to 3.0.18
[ https://jira.codehaus.org/browse/MRESOURCES-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358910#comment-358910 ] Karl-Heinz Marbaise commented on MRESOURCES-185: Fixed in [r1632876|http://svn.apache.org/r1632876]. > Update version of plexus-utils to 3.0.18 > > > Key: MRESOURCES-185 > URL: https://jira.codehaus.org/browse/MRESOURCES-185 > Project: Maven Resources Plugin > Issue Type: Improvement >Affects Versions: backlog >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 2.8 > > > Upgrade plexus-utils from 3.0.15 to 3.0.18 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-185) Update version of plexus-utils to 3.0.18
[ https://jira.codehaus.org/browse/MRESOURCES-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MRESOURCES-185: --- Assignee: Kristian Rosenvold > Update version of plexus-utils to 3.0.18 > > > Key: MRESOURCES-185 > URL: https://jira.codehaus.org/browse/MRESOURCES-185 > Project: Maven Resources Plugin > Issue Type: Improvement >Affects Versions: backlog >Reporter: Karl-Heinz Marbaise >Assignee: Kristian Rosenvold >Priority: Minor > Fix For: 2.8 > > > Upgrade plexus-utils from 3.0.15 to 3.0.18 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-142) Filter does not process sources
[
https://jira.codehaus.org/browse/MRESOURCES-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MRESOURCES-142.
--
Resolution: Cannot Reproduce
Assignee: Karl-Heinz Marbaise
To filter source files you can use the templating-maven-plugin for such
purposes. Apart from that defining a target folder as a source does not make
really sense.
I will close this issue. If you have any objections or more informations about
the issue please don't hesitate to reopen the issue.
> Filter does not process sources
> ---
>
> Key: MRESOURCES-142
> URL: https://jira.codehaus.org/browse/MRESOURCES-142
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Rainer Flicker
>Assignee: Karl-Heinz Marbaise
>
> Filter does not process sources.
> pom.xml:
> {code}
> ...
>
>
>
> src/main/java
> true
> ../filtered-sources/java
>
>
> src/main/resources
> true
>
>**/persistence-test.xml
>
>
>
> target/filtered-sources/java
> ...
> {code}
> mvn clean install -Djavamail.jndi="java:Mail"
> With version 2.5, filtered sources contains ${javamail.jndi}, while with
> version 2.4.3,
> they contain "java:Mail".
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-640) Maven searches only central repository for imported dependencies
[ https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358912#comment-358912 ] Milos Kleint commented on MSITE-640: Can someone file an issue against MNG along with the suggested patch? I suspect the core developer don't look in MSITE too frequently. > Maven searches only central repository for imported dependencies > > > Key: MSITE-640 > URL: https://jira.codehaus.org/browse/MSITE-640 > Project: Maven Site Plugin > Issue Type: Bug > Components: Maven 3 >Affects Versions: 3.0 > Environment: Windows 7 >Reporter: Markus Tippmann > Attachments: stacktrace.txt > > > We are using dependencyManagement with "import" scope like described here: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies > Problem occurs only at site generation, not at build time, where it works > perfectly. > The site plugin tries to find the imported artifacts, but searches only the > central repository and ignores the repositories in settings.xml > configuration. Mirror settings work, if "central" is mirrored, but > dependencies need to be resolved from two repositories, so one mirror does > not help here. > I try to attach the relevant parts of the stacktrace. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1067) Nested causes conflated with wrapper exception
[
https://jira.codehaus.org/browse/SUREFIRE-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1067:
---
Assignee: (was: Tibor Digana)
> Nested causes conflated with wrapper exception
> --
>
> Key: SUREFIRE-1067
> URL: https://jira.codehaus.org/browse/SUREFIRE-1067
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.13
> Environment: JDK 7u51 on Linux
>Reporter: Jesse Glick
>Priority: Critical
>
> I created a simple Maven project containing just a test
> {code}
> package p;
> import java.io.IOException;
> import org.junit.Test;
> public class SomeTest {
> @Test public void t() throws Exception {
> try {
> m();
> } catch (RuntimeException x) {
> throw new IOException(x);
> }
> }
> private void m() {
> throw new UnsupportedOperationException();
> }
> }
> {code}
> If I run this using {{maven-surefire-plugin}} 2.12.4, I get a
> {{p.SomeTest.txt}} with the expected output:
> {code:none}
> ---
> Test set: p.SomeTest
> ---
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.037 sec <<<
> FAILURE!
> t(p.SomeTest) Time elapsed: 0.009 sec <<< ERROR!
> java.io.IOException: java.lang.UnsupportedOperationException
> at p.SomeTest.t(SomeTest.java:9)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.UnsupportedOperationException
> at p.SomeTest.m(SomeTest.java:13)
> at p.SomeTest.t(SomeTest.java:7)
> ... 29 more
> {code}
> But if I use 2.13 or higher, I get
> {code:none}
> ---
> Test set: p.SomeTest
> ---
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.037 sec <<<
> FAILURE!
> t(p.SomeTest) Time elapsed: 0.009 sec <<< ERROR!
> java.io.IOException: java.lang.UnsupportedOperationException
> at p.SomeTest.m(SomeTest.java:13)
> at p.SomeTest.t(SomeTest.java:7)
> {code}
> which is missing the potentially crucial informati
[jira] (MANTRUN-192) filterArtifacts in DependencyFilesetsTask includes entire maven.local.repository
[ https://jira.codehaus.org/browse/MANTRUN-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358913#comment-358913 ] Karl-Heinz Marbaise commented on MANTRUN-192: - Is it possible to create an example project and attach the project to the issue? > filterArtifacts in DependencyFilesetsTask includes entire > maven.local.repository > > > Key: MANTRUN-192 > URL: https://jira.codehaus.org/browse/MANTRUN-192 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Steve Maring > > When I define a scope and type, if the dependencyfileset task fails to match > anything in my dependencies, the maven.project.dependencies refid will end up > containing EVERY artifact found in my local maven repo. A HUGE list. > If nothing matches, then maven.project.dependencies should contain nothing. > This is what I was trying to do ... merge the contents of map files IF they > are found. It is possible that none exist, so my test case was to comment > them out, but I end up with a process that is trying to concat EVERY single > file in my local Maven repo. > > > > org.apache.maven.plugins > maven-antrun-plugin > 1.7 > false > > > merge-maps > package > > run > > > > > refid="maven.project.dependencies"/> > > > > > > > > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTRUN-174) @ Symbols in path name confusing host resolution.
[ https://jira.codehaus.org/browse/MANTRUN-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MANTRUN-174. --- Resolution: Cannot Reproduce Assignee: Karl-Heinz Marbaise No feedback so i close the issue. If you have further information etc. don't hesitate to reopen the issue. > @ Symbols in path name confusing host resolution. > - > > Key: MANTRUN-174 > URL: https://jira.codehaus.org/browse/MANTRUN-174 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.7 > Environment: Linux Ubuntu >Reporter: Dave Fennell >Assignee: Karl-Heinz Marbaise > > I want to use an SCP target directory that has an "@" in it, like this : > 2011-12-12@15:26:11. > the scp command from effective-pom looks like this (users and passwords > replaced): > todir="user:password@hostname:/project/releases/2011-12-12@15:26:11/mule-3.2.0/apps/" > file="/usr/local/src/project/mule/myapp/target/myapp-1.0-SNAPSHOT.zip" > trust="true" failonerror="true" /> > This results in this slightly odd error: > [ERROR] BUILD ERROR > [INFO] > > [INFO] An Ant BuildException has occured: com.jcraft.jsch.JSchException: > java.net.SocketException: Invalid argument or cannot assign requested address > around Ant part ... todir="user:password@hostname:/project/releases/2011-12-12@15:26:11/mule-3.2.0/apps/" > file="/usr/local/src/project/mule/myapp/target/myapp-1.0-SNAPSHOT.zip" > trust="true" failonerror="true"/>... @ 13:242 in > /usr/local/src/whitelabel/mule/boot-config/target/antrun/build-main.xml > Before that it says: >[scp] Connecting to 15:22 > This should actually say >[scp] Connecting to hostname:22 > This is a problem with the plugin and not scp itself because if I use those > paths directly with SCP on the command line it is fine. from testing it > seems to looks for the LAST match in the line that looks something like > "@[a-z0-8]+:" i.e. between an "@" and a ":" however if there is more than one > match it's probably going to be the first one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTRUN-192) filterArtifacts in DependencyFilesetsTask includes entire maven.local.repository
[ https://jira.codehaus.org/browse/MANTRUN-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MANTRUN-192: Fix Version/s: waiting-for-feedback > filterArtifacts in DependencyFilesetsTask includes entire > maven.local.repository > > > Key: MANTRUN-192 > URL: https://jira.codehaus.org/browse/MANTRUN-192 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Steve Maring > Fix For: waiting-for-feedback > > > When I define a scope and type, if the dependencyfileset task fails to match > anything in my dependencies, the maven.project.dependencies refid will end up > containing EVERY artifact found in my local maven repo. A HUGE list. > If nothing matches, then maven.project.dependencies should contain nothing. > This is what I was trying to do ... merge the contents of map files IF they > are found. It is possible that none exist, so my test case was to comment > them out, but I end up with a process that is trying to concat EVERY single > file in my local Maven repo. > > > > org.apache.maven.plugins > maven-antrun-plugin > 1.7 > false > > > merge-maps > package > > run > > > > > refid="maven.project.dependencies"/> > > > > > > > > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1074) Should Surefire-api scan InnerClasses for Test Classes
[ https://jira.codehaus.org/browse/SUREFIRE-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358915#comment-358915 ] Tibor Digana commented on SUREFIRE-1074: Can you check it out with this runner and close this issue? https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/experimental/runners/Enclosed.java > Should Surefire-api scan InnerClasses for Test Classes > -- > > Key: SUREFIRE-1074 > URL: https://jira.codehaus.org/browse/SUREFIRE-1074 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.16 > Environment: mvn 3.0.5 > surefire-api (all versions) >Reporter: Martin Gainty > > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite > processes the Directory for > /JasperApplication/target/classes/net/sf/jasperreports/virtualization > 4/09/2014 03:24 PM 2,225 > BaseSerializationTests$SerializationJob.class > //required inner protected static class SerializationJob class was scanned by > AbstractDirectoryTestSuite > 4/09/2014 03:24 PM 3,519 BaseSerializationTests.class > BaseSerializationTests.class Base Test class successfully scanned and > processed by surefire (surefire-api) > Should AbstractDirectoryTestSuite from surefire-api scan inner (Test) classes > for processing by Surefire? > Let me know > Thanks > Martin -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1074) Should Surefire-api scan InnerClasses for Test Classes
[ https://jira.codehaus.org/browse/SUREFIRE-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358915#comment-358915 ] Tibor Digana edited comment on SUREFIRE-1074 at 12/11/14 4:27 AM: -- Can you check it out with this runner and close this issue? Use plugin dependency surefire-provider junit47. https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/experimental/runners/Enclosed.java was (Author: tibor17): Can you check it out with this runner and close this issue? https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/experimental/runners/Enclosed.java > Should Surefire-api scan InnerClasses for Test Classes > -- > > Key: SUREFIRE-1074 > URL: https://jira.codehaus.org/browse/SUREFIRE-1074 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.16 > Environment: mvn 3.0.5 > surefire-api (all versions) >Reporter: Martin Gainty >Assignee: Tibor Digana > > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite > processes the Directory for > /JasperApplication/target/classes/net/sf/jasperreports/virtualization > 4/09/2014 03:24 PM 2,225 > BaseSerializationTests$SerializationJob.class > //required inner protected static class SerializationJob class was scanned by > AbstractDirectoryTestSuite > 4/09/2014 03:24 PM 3,519 BaseSerializationTests.class > BaseSerializationTests.class Base Test class successfully scanned and > processed by surefire (surefire-api) > Should AbstractDirectoryTestSuite from surefire-api scan inner (Test) classes > for processing by Surefire? > Let me know > Thanks > Martin -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1074) Should Surefire-api scan InnerClasses for Test Classes
[ https://jira.codehaus.org/browse/SUREFIRE-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1074: -- Assignee: Tibor Digana > Should Surefire-api scan InnerClasses for Test Classes > -- > > Key: SUREFIRE-1074 > URL: https://jira.codehaus.org/browse/SUREFIRE-1074 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.16 > Environment: mvn 3.0.5 > surefire-api (all versions) >Reporter: Martin Gainty >Assignee: Tibor Digana > > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite > processes the Directory for > /JasperApplication/target/classes/net/sf/jasperreports/virtualization > 4/09/2014 03:24 PM 2,225 > BaseSerializationTests$SerializationJob.class > //required inner protected static class SerializationJob class was scanned by > AbstractDirectoryTestSuite > 4/09/2014 03:24 PM 3,519 BaseSerializationTests.class > BaseSerializationTests.class Base Test class successfully scanned and > processed by surefire (surefire-api) > Should AbstractDirectoryTestSuite from surefire-api scan inner (Test) classes > for processing by Surefire? > Let me know > Thanks > Martin -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1060) Suppress warning if argLine is set
[
https://jira.codehaus.org/browse/SUREFIRE-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1060.
--
Resolution: Duplicate
Already fixed in 2.18, see https://jira.codehaus.org/browse/SUREFIRE-1053
This behavior already works fine in 2.18:
"If -Dfile.encoding is set as a system property, and it is also set using
argLine then you should suppress this warning because the latter will override
the former."
> Suppress warning if argLine is set
> --
>
> Key: SUREFIRE-1060
> URL: https://jira.codehaus.org/browse/SUREFIRE-1060
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.15
>Reporter: Gili
>
> As a follow-up to SUREFIRE-951, I am getting {{file.encoding cannot be set as
> system property, use -Dfile.encoding=... instead}} in spite
> of the fact that I did set {{file.encoding}} as the warning recommends. If
> {{-Dfile.encoding}} is set as a system property, and it is also set using
> {{argLine}} then you should suppress this warning because the latter will
> override the former.
> I don't have the ability to remove -Dfile.encoding=...
> because this is added by Netbeans at build-time (they have no way of knowing
> we fork the JVM).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1052) Use "project.build.sourceEncoding"-Property by default for forked jvm
[
https://jira.codehaus.org/browse/SUREFIRE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1052.
--
Resolution: Won't Fix
Using this configuration is fine on Oracle VM, I tried!
-Dfile.encoding=${project.build.sourceEncoding}
We don't need to handle the "sourceEncoding".
We are handling ${project.reporting.outputEncoding} only for Xml reporting but
that's different.
> Use "project.build.sourceEncoding"-Property by default for forked jvm
> -
>
> Key: SUREFIRE-1052
> URL: https://jira.codehaus.org/browse/SUREFIRE-1052
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, Maven Surefire Plugin, process forking
>Affects Versions: 2.10, 2.16
>Reporter: Dieter König
> Attachments: pom.xml, SurefireEncodingTestCase.java
>
>
> maven-surefire-plugin is ignoring "project.build.sourceEncoding"-property
> when forking jvm for testcase execution.
> The attached testcase fails with surefire for a project configured as UTF-8
> but is successful when executed in eclipse.
> Known Workaround:
> Configure surefire in the following way
> -Dfile.encoding=${project.build.sourceEncoding}
> P.S.: Unfortunately the oracle jvm itself is also unsafe. Executing the
> testcase with java.exe (without file.encoding-argument) gives AssertionError,
> executing with javaw.exe (without file.encoding-argument) is successful.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-313) url and name are mandatory for a license but this is not validated
[
https://jira.codehaus.org/browse/MPIR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358919#comment-358919
]
Constantino Cronemberger commented on MPIR-313:
---
OK
> url and name are mandatory for a license but this is not validated
> --
>
> Key: MPIR-313
> URL: https://jira.codehaus.org/browse/MPIR-313
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Constantino Cronemberger
>Assignee: Michael Osipov
>Priority: Minor
> Labels: exception
> Attachments: exception.txt, fix_MPIR-313.patch, pom.xml
>
>
> In an internal project we had a license defined in the pom.xml but without
> url and name.
> This causes an exception which does not say anything about the fact that
> these required elements are missing. See attached file with the complete
> exception.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null! -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-313) url and name are mandatory for a license but this is not validated
[
https://jira.codehaus.org/browse/MPIR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358919#comment-358919
]
Constantino Cronemberger edited comment on MPIR-313 at 12/11/14 5:35 AM:
-
OK. You could also add a counter to the name so they will be unique.
was (Author: ccronemberger):
OK
> url and name are mandatory for a license but this is not validated
> --
>
> Key: MPIR-313
> URL: https://jira.codehaus.org/browse/MPIR-313
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Constantino Cronemberger
>Assignee: Michael Osipov
>Priority: Minor
> Labels: exception
> Attachments: exception.txt, fix_MPIR-313.patch, pom.xml
>
>
> In an internal project we had a license defined in the pom.xml but without
> url and name.
> This causes an exception which does not say anything about the fact that
> these required elements are missing. See attached file with the complete
> exception.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null! -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5733) Repositories from settings.xml are ignored for plugin dependencies
[
https://jira.codehaus.org/browse/MNG-5733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5733.
---
Resolution: Not A Bug
Assignee: Michael Osipov
Your {{settings.xml}} is incomplete. It has to look like this:
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd";>
nexus
*
https://.example.com/nexus
nexus
michael-o
secret
nexus-reroute
central
http://central
true
true
central
http://central
true
true
nexus-reroute
{code}
> Repositories from settings.xml are ignored for plugin dependencies
> --
>
> Key: MNG-5733
> URL: https://jira.codehaus.org/browse/MNG-5733
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.3
> Environment: Apache Maven 3.2.3
> (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T23:58:10+03:00)
> Java version: 1.8.0_25, vendor: Oracle Corporation
> Default locale: ru_RU, platform encoding: UTF-8
> OS name: "linux", version: "3.13.0-40-generic", arch: "amd64", family: "unix"
>Reporter: Dmitry Tsydzik
>Assignee: Michael Osipov
>Priority: Blocker
> Attachments: out.log, pom.xml, settings.xml
>
>
> Maven ignores repositories declared in settings.xml when resolves
> dependencies for plugins
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-313) url and name are mandatory for a license but this is not validated
[
https://jira.codehaus.org/browse/MPIR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358927#comment-358927
]
Michael Osipov commented on MPIR-313:
-
Yes that is true but I would rather prefer the dev would fix that after first
site evaluation.
> url and name are mandatory for a license but this is not validated
> --
>
> Key: MPIR-313
> URL: https://jira.codehaus.org/browse/MPIR-313
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Constantino Cronemberger
>Assignee: Michael Osipov
>Priority: Minor
> Labels: exception
> Attachments: exception.txt, fix_MPIR-313.patch, pom.xml
>
>
> In an internal project we had a license defined in the pom.xml but without
> url and name.
> This causes an exception which does not say anything about the fact that
> these required elements are missing. See attached file with the complete
> exception.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null! -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-742.
Resolution: Fixed
Fixed in r1644101
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-739) directory permissions are not 755 but 000 in zip
[ https://jira.codehaus.org/browse/MASSEMBLY-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-739. Resolution: Fixed Fixed in r1644101, please verify > directory permissions are not 755 but 000 in zip > > > Key: MASSEMBLY-739 > URL: https://jira.codehaus.org/browse/MASSEMBLY-739 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.5.1, 2.5.2 > Environment: Windows XP, cygwin >Reporter: Martin Monsorno >Assignee: Kristian Rosenvold > Fix For: 2.5.3 > > Attachments: assembly-bug.zip > > > Since version 2.5 when creating a zip package and unzip this, the created > directories have a file mode of 000 instead of 755, which should be the > default according to the docs. With version 2.4 the mode is 755. See example > project. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5734) Empty module entry should fail instead of just producing a WARNING
Karl-Heinz Marbaise created MNG-5734:
Summary: Empty module entry should fail instead of just producing
a WARNING
Key: MNG-5734
URL: https://jira.codehaus.org/browse/MNG-5734
Project: Maven
Issue Type: Improvement
Affects Versions: 3.2.3
Reporter: Karl-Heinz Marbaise
Priority: Minor
If you define a list of modules within a multi module build like this:
{code:xml}
...
assembly
shade
{code}
The above will produce a WARNING which should be changed into failing the whole
build cause it simply a wrong definition of a module in the list...
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-391) org.apache.maven.shared.repository.DefaultRepositoryAssembler#findCentralRepository does not understand mirrors
Kristian Rosenvold created MSHARED-391: -- Summary: org.apache.maven.shared.repository.DefaultRepositoryAssembler#findCentralRepository does not understand mirrors Key: MSHARED-391 URL: https://jira.codehaus.org/browse/MSHARED-391 Project: Maven Shared Components Issue Type: Bug Reporter: Kristian Rosenvold The method should search getMirroredRepositories() for mirrors too. Unfortunately this method appeared in 3.0.3, so we need to establish a new minimum to fix this -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-677) NPE using includeMetadata true for repository in a descriptor.
[
https://jira.codehaus.org/browse/MASSEMBLY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MASSEMBLY-677:
-
Fix Version/s: (was: 2.5.3)
> NPE using includeMetadata true for repository in a descriptor.
> --
>
> Key: MASSEMBLY-677
> URL: https://jira.codehaus.org/browse/MASSEMBLY-677
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.4
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200)
> Maven home: /usr/share/maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"
>Reporter: Karl-Heinz Marbaise
> Attachments: assemblies-repository-failure.zip
>
>
> I'm trying to create a repository via Maven assembly plugin and used the
> includeMetadata option. If i use false everything is ok (or just remove
> completely cause false is the default). If i change it to true i got the
> following failure:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles) on
> project dist: Execution make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles)
> on project dist: Execution make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:60)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOfLocalRepositoryMetadata(DefaultArtifactRepository.java:128)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.assembleRepositoryMetadata(DefaultRepositoryAssembler.java:487)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.buildRemoteRepository(DefaultRepositoryAssembler.java:231)
> at
> org.apache.maven.plugin.assembly.archive.phase.RepositoryAssemblyPhase.execute(RepositoryAssemblyPhase.java:99)
> at
> org.apache.ma
[jira] (MASSEMBLY-677) NPE using includeMetadata true for repository in a descriptor.
[
https://jira.codehaus.org/browse/MASSEMBLY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358947#comment-358947
]
Kristian Rosenvold commented on MASSEMBLY-677:
--
This requires MSHARED-391 and a bump to minim maven 3.0.3. Bumped for future
fix.
> NPE using includeMetadata true for repository in a descriptor.
> --
>
> Key: MASSEMBLY-677
> URL: https://jira.codehaus.org/browse/MASSEMBLY-677
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.4
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200)
> Maven home: /usr/share/maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"
>Reporter: Karl-Heinz Marbaise
> Attachments: assemblies-repository-failure.zip
>
>
> I'm trying to create a repository via Maven assembly plugin and used the
> includeMetadata option. If i use false everything is ok (or just remove
> completely cause false is the default). If i change it to true i got the
> following failure:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles) on
> project dist: Execution make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles)
> on project dist: Execution make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:60)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOfLocalRepositoryMetadata(DefaultArtifactRepository.java:128)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.assembleRepositoryMetadata(DefaultRepositoryAssembler.java:487)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.buildRemoteRepository(DefaultRepositoryAssembler.java:231)
> at
> org.apache.maven.plugin.assembly.archiv
[jira] (MASSEMBLY-677) NPE using includeMetadata true for repository in a descriptor.
[
https://jira.codehaus.org/browse/MASSEMBLY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358947#comment-358947
]
Kristian Rosenvold edited comment on MASSEMBLY-677 at 12/11/14 12:31 PM:
-
Root cause is MSHARED-391 and a bump to minim maven 3.0.3. Bumped for future
fix.
was (Author: krosenvold):
This requires MSHARED-391 and a bump to minim maven 3.0.3. Bumped for future
fix.
> NPE using includeMetadata true for repository in a descriptor.
> --
>
> Key: MASSEMBLY-677
> URL: https://jira.codehaus.org/browse/MASSEMBLY-677
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.4
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200)
> Maven home: /usr/share/maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"
>Reporter: Karl-Heinz Marbaise
> Attachments: assemblies-repository-failure.zip
>
>
> I'm trying to create a repository via Maven assembly plugin and used the
> includeMetadata option. If i use false everything is ok (or just remove
> completely cause false is the default). If i change it to true i got the
> following failure:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles) on
> project dist: Execution make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles)
> on project dist: Execution make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:60)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOfLocalRepositoryMetadata(DefaultArtifactRepository.java:128)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.assembleRepositoryMetadata(DefaultRepositoryAssembler.java:487)
> at
> org.apache
[jira] (MASSEMBLY-677) NPE using includeMetadata true for repository in a descriptor.
[
https://jira.codehaus.org/browse/MASSEMBLY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358947#comment-358947
]
Kristian Rosenvold edited comment on MASSEMBLY-677 at 12/11/14 12:31 PM:
-
Root cause is MSHARED-391 and a bump to minimum maven 3.0.3. Bumped for future
fix.
was (Author: krosenvold):
Root cause is MSHARED-391 and a bump to minim maven 3.0.3. Bumped for future
fix.
> NPE using includeMetadata true for repository in a descriptor.
> --
>
> Key: MASSEMBLY-677
> URL: https://jira.codehaus.org/browse/MASSEMBLY-677
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.4
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200)
> Maven home: /usr/share/maven
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"
>Reporter: Karl-Heinz Marbaise
> Attachments: assemblies-repository-failure.zip
>
>
> I'm trying to create a repository via Maven assembly plugin and used the
> includeMetadata option. If i use false everything is ok (or just remove
> completely cause false is the default). If i change it to true i got the
> following failure:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles) on
> project dist: Execution make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles)
> on project dist: Execution make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> make-bundles of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:60)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOfLocalRepositoryMetadata(DefaultArtifactRepository.java:128)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.assembleRepositoryMetadata(DefaultRepositoryAssembler.java:487)
> at
> org.apac
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[ https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Curtis Rueden updated MENFORCER-185: Attachment: seuss.zip mvn validate [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] pom [INFO] green-eggs [INFO] ham [INFO] [INFO] [INFO] Building pom 0.0.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-rules) @ pom --- [INFO] [INFO] [INFO] Building green-eggs 0.0.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-rules) @ green-eggs --- [WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireReleaseDeps failed with message: Parent Cannot be a snapshot: seuss:pom:pom:0.0.0-SNAPSHOT [INFO] [INFO] Reactor Summary: [INFO] [INFO] pom SUCCESS [ 0.462 s] [INFO] green-eggs . FAILURE [ 0.003 s] [INFO] ham SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] > Require Release Dependencies ignorant about aggregator build > > > Key: MENFORCER-185 > URL: https://jira.codehaus.org/browse/MENFORCER-185 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.3.1 >Reporter: Thomas Diesler > Attachments: seuss.zip > > > If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency > on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build. > Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not > allowed even when they belong to the same project and were built during the > same reactor build. > We have a complex project with 100+ modules. I want to enforce that no module > has dependencies on project SNAPSHOTS that were not included in the build. In > such case A would use a stale version of B that happened to be available in > the local/remote maven repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[ https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358949#comment-358949 ] Curtis Rueden commented on MENFORCER-185: - +1. My group's projects also use requireReleaseDeps, which works great for single-module projects. I attached a nearly MCVE for illustration. > Require Release Dependencies ignorant about aggregator build > > > Key: MENFORCER-185 > URL: https://jira.codehaus.org/browse/MENFORCER-185 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.3.1 >Reporter: Thomas Diesler > Attachments: seuss.zip > > > If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency > on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build. > Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not > allowed even when they belong to the same project and were built during the > same reactor build. > We have a complex project with 100+ modules. I want to enforce that no module > has dependencies on project SNAPSHOTS that were not included in the build. In > such case A would use a stale version of B that happened to be available in > the local/remote maven repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[ https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358949#comment-358949 ] Curtis Rueden edited comment on MENFORCER-185 at 12/11/14 1:29 PM: --- +1. My group's projects also use requireReleaseDeps, which works great for single-module projects, but not multi-module ones without hacky exclusions. I attached a nearly MCVE for illustration. was (Author: ctrueden): +1. My group's projects also use requireReleaseDeps, which works great for single-module projects. I attached a nearly MCVE for illustration. > Require Release Dependencies ignorant about aggregator build > > > Key: MENFORCER-185 > URL: https://jira.codehaus.org/browse/MENFORCER-185 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.3.1 >Reporter: Thomas Diesler > Attachments: seuss.zip > > > If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency > on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build. > Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not > allowed even when they belong to the same project and were built during the > same reactor build. > We have a complex project with 100+ modules. I want to enforce that no module > has dependencies on project SNAPSHOTS that were not included in the build. In > such case A would use a stale version of B that happened to be available in > the local/remote maven repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-743) not correct
[
https://jira.codehaus.org/browse/MASSEMBLY-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358955#comment-358955
]
Kristian Rosenvold commented on MASSEMBLY-743:
--
This depends on MODELLO-290, which is fixed in 1.8.3 (just released)
> not correct
> --
>
> Key: MASSEMBLY-743
> URL: https://jira.codehaus.org/browse/MASSEMBLY-743
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.5.2
>Reporter: Jean-Eric Cuendet
>Assignee: Kristian Rosenvold
> Fix For: 2.5.3
>
> Attachments: maven-assembly-bug.tar.gz
>
>
> I use the assembly plugin, with the tag in the
> assembly.xml file. If I put a variable (${mine.includeBaseDirectory}) in the
> tag, it's not taken into account.
> But if I use true or false, that fine.
> I have created a small project that shows the problem. It's attached.
> To reproduce:
> - unzip the attachment
> - cd maven-assembly-bug/
> - mvn clean install assembly:single
> The file maven-assembly-bug-1.0.0-SNAPSHOT.tar.gz doesn't contain the
> baseDir, while the variable used in the tag is set to
> true
> If you change the value in assembly.xml to true or false (instead of using
> the variable), that's worting fine.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1123) TestNg with mulptile suiteXml and reuseForks=false runs tests multiple times
Andreas Gudian created SUREFIRE-1123:
Summary: TestNg with mulptile suiteXml and reuseForks=false runs
tests multiple times
Key: SUREFIRE-1123
URL: https://jira.codehaus.org/browse/SUREFIRE-1123
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.18, 2.17, 2.16, 2.10
Reporter: Andreas Gudian
That happens for quite some time now (tried all versions back to 2.10), but was
uncovered by a fix for SUREFIRE-1122, resulting in the failing IT
{{CheckTestNgSuiteXmlIT.suiteXmlForkModeAlways}}.
When configured with {{n}} suiteXml files and reuseForks=false, all tests (from
all suiteXml files) are executed {{n}} times.
For now, I'm ignoring the failing IT, but we might want to look into this some
time.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1122) When running failsafe with -Dfailsafe.rerunFailingTestsCount and parallel all, the reports are not generated correctly
[ https://jira.codehaus.org/browse/SUREFIRE-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian closed SUREFIRE-1122. Resolution: Fixed Commit is pushed. Roy, you can give 2.19-SNAPSHOT a try, if you like. > When running failsafe with -Dfailsafe.rerunFailingTestsCount and parallel > all, the reports are not generated correctly > -- > > Key: SUREFIRE-1122 > URL: https://jira.codehaus.org/browse/SUREFIRE-1122 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.18 >Reporter: Roy Arnon >Assignee: Andreas Gudian > Fix For: 2.18.1 > > Attachments: invalid.xml, test.zip, valid.xml > > > Hi, > I just tried the new feature -Dfailsafe.rerunFailingTestsCount on our > failsafe build. > Unfortunately, when running the build using parallel=all, it seems the junit > xml files are not generated correctly. > I've tried running it multiple different ways, including classedAndMethods, > and all, but it seems to generate an incorrect xml file either way. > I've attached both files here. > I can provide a pom and java test case if required. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[
https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358959#comment-358959
]
Karl-Heinz Marbaise commented on MENFORCER-185:
---
So first thanks Curtis for your feedback. So after taking a look into that i
found some things we need to mention.
The
[documentation|http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html]
says that by default the {{onlyWhenRelease}} configuration element is set to
{{false}} which means the check will be done always. Furthermore the
documentation also says the default for {{failWhenParentIsSnapshot}}
configuration element is set to {{true}} which means it will check the parent
always. These are the reasons why the example build fails.
I have created a [github
project|https://github.com/khmarbaise/menforcer/tree/master/menforcer-185] with
the above example and enhanced it a little with an dependency to {{ham}} in
{{green-egs}} module but with the wrong version which is not from the current
reactor. The newly implemented rule {{reactorModuleConvergence}} will exactly
show this problem.
{code}
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.ReactorModuleConvergence
failed with message:
Reactor modules contains dependencies which do not reference the reactor.
There is a problem in your reactor.
module: seuss:green-eggs:jar:0.0.0-SNAPSHOT
dependency: seuss:ham:0.0.1-SNAPSHOT
{code}
This is of course not the check for SNAPSHOT dependencies what you like to do.
So this looks to me that we need to (re)implement the
{{requireReleaseDependencies}} rule in a complete different way...cause the doc
stated:
??This rule checks the dependencies and fails if any snapshots are found.??
Based on that i would interpret that in the way to check only the dependencies
and check if they are not part of the reactor to fail.
PS.: The title of the issue is a little bit misleading, cause we are talking
about a multi module build and not about an aggregator build.
> Require Release Dependencies ignorant about aggregator build
>
>
> Key: MENFORCER-185
> URL: https://jira.codehaus.org/browse/MENFORCER-185
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Thomas Diesler
> Attachments: seuss.zip
>
>
> If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency
> on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build.
> Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not
> allowed even when they belong to the same project and were built during the
> same reactor build.
> We have a complex project with 100+ modules. I want to enforce that no module
> has dependencies on project SNAPSHOTS that were not included in the build. In
> such case A would use a stale version of B that happened to be available in
> the local/remote maven repository.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[
https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358960#comment-358960
]
Curtis Rueden commented on MENFORCER-185:
-
Thanks for the quick reply, Karl. I want to clarify that this is a fringe issue
for my group's projects, since we have switched almost completely to
single-module projects in separate Git repositories. We have only a couple of
multi-module projects left that get bitten. That said, I agree with the OP that
if you have a 100-module build, and it is important that it have only release
dependencies outside the reactor, it would be awesome if this rule could
support that use case. My personal tack would be to add another boolean
property {{allowSnapshotsInReactor}} which defaults to {{false}} for backwards
compatibility, but can be set to {{true}} to get the desired behavior.
Looking at the source, I wouldn't think a full rewrite is required, but rather
some case logic carefully injected in a couple of places. For example, in
{{RequireReleaseDeps.java}}, in the {{if ( failWhenParentIsSnapshot )}} block,
do not throw the exception if {{allowSnapshotsInReactor}} is set and the parent
is part of the multi-module build. And in the {{checkDependencies}} method, do
not add the artifact to the {{foundSnapshots}} structure if the artifact is
part of the multi-module build.
I'm certainly no expert on the codebase though, so perhaps it is more
complicated than that.
> Require Release Dependencies ignorant about aggregator build
>
>
> Key: MENFORCER-185
> URL: https://jira.codehaus.org/browse/MENFORCER-185
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Thomas Diesler
> Attachments: seuss.zip
>
>
> If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency
> on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build.
> Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not
> allowed even when they belong to the same project and were built during the
> same reactor build.
> We have a complex project with 100+ modules. I want to enforce that no module
> has dependencies on project SNAPSHOTS that were not included in the build. In
> such case A would use a stale version of B that happened to be available in
> the local/remote maven repository.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-313) License name is mandatory but it is not validated
[
https://jira.codehaus.org/browse/MPIR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-313:
Summary: License name is mandatory but it is not validated (was: url and
name are mandatory for a license but this is not validated)
> License name is mandatory but it is not validated
> -
>
> Key: MPIR-313
> URL: https://jira.codehaus.org/browse/MPIR-313
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Constantino Cronemberger
>Assignee: Michael Osipov
>Priority: Minor
> Labels: exception
> Attachments: exception.txt, fix_MPIR-313.patch, pom.xml
>
>
> In an internal project we had a license defined in the pom.xml but without
> url and name.
> This causes an exception which does not say anything about the fact that
> these required elements are missing. See attached file with the complete
> exception.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null! -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-313) License name is mandatory but it is not validated
[
https://jira.codehaus.org/browse/MPIR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-313:
Fix Version/s: 2.8
> License name is mandatory but it is not validated
> -
>
> Key: MPIR-313
> URL: https://jira.codehaus.org/browse/MPIR-313
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Constantino Cronemberger
>Assignee: Michael Osipov
>Priority: Minor
> Labels: exception
> Fix For: 2.8
>
> Attachments: exception.txt, fix_MPIR-313.patch, pom.xml
>
>
> In an internal project we had a license defined in the pom.xml but without
> url and name.
> This causes an exception which does not say anything about the fact that
> these required elements are missing. See attached file with the complete
> exception.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null! -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-313) License name is mandatory but it is not validated
[
https://jira.codehaus.org/browse/MPIR-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPIR-313.
---
Resolution: Fixed
Fixed with [r1644770|http://svn.apache.org/r1644770].
> License name is mandatory but it is not validated
> -
>
> Key: MPIR-313
> URL: https://jira.codehaus.org/browse/MPIR-313
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Constantino Cronemberger
>Assignee: Michael Osipov
>Priority: Minor
> Labels: exception
> Fix For: 2.8
>
> Attachments: exception.txt, fix_MPIR-313.patch, pom.xml
>
>
> In an internal project we had a license defined in the pom.xml but without
> url and name.
> This causes an exception which does not say anything about the fact that
> these required elements are missing. See attached file with the complete
> exception.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null! -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project jee-util: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Anchor name
> cannot be null!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1084) Surefire-report stack traces appear on a single line.
[
https://jira.codehaus.org/browse/SUREFIRE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358963#comment-358963
]
Ulli Hafner commented on SUREFIRE-1084:
---
I think the Surefire site report does not show new lines for stacktraces *and*
assertion messages. Here is an example project (branch assignments5):
https://github.com/uhafner/karatest/tree/assignments5
When you run {{mvn clean test -Dmaven.test.failure.ignore=true site}} then the
Surefire report shows the assertion message in a single line. Should I provide
a screenshot or is the project sufficient to reproduce?
> Surefire-report stack traces appear on a single line.
> -
>
> Key: SUREFIRE-1084
> URL: https://jira.codehaus.org/browse/SUREFIRE-1084
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Josh Eversmann
>Priority: Minor
> Attachments: Screen Shot 2014-06-30 at 6.40.32 PM.png
>
>
> The tags and line breaks used by SurefireReportGenerator
> .constructFailureDetails do not correctly format the stack trace in the
> generated page.
> Related PR: https://github.com/apache/maven-surefire/pull/41
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[ https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MENFORCER-185: -- Fix Version/s: more-investigation > Require Release Dependencies ignorant about aggregator build > > > Key: MENFORCER-185 > URL: https://jira.codehaus.org/browse/MENFORCER-185 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.3.1 >Reporter: Thomas Diesler > Fix For: more-investigation > > Attachments: seuss.zip > > > If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency > on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build. > Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not > allowed even when they belong to the same project and were built during the > same reactor build. > We have a complex project with 100+ modules. I want to enforce that no module > has dependencies on project SNAPSHOTS that were not included in the build. In > such case A would use a stale version of B that happened to be available in > the local/remote maven repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-319) Apache Ant has not dependency management but Apache Ivy has
[ https://jira.codehaus.org/browse/MPIR-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPIR-319: Fix Version/s: 2.8 > Apache Ant has not dependency management but Apache Ivy has > --- > > Key: MPIR-319 > URL: https://jira.codehaus.org/browse/MPIR-319 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: dependency-info >Affects Versions: 2.7 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 2.8 > > > The dependencies information report shows how to integrate into Apache Ant > but AA does not have any dep mngt which ant Ivy oder Eclipse Aether. Since > the dep snippet refers to Ivy, rename it! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-319) Apache Ant has not dependency management but Apache Ivy has
Michael Osipov created MPIR-319: --- Summary: Apache Ant has not dependency management but Apache Ivy has Key: MPIR-319 URL: https://jira.codehaus.org/browse/MPIR-319 Project: Maven Project Info Reports Plugin Issue Type: Bug Components: dependency-info Affects Versions: 2.7 Reporter: Michael Osipov The dependencies information report shows how to integrate into Apache Ant but AA does not have any dep mngt which ant Ivy oder Eclipse Aether. Since the dep snippet refers to Ivy, rename it! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-319) Apache Ant has not dependency management but Apache Ivy has
[ https://jira.codehaus.org/browse/MPIR-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MPIR-319: --- Assignee: Michael Osipov > Apache Ant has not dependency management but Apache Ivy has > --- > > Key: MPIR-319 > URL: https://jira.codehaus.org/browse/MPIR-319 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: dependency-info >Affects Versions: 2.7 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 2.8 > > > The dependencies information report shows how to integrate into Apache Ant > but AA does not have any dep mngt which ant Ivy oder Eclipse Aether. Since > the dep snippet refers to Ivy, rename it! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-319) Apache Ant has not dependency management but Apache Ivy has
[ https://jira.codehaus.org/browse/MPIR-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-319. --- Resolution: Fixed Fixed with [r1644774|http://svn.apache.org/r1644774]. > Apache Ant has not dependency management but Apache Ivy has > --- > > Key: MPIR-319 > URL: https://jira.codehaus.org/browse/MPIR-319 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: dependency-info >Affects Versions: 2.7 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 2.8 > > > The dependencies information report shows how to integrate into Apache Ant > but AA does not have any dep mngt which ant Ivy oder Eclipse Aether. Since > the dep snippet refers to Ivy, rename it! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-320) AbstractMavenReportRenderer#applyPattern(String) chokes on some specific input and produces useless segments
Michael Osipov created MPIR-320:
---
Summary: AbstractMavenReportRenderer#applyPattern(String) chokes
on some specific input and produces useless segments
Key: MPIR-320
URL: https://jira.codehaus.org/browse/MPIR-320
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.7
Reporter: Michael Osipov
Consider this input:
{noformat}
{Indiana University Extreme! Lab Software License, vesion
1.1.1,http://www.extreme.indiana.edu/viewcvs/~checkout~/XPP3/java/LICENSE.txt}{Public
Domain,http://creativecommons.org/licenses/publicdomain}{Apache Software
License, version 1.1,http://www.apache.org/licenses/LICENSE-1.1}
{noformat}
It should be broken up into six segments. The output of {{applyPattern}} is:
{noformat}
[0] "Indiana University Extreme! Lab Software License, vesion 1.1.1"
(id=321)
[1]
"http://www.extreme.indiana.edu/viewcvs/~checkout~/XPP3/java/LICENSE.txt";
(id=322)
[2] "" (id=323)
[3] null
[4] "Public Domain" (id=324)
[5] "http://creativecommons.org/licenses/publicdomain"; (id=325)
[6] "" (id=326)
[7] null
[8] "Apache Software License, version 1.1" (id=328)
[9] "http://www.apache.org/licenses/LICENSE-1.1"; (id=329)
{noformat}
and the output is incorrectly generated.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-392) AbstractMavenReportRenderer#applyPattern(String) chokes on some specific input and produces useless segments
[
https://jira.codehaus.org/browse/MSHARED-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MPIR-320 to MSHARED-392:
-
Component/s: (was: dependencies)
maven-reporting-impl
Affects Version/s: (was: 2.7)
maven-reporting-impl-2.3
Key: MSHARED-392 (was: MPIR-320)
Project: Maven Shared Components (was: Maven Project Info
Reports Plugin)
> AbstractMavenReportRenderer#applyPattern(String) chokes on some specific
> input and produces useless segments
>
>
> Key: MSHARED-392
> URL: https://jira.codehaus.org/browse/MSHARED-392
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-2.3
>Reporter: Michael Osipov
>
> Consider this input:
> {noformat}
> {Indiana University Extreme! Lab Software License, vesion
> 1.1.1,http://www.extreme.indiana.edu/viewcvs/~checkout~/XPP3/java/LICENSE.txt}{Public
> Domain,http://creativecommons.org/licenses/publicdomain}{Apache Software
> License, version 1.1,http://www.apache.org/licenses/LICENSE-1.1}
> {noformat}
> It should be broken up into six segments. The output of {{applyPattern}} is:
> {noformat}
> [0] "Indiana University Extreme! Lab Software License, vesion 1.1.1"
> (id=321)
> [1]
> "http://www.extreme.indiana.edu/viewcvs/~checkout~/XPP3/java/LICENSE.txt";
> (id=322)
> [2] "" (id=323)
> [3] null
> [4] "Public Domain" (id=324)
> [5] "http://creativecommons.org/licenses/publicdomain"; (id=325)
> [6] "" (id=326)
> [7] null
> [8] "Apache Software License, version 1.1" (id=328)
> [9] "http://www.apache.org/licenses/LICENSE-1.1"; (id=329)
> {noformat}
> and the output is incorrectly generated.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-393) AbstractMavenReportRenderer#linkPatternedText does not apply use join string
Michael Osipov created MSHARED-393:
--
Summary: AbstractMavenReportRenderer#linkPatternedText does not
apply use join string
Key: MSHARED-393
URL: https://jira.codehaus.org/browse/MSHARED-393
Project: Maven Shared Components
Issue Type: Bug
Components: maven-reporting-impl
Affects Versions: maven-reporting-impl-2.3
Reporter: Michael Osipov
While traversing the linkable segments, the code should check whether there is
following element and add a joiner string like {{, }}. Otherwise the output is
unreadable.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-393) AbstractMavenReportRenderer#linkPatternedText does not use any join string
[
https://jira.codehaus.org/browse/MSHARED-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-393:
---
Description: While traversing the linkable segments, the code should check
whether there is a next element and add a join string like {{, }}. Otherwise
the output is unreadable. (was: While traversing the linkable segments, the
code should check whether there is following element and add a joiner string
like {{, }}. Otherwise the output is unreadable.)
> AbstractMavenReportRenderer#linkPatternedText does not use any join string
> --
>
> Key: MSHARED-393
> URL: https://jira.codehaus.org/browse/MSHARED-393
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-2.3
>Reporter: Michael Osipov
>
> While traversing the linkable segments, the code should check whether there
> is a next element and add a join string like {{, }}. Otherwise the output is
> unreadable.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-393) AbstractMavenReportRenderer#linkPatternedText does not use any join string
[
https://jira.codehaus.org/browse/MSHARED-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-393:
---
Summary: AbstractMavenReportRenderer#linkPatternedText does not use any
join string (was: AbstractMavenReportRenderer#linkPatternedText does not apply
use join string)
> AbstractMavenReportRenderer#linkPatternedText does not use any join string
> --
>
> Key: MSHARED-393
> URL: https://jira.codehaus.org/browse/MSHARED-393
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-2.3
>Reporter: Michael Osipov
>
> While traversing the linkable segments, the code should check whether there
> is following element and add a joiner string like {{, }}. Otherwise the
> output is unreadable.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-261) Upgrade to Checkstyle 6.1
[ https://jira.codehaus.org/browse/MCHECKSTYLE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358970#comment-358970 ] Roman Ivanov commented on MCHECKSTYLE-261: -- checkstyle 6.1.1 was released 2 weeks ago, please use 6.1.1 > Upgrade to Checkstyle 6.1 > - > > Key: MCHECKSTYLE-261 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-261 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.14 >Reporter: Dennis Lundberg > Fix For: 2.15 > > > Upgrade to the latest 6.x version of Checkstyle, which at the time of writing > is 6.1. > Note that this upgrade will make the Checkstyle plugin require Java 6, > because Checkstyle requires Java 6 since version 6.0. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-253) Upgrade to checkstyle 5.9 for Java 8 compatibility
[ https://jira.codehaus.org/browse/MCHECKSTYLE-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358969#comment-358969 ] Roman Ivanov commented on MCHECKSTYLE-253: -- attention: Checkstyle 6.2 will be compiled base on java7, so 6.1.1 is latest binaries based on java6. > Upgrade to checkstyle 5.9 for Java 8 compatibility > -- > > Key: MCHECKSTYLE-253 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-253 > Project: Maven Checkstyle Plugin > Issue Type: New Feature >Reporter: Zlika >Assignee: Mirko Friedenhagen > Fix For: 2.14 > > > Checkstyle 5.9 has just been released and adds support for Java 8. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-349) Strange behaviour for github-report
Tigran Tchougourian created MCHANGES-349:
Summary: Strange behaviour for github-report
Key: MCHANGES-349
URL: https://jira.codehaus.org/browse/MCHANGES-349
Project: Maven Changes Plugin
Issue Type: Bug
Components: changes.xml, github
Affects Versions: 2.11
Environment: tested on Mac with maven 3.2.3
tested on Win8 with maven 3.2.3
Reporter: Tigran Tchougourian
Hello,
According to the documentation :
http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
I can write this
{code:xml:Title="pom.xml"}
...
GitHub
https://github.com/NargiT/random-media/issues
...
{code}
But when I run {code:xml}$ mvn site{code} the report : changes-report do not
handle issues correctly from the changes.xml
{code:xml|Title="pom.xml"}
...
org.apache.maven.plugins
maven-changes-plugin
2.11
changes-report
github-report
...
{code}
{code:xml|Title="changes.xml"}
...
...
{code}
Instead to generate
*{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
changes-report.html generates
*{color:red}https://github.com/NargiT/random-media/1{color}*
If I add an extra ' */* ' at the end, it solve my problem.
{code:xml}
GitHub
https://github.com/NargiT/random-media/issues/
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-349) Strange behaviour for github-report
[
https://jira.codehaus.org/browse/MCHANGES-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tigran Tchougourian updated MCHANGES-349:
-
Issue Type: Task (was: Bug)
> Strange behaviour for github-report
> ---
>
> Key: MCHANGES-349
> URL: https://jira.codehaus.org/browse/MCHANGES-349
> Project: Maven Changes Plugin
> Issue Type: Task
> Components: changes.xml, github
>Affects Versions: 2.11
> Environment: tested on Mac with maven 3.2.3
> tested on Win8 with maven 3.2.3
>Reporter: Tigran Tchougourian
>
> Hello,
> According to the documentation :
> http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
> I can write this
> {code:xml:Title="pom.xml"}
> ...
>
> GitHub
> https://github.com/NargiT/random-media/issues
>
> ...
> {code}
> But when I run {code:xml}$ mvn site{code} the report : changes-report do not
> handle issues correctly from the changes.xml
> {code:xml|Title="pom.xml"}
> ...
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.11
>
>
>
> changes-report
> github-report
>
>
>
>
>
> ...
> {code}
> {code:xml|Title="changes.xml"}
> ...
>
>
>
>
>
> ...
> {code}
> Instead to generate
> *{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
> changes-report.html generates
> *{color:red}https://github.com/NargiT/random-media/1{color}*
> If I add an extra ' */* ' at the end, it solve my problem.
> {code:xml}
>
> GitHub
> https://github.com/NargiT/random-media/issues/
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-349) Strange behaviour for github-report
[
https://jira.codehaus.org/browse/MCHANGES-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tigran Tchougourian updated MCHANGES-349:
-
Priority: Minor (was: Major)
> Strange behaviour for github-report
> ---
>
> Key: MCHANGES-349
> URL: https://jira.codehaus.org/browse/MCHANGES-349
> Project: Maven Changes Plugin
> Issue Type: Task
> Components: changes.xml, github
>Affects Versions: 2.11
> Environment: tested on Mac with maven 3.2.3
> tested on Win8 with maven 3.2.3
>Reporter: Tigran Tchougourian
>Priority: Minor
>
> Hello,
> According to the documentation :
> http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
> I can write this
> {code:xml:Title="pom.xml"}
> ...
>
> GitHub
> https://github.com/NargiT/random-media/issues
>
> ...
> {code}
> But when I run {code:xml}$ mvn site{code} the report : changes-report do not
> handle issues correctly from the changes.xml
> {code:xml|Title="pom.xml"}
> ...
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.11
>
>
>
> changes-report
> github-report
>
>
>
>
>
> ...
> {code}
> {code:xml|Title="changes.xml"}
> ...
>
>
>
>
>
> ...
> {code}
> Instead to generate
> *{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
> changes-report.html generates
> *{color:red}https://github.com/NargiT/random-media/1{color}*
> If I add an extra ' */* ' at the end, it solve my problem.
> {code:xml}
>
> GitHub
> https://github.com/NargiT/random-media/issues/
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-349) Strange behaviour for github-report
[
https://jira.codehaus.org/browse/MCHANGES-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tigran Tchougourian updated MCHANGES-349:
-
Description:
Hello,
According to the documentation :
http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
I can write this
{code:xml:Title="pom.xml"}
...
GitHub
https://github.com/NargiT/random-media/issues
...
{code}
But when I run {code:xml}$ mvn site{code} the report : changes-report do not
handle issues correctly from the changes.xml
{code:xml|Title="pom.xml"}
...
org.apache.maven.plugins
maven-changes-plugin
2.11
changes-report
github-report
...
{code}
{code:xml|Title="changes.xml"}
...
...
{code}
Instead to generate
*{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
changes-report.html generates *https://github.com/NargiT/random-media/1*
If I add an extra ' */* ' at the end, it solve my problem.
{code:xml}
GitHub
https://github.com/NargiT/random-media/issues/
{code}
was:
Hello,
According to the documentation :
http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
I can write this
{code:xml:Title="pom.xml"}
...
GitHub
https://github.com/NargiT/random-media/issues
...
{code}
But when I run {code:xml}$ mvn site{code} the report : changes-report do not
handle issues correctly from the changes.xml
{code:xml|Title="pom.xml"}
...
org.apache.maven.plugins
maven-changes-plugin
2.11
changes-report
github-report
...
{code}
{code:xml|Title="changes.xml"}
...
...
{code}
Instead to generate
*{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
changes-report.html generates
*{color:red}https://github.com/NargiT/random-media/1{color}*
If I add an extra ' */* ' at the end, it solve my problem.
{code:xml}
GitHub
https://github.com/NargiT/random-media/issues/
{code}
> Strange behaviour for github-report
> ---
>
> Key: MCHANGES-349
> URL: https://jira.codehaus.org/browse/MCHANGES-349
> Project: Maven Changes Plugin
> Issue Type: Task
> Components: changes.xml, github
>Affects Versions: 2.11
> Environment: tested on Mac with maven 3.2.3
> tested on Win8 with maven 3.2.3
>Reporter: Tigran Tchougourian
>Priority: Minor
>
> Hello,
> According to the documentation :
> http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
> I can write this
> {code:xml:Title="pom.xml"}
> ...
>
> GitHub
> https://github.com/NargiT/random-media/issues
>
> ...
> {code}
> But when I run {code:xml}$ mvn site{code} the report : changes-report do not
> handle issues correctly from the changes.xml
> {code:xml|Title="pom.xml"}
> ...
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.11
>
>
>
> changes-report
> github-report
>
>
>
>
>
> ...
> {code}
> {code:xml|Title="changes.xml"}
> ...
>
>
>
>
>
> ...
> {code}
> Instead to generate
> *{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
> changes-report.html generates *https://github.com/NargiT/random-media/1*
> If I add an extra ' */* ' at the end, it solve my problem.
> {code:xml}
>
> GitHub
> https://github.com/NargiT/random-media/issues/
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-349) Strange behaviour for issueManagement url on github
[
https://jira.codehaus.org/browse/MCHANGES-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tigran Tchougourian updated MCHANGES-349:
-
Summary: Strange behaviour for issueManagement url on github (was: Strange
behaviour for github-report)
> Strange behaviour for issueManagement url on github
> ---
>
> Key: MCHANGES-349
> URL: https://jira.codehaus.org/browse/MCHANGES-349
> Project: Maven Changes Plugin
> Issue Type: Task
> Components: changes.xml, github
>Affects Versions: 2.11
> Environment: tested on Mac with maven 3.2.3
> tested on Win8 with maven 3.2.3
>Reporter: Tigran Tchougourian
>Priority: Minor
>
> Hello,
> According to the documentation :
> http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
> I can write this
> {code:xml:Title="pom.xml"}
> ...
>
> GitHub
> https://github.com/NargiT/random-media/issues
>
> ...
> {code}
> But when I run {code:xml}$ mvn site{code} the report : changes-report do not
> handle issues correctly from the changes.xml
> {code:xml|Title="pom.xml"}
> ...
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.11
>
>
>
> changes-report
> github-report
>
>
>
>
>
> ...
> {code}
> {code:xml|Title="changes.xml"}
> ...
>
>
>
>
>
> ...
> {code}
> Instead to generate
> *{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
> changes-report.html generates https://github.com/NargiT/random-media/1
> If I add an extra ' */* ' at the end, it solve my problem.
> {code:xml}
>
> GitHub
> https://github.com/NargiT/random-media/issues/
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-349) Strange behaviour for github-report
[
https://jira.codehaus.org/browse/MCHANGES-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tigran Tchougourian updated MCHANGES-349:
-
Description:
Hello,
According to the documentation :
http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
I can write this
{code:xml:Title="pom.xml"}
...
GitHub
https://github.com/NargiT/random-media/issues
...
{code}
But when I run {code:xml}$ mvn site{code} the report : changes-report do not
handle issues correctly from the changes.xml
{code:xml|Title="pom.xml"}
...
org.apache.maven.plugins
maven-changes-plugin
2.11
changes-report
github-report
...
{code}
{code:xml|Title="changes.xml"}
...
...
{code}
Instead to generate
*{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
changes-report.html generates https://github.com/NargiT/random-media/1
If I add an extra ' */* ' at the end, it solve my problem.
{code:xml}
GitHub
https://github.com/NargiT/random-media/issues/
{code}
was:
Hello,
According to the documentation :
http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
I can write this
{code:xml:Title="pom.xml"}
...
GitHub
https://github.com/NargiT/random-media/issues
...
{code}
But when I run {code:xml}$ mvn site{code} the report : changes-report do not
handle issues correctly from the changes.xml
{code:xml|Title="pom.xml"}
...
org.apache.maven.plugins
maven-changes-plugin
2.11
changes-report
github-report
...
{code}
{code:xml|Title="changes.xml"}
...
...
{code}
Instead to generate
*{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
changes-report.html generates *https://github.com/NargiT/random-media/1*
If I add an extra ' */* ' at the end, it solve my problem.
{code:xml}
GitHub
https://github.com/NargiT/random-media/issues/
{code}
> Strange behaviour for github-report
> ---
>
> Key: MCHANGES-349
> URL: https://jira.codehaus.org/browse/MCHANGES-349
> Project: Maven Changes Plugin
> Issue Type: Task
> Components: changes.xml, github
>Affects Versions: 2.11
> Environment: tested on Mac with maven 3.2.3
> tested on Win8 with maven 3.2.3
>Reporter: Tigran Tchougourian
>Priority: Minor
>
> Hello,
> According to the documentation :
> http://maven.apache.org/plugins/maven-changes-plugin/usage.html#How_to_Generate_the_GitHub_Report
> I can write this
> {code:xml:Title="pom.xml"}
> ...
>
> GitHub
> https://github.com/NargiT/random-media/issues
>
> ...
> {code}
> But when I run {code:xml}$ mvn site{code} the report : changes-report do not
> handle issues correctly from the changes.xml
> {code:xml|Title="pom.xml"}
> ...
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.11
>
>
>
> changes-report
> github-report
>
>
>
>
>
> ...
> {code}
> {code:xml|Title="changes.xml"}
> ...
>
>
>
>
>
> ...
> {code}
> Instead to generate
> *{color:green}https://github.com/NargiT/random-media/issues/1{color}*,
> changes-report.html generates https://github.com/NargiT/random-media/1
> If I add an extra ' */* ' at the end, it solve my problem.
> {code:xml}
>
> GitHub
> https://github.com/NargiT/random-media/issues/
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-771) release:prepare tries to push tag with invalid Git URL
[
https://jira.codehaus.org/browse/MRELEASE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358972#comment-358972
]
reda abdi commented on MRELEASE-771:
Hello,
This is still happening in version 2.5.1
> release:prepare tries to push tag with invalid Git URL
> --
>
> Key: MRELEASE-771
> URL: https://jira.codehaus.org/browse/MRELEASE-771
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git, prepare, scm
>Affects Versions: 2.3.1
> Environment: Debian 6, run form shell
>Reporter: Tuukka Mustonen
>
> Suddenly, after no version change of maven-release-plugin, our
> {{release:prepare}} started to fail into:
> {noformat}
> [INFO] Unable to tag SCM
> Provider message:
> The git-push command failed.
> Command output:
> ssh: Could not resolve hostname : Name or service not known
> fatal: The remote end hung up unexpectedly
> {noformat}
> The reason appears to be that pushing of the tag uses invalid syntax for git
> command:
> {noformat}
> [INFO] Executing: /bin/sh -c cd "/jenkins/job1" && git push
> ssh://g...@github.mydomain.com myproduct-1.0.0
> {noformat}
> The problem here is that the target URL ({{ssh://g...@github.mydomain.com}})
> is lacking the actual repository identifier
> ({{/MyOrganization/myproduct.git}}) - the plugin is using just
> {{ssh://g...@github.mydomain.com}} while it should be using something like
> {{ssh://g...@github.mydomain.com/MyOrganization/myproduct.git}}.
> I cannot come up with a reason why it started to do this so I cannot give
> instructions on to how to reproduce it either. For us, it occurs in one
> repository, while in another one using the same plugin version and
> configuration the problem doesn't occur.
> Apparently the behavior of using ssh-URL instead of {{origin}} as remote
> repository has been there for ages, added in SCM-498.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5686) mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
[
https://jira.codehaus.org/browse/MNG-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358973#comment-358973
]
Jonathan Sailor commented on MNG-5686:
--
@Chris, huh, I guess I remembered the -L/-h backwards. Are you ok with editing
the patch before commit, or should I upload a modified version?
> mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
> ---
>
> Key: MNG-5686
> URL: https://jira.codehaus.org/browse/MNG-5686
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.3
> Environment: Mac OS X 10.9.4
>Reporter: Takayoshi Fujiki
> Attachments: 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.patch,
> 0002-MNG-5686-detect-JAVA_HOME-on-newer-OSX-again.patch, maven-bin-mvn.patch
>
>
> From 3.2.3, mvn cannot start and outputs the following error.
> {code}
> $ ./apache-maven-3.2.3/bin/mvn -version
> Error: JAVA_HOME is not defined correctly.
> We cannot execute /usr/libexec/java_home/bin/java
> {code}
> 3.2.2 doesn't have this problem.
> {code}
> $ ./apache-maven-3.2.2/bin/mvn -version
> Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
> 2014-06-17T22:51:42+09:00)
> Maven home: /Users/xxx/tmp/apache-maven-3.2.2
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> {code}
> When I modified {{bin/mvn}} like the following, this problem was gone.
> {code}
> --- bin/mvn.orig 2014-09-10 03:33:52.0 +0900
> +++ bin/mvn 2014-09-10 03:34:18.0 +0900
> @@ -83,7 +83,7 @@
> #
> # Apple JDKs
> #
> - export JAVA_HOME=/usr/libexec/java_home
> + export JAVA_HOME="`/usr/libexec/java_home`"
> fi
> ;;
> esac
> {code}
> Maybe MNG-5658 is related to this problem. {{/usr/libexec/java_home}} is a
> command([java_home(1)|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man1/java_home.1.html]),
> and {{$(command)}} is a style of [Command
> Substitution|http://www.tldp.org/LDP/abs/html/commandsub.html] (Another(old)
> style is {{`command`}}).
> So removing "$()" breaks the JAVA_HOME detection on OS X.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
