[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}
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
excludes
excludeenvSpecific/**/*/exclude
/excludes
/resource
resource
directory${basedir}/src/main/resources/envSpecific/${env}/directory
filteringtrue/filtering
includes
include**/*/include
/includes
/resource
/resources
{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-tabpanelfocusedCommentId=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}
...
build
resources
resource
directorysrc/main/java/directory
filteringtrue/filtering
targetPath../filtered-sources/java/targetPath
/resource
resource
directorysrc/main/resources/directory
filteringtrue/filtering
excludes
exclude**/persistence-test.xml/exclude
/excludes
/resource
/resources
sourceDirectorytarget/filtered-sources/java/sourceDirectory
...
{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-tabpanelfocusedCommentId=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 information about what threw the
{{IOException}} and why. (Or if the wrapper exception does not follow the
convention of
[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-tabpanelfocusedCommentId=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.
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
version1.7/version
inheritedfalse/inherited
executions
execution
idmerge-maps/id
phasepackage/phase
goals
goalrun/goal
/goals
configuration
target
dependencyfilesets scopes=compile types=map/
property name=map_files
refid=maven.project.dependencies/
echo message=merging map files: ${map_files}/
concat destfile=merged.map fixlastline=yes
fileset refid=maven.project.dependencies/
/concat
/target
/configuration
/execution
/executions
/plugin
/plugins
/build
dependencies
!--
dependency
groupIdorg.maring/groupId
artifactIdmap-a/artifactId
version1.0.0-SNAPSHOT/version
typemap/type
classifierobf/classifier
scopecompile/scope
/dependency
dependency
groupIdorg.maring/groupId
artifactIdmap-b/artifactId
version1.0.0-SNAPSHOT/version
typemap/type
classifierobf/classifier
scopecompile/scope
optionaltrue/optional
/dependency
--
/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): scp 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 ...scp 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.
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
version1.7/version
inheritedfalse/inherited
executions
execution
idmerge-maps/id
phasepackage/phase
goals
goalrun/goal
/goals
configuration
target
dependencyfilesets scopes=compile types=map/
property name=map_files
refid=maven.project.dependencies/
echo message=merging map files: ${map_files}/
concat destfile=merged.map fixlastline=yes
fileset refid=maven.project.dependencies/
/concat
/target
/configuration
/execution
/executions
/plugin
/plugins
/build
dependencies
!--
dependency
groupIdorg.maring/groupId
artifactIdmap-a/artifactId
version1.0.0-SNAPSHOT/version
typemap/type
classifierobf/classifier
scopecompile/scope
/dependency
dependency
groupIdorg.maring/groupId
artifactIdmap-b/artifactId
version1.0.0-SNAPSHOT/version
typemap/type
classifierobf/classifier
scopecompile/scope
optionaltrue/optional
/dependency
--
/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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 argLine-Dfile.encoding=...argLine 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 argLine-Dfile.encoding=...argLine
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!
configurationargLine-Dfile.encoding=${project.build.sourceEncoding}/argLine/configuration
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
configurationargLine-Dfile.encoding=${project.build.sourceEncoding}/argLine/configuration
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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}
settings xmlns=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;
mirrors
mirror
idnexus/id
mirrorOf*/mirrorOf
urlhttps://.example.com/nexus/url
/mirror
/mirrors
servers
server
idnexus/id
usernamemichael-o/username
passwordsecret/password
/server
/servers
profiles
profile
idnexus-reroute/id
repositories
repository
idcentral/id
urlhttp://central/url
releases
enabledtrue/enabled
/releases
snapshots
enabledtrue/enabled
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idcentral/id
urlhttp://central/url
releases
enabledtrue/enabled
/releases
snapshots
enabledtrue/enabled
/snapshots
/pluginRepository
/pluginRepositories
/profile
/profiles
activeProfiles
activeProfilenexus-reroute/activeProfile
/activeProfiles
/settings
{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-tabpanelfocusedCommentId=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.init(ZipFile.java:211)
org.apache.commons.compress.archivers.zip.ZipFile.init(ZipFile.java:193)
org.apache.commons.compress.archivers.zip.ZipFile.init(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}
modules
...
moduleassembly/module
moduleshade/module
module/module
/modules
{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
[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-tabpanelfocusedCommentId=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.archive.phase.RepositoryAssemblyPhase.execute(RepositoryAssemblyPhase.java:99)
at
[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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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) includeBaseDirectory not correct
[
https://jira.codehaus.org/browse/MASSEMBLY-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358955#comment-358955
]
Kristian Rosenvold commented on MASSEMBLY-743:
--
This depends on MODELLO-290, which is fixed in 1.8.3 (just released)
includeBaseDirectory 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 includeBaseDirectory 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 includeBaseDirectory 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 pre 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
/reportSet
/reportSets
/plugin
/plugins
...
{code}
{code:xml|Title=changes.xml}
...
release version=0.0.1 date=2014-12-11 description=First release
action dev=nargit type=add
fixes issue=1 /
/action
/release
...
{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}
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues//url
/issueManagement
{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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
/reportSet
/reportSets
/plugin
/plugins
...
{code}
{code:xml|Title=changes.xml}
...
release version=0.0.1 date=2014-12-11 description=First release
action dev=nargit type=add
fixes issue=1 /
/action
/release
...
{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}
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues//url
/issueManagement
{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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
/reportSet
/reportSets
/plugin
/plugins
...
{code}
{code:xml|Title=changes.xml}
...
release version=0.0.1 date=2014-12-11 description=First release
action dev=nargit type=add
fixes issue=1 /
/action
/release
...
{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}
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues//url
/issueManagement
{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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
/reportSet
/reportSets
/plugin
/plugins
...
{code}
{code:xml|Title=changes.xml}
...
release version=0.0.1 date=2014-12-11 description=First release
action dev=nargit type=add
fixes issue=1 /
/action
/release
...
{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}
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues//url
/issueManagement
{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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
/reportSet
/reportSets
/plugin
/plugins
...
{code}
{code:xml|Title=changes.xml}
...
release version=0.0.1 date=2014-12-11 description=First release
action dev=nargit type=add
fixes issue=1 /
/action
/release
...
{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}
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues//url
/issueManagement
{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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
[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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
/reportSet
/reportSets
/plugin
/plugins
...
{code}
{code:xml|Title=changes.xml}
...
release version=0.0.1 date=2014-12-11 description=First release
action dev=nargit type=add
fixes issue=1 /
/action
/release
...
{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}
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues//url
/issueManagement
{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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
/reportSet
/reportSets
/plugin
/plugins
...
{code}
{code:xml|Title=changes.xml}
...
release version=0.0.1 date=2014-12-11 description=First release
action dev=nargit type=add
fixes issue=1 /
/action
/release
...
{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}
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues//url
/issueManagement
{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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
/reportSet
/reportSets
/plugin
/plugins
...
{code}
{code:xml|Title=changes.xml}
...
release version=0.0.1 date=2014-12-11 description=First release
action dev=nargit type=add
fixes issue=1 /
/action
/release
...
{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}
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues//url
/issueManagement
{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}
...
issueManagement
systemGitHub/system
urlhttps://github.com/NargiT/random-media/issues/url
/issueManagement
...
{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}
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version2.11/version
reportSets
reportSet
reports
reportchanges-report/report
reportgithub-report/report
/reports
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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)
