date:20141113


 [ 
https://jira.codehaus.org/browse/SUREFIRE-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-1085.
--

Resolution: Not A Bug

 Documentation incorrect for running single integration test
 ---

 Key: SUREFIRE-1085
 URL: https://jira.codehaus.org/browse/SUREFIRE-1085
 Project: Maven Surefire
  Issue Type: Improvement
  Components: documentation
Affects Versions: 2.12
Reporter: Karsten Ohme
Assignee: Tibor Digana
Priority: Minor

 The online documentation for Failsafe which describes [Running a Single 
 Test|http://maven.apache.org/plugins/maven-failsafe-plugin/examples/single-test.html]
  shows:
 bq.mvn -Dit.test=ITCircle verify
 The it.test parameter does not seem to work. Rather, the same parameter as 
 Surefire (-Dtest=foo) appears to also work for Failsafe.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-859) Exception in thread TreadedStreamConsumer java.lang.RuntimeException during GC

2014-11-13 Thread Mag Hoehme (JIRA)

[
https://jira.codehaus.org/browse/SUREFIRE-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356055#comment-356055
]

Mag Hoehme edited comment on SUREFIRE-859 at 11/13/14 2:39 AM:
---

Thanks for fixing the problem. However, the setup in which the exception was
originally thrown is no longer in available to me.

was (Author: mag):
The setup in which the exception was originally thrown is no longer available.

Exception in thread TreadedStreamConsumer java.lang.RuntimeException during
GC

Key: SUREFIRE-859
URL: https://jira.codehaus.org/browse/SUREFIRE-859
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin,
process forking
Affects Versions: 2.11, 2.12
Environment: Solaris 5.10, jdk16-1.6.0_11-0 (same with jdk1.5.0_14),
apache-maven-2.2.1
Reporter: Mag Hoehme
Assignee: Tibor Digana
Fix For: 2.19

Attachments: runtimeexception.txt

When executing 151 integration tests with 829 test methods on a Solaris
machine, there is an exception:
===
Exception in thread ThreadStreamConsumer java.lang.RuntimeException: 176:
[GC 100,177: [ParNew
...
java.langh.RuntimeException: The forked VM terminated without saying properly
goodbye. VM crash or System.exit called ?
===
(see attachment for full stack traces)
The message of the RuntimeException suggests that the problem is connected to
garbage collection. The stack trace points to ForkClient.java. It looks as if
the method consumeLine in ForkClient.java is fed with GC information
instead of the expected string.
The exception occurs with concurrency configuration parallel='none' as well
as with parallel='classes' in both versions of the surefire plugin, 2.11
and 2.12.
However, this problem does not show up on a Windows/Cygwin environment.

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-279) Wrong hyperlinks on index and modules page

2014-11-13 Thread Grzegorz Slowikowski (JIRA)


[ 
https://jira.codehaus.org/browse/MPIR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356056#comment-356056
 ] 

Grzegorz Slowikowski commented on MPIR-279:
---

First of all add:
{code:java}
this.localRepository = localRepository;
{code}
to ModulesRenderer's constructor.

This solves NPE, but then I have another exception.
{code}
testReport(org.apache.maven.report.projectinfo.ModulesReportTest)  Time 
elapsed: 1.25 sec   ERROR!
java.lang.IllegalStateException: Unable to read local module POM
at 
org.apache.maven.report.projectinfo.ModulesReport$ModulesRenderer.renderBody(ModulesReport.java:140)
at 
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:83)
at 
org.apache.maven.report.projectinfo.ModulesReport.executeReport(ModulesReport.java:56)
at 
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
at 
org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute(AbstractProjectInfoReport.java:223)
at 
org.apache.maven.report.projectinfo.AbstractProjectInfoTestCase.generateReport(AbstractProjectInfoTestCase.java:198)
at 
org.apache.maven.report.projectinfo.AbstractProjectInfoTestCase.generateReport(AbstractProjectInfoTestCase.java:182)
at 
org.apache.maven.report.projectinfo.ModulesReportTest.testReport(ModulesReportTest.java:50)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find 
parent: org.apache.maven.plugin.projectinfo.tests:dependency-convergence for 
project: org.apache.maven.plugin.projectinfo.tests:project1:jar:1.0-SNAPSHOT 
for project org.apache.maven.plugin.projectinfo.tests:project1:jar:1.0-SNAPSHOT
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1396)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:823)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:217)
at 
org.apache.maven.report.projectinfo.ModulesReport$ModulesRenderer.renderBody(ModulesReport.java:136)
... 58 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM 
'org.apache.maven.plugin.projectinfo.tests:dependency-convergence' not found in 
repository: Unable to download the artifact from any repository

  
org.apache.maven.plugin.projectinfo.tests:dependency-convergence:pom:1.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

 for project org.apache.maven.plugin.projectinfo.tests:dependency-convergence
at 
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:605)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1392)
... 62 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable 
to download the artifact from any repository

  
org.apache.maven.plugin.projectinfo.tests:dependency-convergence:pom:1.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)


at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:228)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:558)
... 63 more
Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to 
download the artifact from any repository
at 
org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:404)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:216)
... 65 more
{code}

 Wrong hyperlinks on index and modules page
 --

 Key: MPIR-279
 URL: https://jira.codehaus.org/browse/MPIR-279
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: modules
Affects Versions: 2.7
Reporter: Stephen Colebourne
Assignee: Michael Osipov
 Attachments: OG-Platform2.zip


 The attached zip is a complete multi-module build with the bug exposed. Run 
 using mvn clean site site:stage to reproduce.
 What is observed is that the navigation hyperlinks in the top left (added by 
 the site plugin) are correctly defined as 
 target/staging/og-timeseries/index.html, whereas the hyperlinks in the 
 middle of index.html and modules.html are incorrectly defined as

[jira] (SUREFIRE-859) Exception in thread TreadedStreamConsumer java.lang.RuntimeException during GC

2014-11-13 Thread Mag Hoehme (JIRA)

[
https://jira.codehaus.org/browse/SUREFIRE-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356055#comment-356055
]

Mag Hoehme edited comment on SUREFIRE-859 at 11/13/14 2:40 AM:
---

Thanks for fixing the problem. Unfortunately, the setup in which the exception
was originally thrown is no longer in available to me.

was (Author: mag):
Thanks for fixing the problem. However, the setup in which the exception was
originally thrown is no longer in available to me.

Exception in thread TreadedStreamConsumer java.lang.RuntimeException during
GC

Attachments: runtimeexception.txt

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-859) Exception in thread TreadedStreamConsumer java.lang.RuntimeException during GC

2014-11-13 Thread Mag Hoehme (JIRA)


[ 
https://jira.codehaus.org/browse/SUREFIRE-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356055#comment-356055
 ] 

Mag Hoehme commented on SUREFIRE-859:
-

The setup in which the exception was originally thrown is no longer available.

 Exception in thread TreadedStreamConsumer java.lang.RuntimeException during 
 GC
 

 Key: SUREFIRE-859
 URL: https://jira.codehaus.org/browse/SUREFIRE-859
 Project: Maven Surefire
  Issue Type: Bug
  Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin, 
 process forking
Affects Versions: 2.11, 2.12
 Environment: Solaris  5.10, jdk16-1.6.0_11-0 (same with jdk1.5.0_14), 
 apache-maven-2.2.1
Reporter: Mag Hoehme
Assignee: Tibor Digana
 Fix For: 2.19

 Attachments: runtimeexception.txt


 When executing 151 integration tests with 829 test methods on a Solaris 
 machine, there is an exception: 
 ===
 Exception in thread ThreadStreamConsumer java.lang.RuntimeException: 176: 
 [GC 100,177: [ParNew
 ...
 java.langh.RuntimeException: The forked VM terminated without saying properly 
 goodbye. VM crash or System.exit called ?
 ===
 (see attachment for full stack traces)
 The message of the RuntimeException suggests that the problem is connected to 
 garbage collection. The stack trace points to ForkClient.java. It looks as if 
 the method consumeLine in ForkClient.java is fed with GC information 
 instead of the expected string.
 The exception occurs with concurrency configuration parallel='none' as well 
 as with parallel='classes' in both versions of the surefire plugin, 2.11 
 and 2.12.
 However, this problem does not show up on a Windows/Cygwin environment.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-859) Exception in thread TreadedStreamConsumer java.lang.RuntimeException during GC

[
https://jira.codehaus.org/browse/SUREFIRE-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356057#comment-356057
]

Tibor Digana commented on SUREFIRE-859:
---

@Mag
It was a simple fix. We are a small group of Maven developers. I would like to
ask you to participate in development from time to time. A lot of Maven
projects like surefire are available on GitHub as well.

Exception in thread TreadedStreamConsumer java.lang.RuntimeException during
GC

Attachments: runtimeexception.txt

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-279) Wrong hyperlinks on index and modules page

[
https://jira.codehaus.org/browse/MPIR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356060#comment-356060
]

Michael Osipov commented on MPIR-279:
-

Thanks, I have missed the {{localRepository}} completely. Though the exception
does not make sense at all but I will have at look at it.

As a last resort, one could disable the unit test. Sadly but maybe necessary
until someone finds the cause for that.

Wrong hyperlinks on index and modules page
--

Key: MPIR-279
URL: https://jira.codehaus.org/browse/MPIR-279
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: modules
Affects Versions: 2.7
Reporter: Stephen Colebourne
Assignee: Michael Osipov
Attachments: OG-Platform2.zip

The attached zip is a complete multi-module build with the bug exposed. Run
using mvn clean site site:stage to reproduce.
What is observed is that the navigation hyperlinks in the top left (added by
the site plugin) are correctly defined as
target/staging/og-timeseries/index.html, whereas the hyperlinks in the
middle of index.html and modules.html are incorrectly defined as
target/staging/projects/og-timeseries/index.html - note the incorrect extra
projects.
The problem will occur because the child projects in the multi-module build
are not immediate children of the parent/aggregator. Instead the structure is:
{code}
platform
- pom.xml
- projects
- og-timeseries
- pom.xml
{code}
The extra layer is being handled by the site plugin (by referring to the
distributionManagement.site.url). It is not handled by this plugin.
As a side note, if distributionManagement.site.url is NOT set in the child
projects, then the site will build consistently using
target/staging/projects/og-timeseries/index.html everywhere.
This is no doubt related to MPIR-273.

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-620) Ability to access manifest resource while running unit tests


[ 
https://jira.codehaus.org/browse/SUREFIRE-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356062#comment-356062
 ] 

Tibor Digana commented on SUREFIRE-620:
---

Any objections to close this issue?
IMHO you should use maven-failsafe-plugin instead.
The IT tests are supposed to test *.jar package instead of classes and 
test-classes.
You may probably find already reported bug that failsafe again uses classes 
instead of package. It should be fixed and this closed.

 Ability to access manifest resource while running unit tests
 

 Key: SUREFIRE-620
 URL: https://jira.codehaus.org/browse/SUREFIRE-620
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Junit 4.x support, Maven Surefire Plugin
Affects Versions: 2.5
 Environment: n/a
Reporter: Ernst de Haan
Priority: Minor

 Use case:
 - my code calls getClass().getPackage().getImplementationVersion() to 
 determine the version specified in the manifest
 - I would like to test this code, for example making sure the returned string 
 is not null
 Currently, when I run mvn test it does not generate the JAR, nor does it 
 not make the META-INF/MANIFEST.MF file available in the classpath.
 First question is whether this is a *unit* test or an *integration* test. I 
 would say a unit test, because no other code bases are involved, this should 
 be within a single module, and not testing any dependencies.
 Secondly, is the test valid at all if it uses a resource. I would say yes, 
 because it is even standard functionality offered by J2SE and I consider this 
 a good approach to determining meta data from the codebase self.
 Thirdly, should the Surefire plugin depend on the JAR being created or should 
 it just generate the manifest (and copy/generate other resources?) and stick 
 them where the compiled classes go?



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-620) Ability to access manifest resource while running unit tests


 [ 
https://jira.codehaus.org/browse/SUREFIRE-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-620:
-

Assignee: Tibor Digana

 Ability to access manifest resource while running unit tests
 

 Key: SUREFIRE-620
 URL: https://jira.codehaus.org/browse/SUREFIRE-620
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Junit 4.x support, Maven Surefire Plugin
Affects Versions: 2.5
 Environment: n/a
Reporter: Ernst de Haan
Assignee: Tibor Digana
Priority: Minor

 Use case:
 - my code calls getClass().getPackage().getImplementationVersion() to 
 determine the version specified in the manifest
 - I would like to test this code, for example making sure the returned string 
 is not null
 Currently, when I run mvn test it does not generate the JAR, nor does it 
 not make the META-INF/MANIFEST.MF file available in the classpath.
 First question is whether this is a *unit* test or an *integration* test. I 
 would say a unit test, because no other code bases are involved, this should 
 be within a single module, and not testing any dependencies.
 Secondly, is the test valid at all if it uses a resource. I would say yes, 
 because it is even standard functionality offered by J2SE and I consider this 
 a good approach to determining meta data from the codebase self.
 Thirdly, should the Surefire plugin depend on the JAR being created or should 
 it just generate the manifest (and copy/generate other resources?) and stick 
 them where the compiled classes go?



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-1054) test property overrides excludes but not excludedGroups


 [ 
https://jira.codehaus.org/browse/SUREFIRE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-1054:
--

Assignee: Tibor Digana

 test property overrides excludes but not excludedGroups
 -

 Key: SUREFIRE-1054
 URL: https://jira.codehaus.org/browse/SUREFIRE-1054
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.16
 Environment: Maven 3.1.1, JUnit 4.11, maven-surefire-plugin 2.16
Reporter: Elizabeth Chatman
Assignee: Tibor Digana

 I recently changed my maven configuration to use the excludedGroups 
 property instead of excludes, and found that I can no longer run individual 
 tests if they are part of the excludedGroups.
 Example:
 My default configuration used to look like this (using path and filename 
 matching to try to match groups of tests):
 {code:xml}
 excludes
   exclude**/integration/**/exclude
   exclude**/*IntegrationTest.java/exclude
 /excludes
 {code}
 My new configuration, after annotating my integration tests with 
 {{@Category(IntegrationTests.class)}}:
 {code:xml}excludedGroupscom.mycompany.IntegrationTests/excludedGroups{code}
 Previously, I could run a single integration test using:
 {{mvn test -Dtest=NameOfIntegrationTest}}
 Now that command fails (No tests were executed!) unless I manually override 
 the excludedGroups property ({{mvn test -Dtest=NameOfIntegrationTest 
 -DexcludedGroups=}})



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-1043) Please add possibility to specify tests groups order for sequential run and tests groups content for parallel run.

[
https://jira.codehaus.org/browse/SUREFIRE-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tibor Digana closed SUREFIRE-1043.
--

Resolution: Duplicate

Duplicate to the new feature in surefire/failsafe 2.19.
This seems to be solved with @NotThreadSafe annotation on tests running in a
sequence.

Please add possibility to specify tests groups order for sequential run and
tests groups content for parallel run.
--

Key: SUREFIRE-1043
URL: https://jira.codehaus.org/browse/SUREFIRE-1043
Project: Maven Surefire
Issue Type: Improvement
Affects Versions: 2.16
Reporter: Tomasz Halama

What we need is as following:
For sequential run:
We would like to have some means to specify run order of whole groups of
tests, during one invocation of plugin. Content of the group should be
determined by ant style expressions. Inside each such group, tests should be
run in order, specified by 'runOrder' parameter.
Example:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-failsafe-plugin/artifactId
configuration
groupsOrder
group**/*ST/group
groupcom/something/SomeTest,com/something/SomeTest2/group
group**/*IT,**/IT*/group
groupcom/something/SomeTest3/group
/groupsOrder
runOrderalphabetical/runOrder
/configuration
/plugin
In above example run order of tests should be as following:
1. all tests, which have ST suffix, should be run in alphabetical order
2. com/something/SomeTest and com/something/SomeTest2 should be run in
alphabetical order
3. all tests, which have IT suffix or prefix, should be run in alphabetical
order
4. com/something/SomeTest3 should be run
Instead of adding some new parameter (like above 'groupsOrder' section), I
think 'includes' can be used for this purpose (each entry would determine a
group), with some additional boolean value, i.e. 'groupsByIncludes'
(indicating, that each 'include' entry should be considered as a separate
group):
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-failsafe-plugin/artifactId
configuration
includes
include**/*ST.java/include

includecom/something/SomeTest.java,com/something/SomeTest2.java/include
include**/*IT.java,**/IT*.java/include
includecom/something/SomeTest3.java/include
/includes
runOrderalphabetical/runOrder
groupsByIncludestruegroupsByIncludes
/configuration
/plugin
In our case we cannot simply divide one invocation of plugin into several
ones (which would solve this problem), because setuping tests context takes
too much time.
This feature will also give possibility to run tests by some specific order
(when each 'group'/'include' would consist of only one entry). Possibility to
set specific order could be very handy, when i.e. you detected, that some of
your tests are not independent and you want to reproduce the problem.
For parallel run:
We would like to have some means to specify tests groups for parallel run. By
this I mean: tests in each group will be run in parallel, but the groups
itself will be run sequentially (so only tests from the same group can be
executed at the same time)
There should be also some annotation, which can be used to marked tests,
which cannot be run in parallel at all.
If 'includes' contains such tests - they should be run sequentially at the
end.
To achieve all of this, new (i.e. groupsOrder) or 'includes' parameter can be
used here, in the same way as for sequential run, except 'parallel' attribute
should be set to new value: i.e. parallelGroup.
I think, that logging information, when each test (each test method) starts
and stops, would be also a good idea (we would know exact tests, which are
run at the same time).

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-1001) PermGen space error from ThreadedStreamConsumer


 [ 
https://jira.codehaus.org/browse/SUREFIRE-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-1001:
--

Assignee: Tibor Digana

 PermGen space error from ThreadedStreamConsumer
 ---

 Key: SUREFIRE-1001
 URL: https://jira.codehaus.org/browse/SUREFIRE-1001
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.14.1
 Environment: Ubuntu, Linux ver.  3.2.0-26-virtual, Java 1.6.0_32
Reporter: Tomasz Dziurko
Assignee: Tibor Digana

 java.lang.OutOfMemoryError: PermGen space occurs while generating test report 
 after our 4h stress test. This seems to be the same type of problem as 
 http://jira.codehaus.org/browse/SUREFIRE-754
 [15:18:04][com.smspl.mc5:mc5-performance-tests] Exception in thread 
 ThreadedStreamConsumer java.lang.OutOfMemoryError: PermGen space
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.lang.ClassLoader.defineClass1(Native Method)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.lang.ClassLoader.defineClass(ClassLoader.java:615)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.net.URLClassLoader.access$000(URLClassLoader.java:58)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.net.URLClassLoader$1.run(URLClassLoader.java:197)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.security.AccessController.doPrivileged(Native Method)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.apache.maven.plugin.surefire.report.TestSetRunListener.wrap(TestSetRunListener.java:244)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:182)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:114)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.lang.Thread.run(Thread.java:662)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-1001) PermGen space error from ThreadedStreamConsumer


[ 
https://jira.codehaus.org/browse/SUREFIRE-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356064#comment-356064
 ] 

Tibor Digana commented on SUREFIRE-1001:


@Tomasz It is a forked process, thus try to use this configuration and let us 
know your findings argLine-XX:MaxPermSize=512m/argLine

 PermGen space error from ThreadedStreamConsumer
 ---

 Key: SUREFIRE-1001
 URL: https://jira.codehaus.org/browse/SUREFIRE-1001
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.14.1
 Environment: Ubuntu, Linux ver.  3.2.0-26-virtual, Java 1.6.0_32
Reporter: Tomasz Dziurko
Assignee: Tibor Digana

 java.lang.OutOfMemoryError: PermGen space occurs while generating test report 
 after our 4h stress test. This seems to be the same type of problem as 
 http://jira.codehaus.org/browse/SUREFIRE-754
 [15:18:04][com.smspl.mc5:mc5-performance-tests] Exception in thread 
 ThreadedStreamConsumer java.lang.OutOfMemoryError: PermGen space
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.lang.ClassLoader.defineClass1(Native Method)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.lang.ClassLoader.defineClass(ClassLoader.java:615)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.net.URLClassLoader.access$000(URLClassLoader.java:58)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.net.URLClassLoader$1.run(URLClassLoader.java:197)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.security.AccessController.doPrivileged(Native Method)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.apache.maven.plugin.surefire.report.TestSetRunListener.wrap(TestSetRunListener.java:244)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:182)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:114)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
 [15:18:04][com.smspl.mc5:mc5-performance-tests]   at 
 java.lang.Thread.run(Thread.java:662)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-735) Blame result on branched file is incorrect

2014-11-13 Thread Igor Polubelov (JIRA)


 [ 
https://jira.codehaus.org/browse/SCM-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Polubelov updated SCM-735:
---

Attachment: blame_result_fix.patch

fix for master

 Blame result on branched file is incorrect
 --

 Key: SCM-735
 URL: https://jira.codehaus.org/browse/SCM-735
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-perforce
Affects Versions: 1.8.1
Reporter: Gregory SSI-YAN-KAI
 Attachments: blame_result_fix.patch, scm.patch


 When a file is branched, its revision id restarts from 1.
 So, 2 different lines can have the same revision id even though they have 
 been submitted in 2 different changelists.
 Since the perforce blame command is based on the revision id of each line, 
 the result might be incorrect.
 The solution I'm proposing in the attached patch is to use changelist number 
 to identify the author of a line.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-324) DependencySet scope runtime includes jars that are scope provided


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-324.


   Resolution: Fixed
Fix Version/s: (was: 2.5.2)
   2.2.1
 Assignee: Kristian Rosenvold

I was able to reproduce this with the mentioned versions, and this is fixed 
with 2.2.1. Testcase is committed under bugs/massembly-324

 DependencySet scope runtime includes jars that are scope provided
 -

 Key: MASSEMBLY-324
 URL: https://jira.codehaus.org/browse/MASSEMBLY-324
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: dependencySet
Affects Versions: 2.2-beta-2
Reporter: Michael
Assignee: Kristian Rosenvold
 Fix For: 2.2.1


 I use some jars in provided scope:
 {code:xml}
   dependency
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.5/version
   scopeprovided/scope
   /dependency
 {code}
 in my assembly, I specify scope as runtime:
 {code:xml}
   dependencySet
   outputDirectoryWEB-INF/lib/outputDirectory
   unpackfalse/unpack
   scoperuntime/scope
   /dependencySet
 {code}
 Yet I still find the servlet-api-2.5.jar in my WAR.  SInce the servlet-api is 
 scope provided, it should be provided by the container and not included in 
 the WAR.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-929) Unexpected output with -Dmaven.surefire.debug


 [ 
https://jira.codehaus.org/browse/SUREFIRE-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-929.
-

Resolution: Not A Bug

The property is expected to bind to plugin parameter debugForkedProcess
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#debugForkedProcess

 Unexpected output with -Dmaven.surefire.debug
 ---

 Key: SUREFIRE-929
 URL: https://jira.codehaus.org/browse/SUREFIRE-929
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.12.4
Reporter: Tamás Cservenák

 Steps to recreate:
 1) create a project out of maven-quickstart 
 org.apache.maven.archetypes:maven-archetype-quickstart (just to have a 
 project, but actually _any_ project would do it)
 2) build it by executing following
 {noformat}
 mvn clean test -Dmaven.surefire.debug=tru
 {noformat}
 Yes, tru not true!
 Expected: build as usual, without debugging (have it aligned with other -D 
 switches like -DfailIfNoTests etc).
 What happens: WAT?
 {noformat}
 [cstamas@zaphod sample]$ mvn -V clean test -Dmaven.surefire.debug=tru
 Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
 Maven home: /usr/share/maven
 Java version: 1.6.0_37, vendor: Apple Inc.
 Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
 Default locale: en_US, platform encoding: MacRoman
 OS name: mac os x, version: 10.8.2, arch: x86_64, family: mac
 [INFO] Scanning for projects...
 [INFO]
  
 [INFO] 
 
 [INFO] Building a 1.0-SNAPSHOT
 [INFO] 
 
 [INFO] 
 [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ a ---
 [INFO] Deleting /Users/cstamas/tmp/sample/target
 [INFO] 
 [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ a ---
 [debug] execute contextualize
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] skip non existing resourceDirectory 
 /Users/cstamas/tmp/sample/src/main/resources
 [INFO] 
 [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ a ---
 [INFO] Compiling 1 source file to /Users/cstamas/tmp/sample/target/classes
 [INFO] 
 [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
 a ---
 [debug] execute contextualize
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] skip non existing resourceDirectory 
 /Users/cstamas/tmp/sample/src/test/resources
 [INFO] 
 [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ a 
 ---
 [INFO] Compiling 1 source file to 
 /Users/cstamas/tmp/sample/target/test-classes
 [INFO] 
 [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ a ---
 [INFO] Surefire report directory: 
 /Users/cstamas/tmp/sample/target/surefire-reports
 ---
  T E S T S
 ---
 Exception in thread main java.lang.NoClassDefFoundError: tru
 Caused by: java.lang.ClassNotFoundException: tru
   at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
 Results :
 Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
 [INFO] 
 
 [INFO] BUILD SUCCESS
 [INFO] 
 
 [INFO] Total time: 1.440s
 [INFO] Finished at: Fri Nov 30 17:06:41 CET 2012
 [INFO] Final Memory: 9M/81M
 [INFO] 
 
 [cstamas@zaphod sample]$
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-904) Categorization of tests results in running first tests without categorization,then tests run based on category


 [ 
https://jira.codehaus.org/browse/SUREFIRE-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-904:
-

Assignee: Tibor Digana

 Categorization of tests results in running first tests without 
 categorization,then tests run based on category
 --

 Key: SUREFIRE-904
 URL: https://jira.codehaus.org/browse/SUREFIRE-904
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.12.2
 Environment: maven 3.0.4
 junit 4.8.1
 maven surefire pluign 2.12.2
Reporter: Ronal Bashirov
Assignee: Tibor Digana
 Attachments: mavenproject2.zip


 I am separate my tests using junit categories.
 So I have some test:
  @Test
 @Category(UnitTest.class)
 public void testApp1() {
 
 System.out.println( UnitTest );
 assertTrue(true);
 }
 @Test
 @Category(ComponentTest.class)
 public void testApp2() {
 System.out.println( ComponentTest );
 assertTrue(true);
 }
 @Test
 @Category(SystemTest.class)
 public void testApp3() {
 System.out.println( SystemTest );
 assertTrue(true);
 }
 Then I am trying to run them separately 
  plugin
 artifactIdmaven-surefire-plugin/artifactId
 version2.12.2/version
 executions
 execution
 idunit-tests/id
 goals
 goaltest/goal
 /goals
 configuration
 
 groupscom.mycompany.mavenproject2.UnitTest/groups 
 reportsDirectory 
 ${project.build.directory}/surefire-reports/unit/reportsDirectory 
 
 /configuration 
 /execution
 execution
 idcomp-tests/id
 goals
 goaltest/goal
 /goals
 configuration
 
 groupscom.mycompany.mavenproject2.ComponentTest/groups
 reportsDirectory 
 ${project.build.directory}/surefire-reports/comp/reportsDirectory 
  
 /configuration 
 /execution
 execution
 idsys-tests/id
 goals
 goaltest/goal
 /goals
 configuration
 
 groupscom.mycompany.mavenproject2.SystemTest/groups
 reportsDirectory 
 ${project.build.directory}/surefire-reports/sys/reportsDirectory
  
 /configuration 
 /execution
 /executions
 
 /plugin
 As result I am getting
 ---
  T E S T S
 ---
 Running com.mycompany.mavenproject2.AppTest
 UnitTest
 ComponentTest
 SystemTest
 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
 Results :
 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
 [surefire:test]
 Surefire report directory: 
 C:\Users\mz\Documents\NetBeansProjects\mavenproject2\target\surefire-reports\unit
 ---
  T E S T S
 ---
 Concurrency config is parallel='none', perCoreThreadCount=true, 
 threadCount=2, useUnlimitedThreads=false
 Running com.mycompany.mavenproject2.AppTest
 UnitTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
 Results :
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
 [surefire:test]
 Surefire report directory: 
 C:\Users\mz\Documents\NetBeansProjects\mavenproject2\target\surefire-reports\comp
 ---
  T E S T S
 ---
 Concurrency config is parallel='none', perCoreThreadCount=true, 
 threadCount=2, useUnlimitedThreads=false
 Running com.mycompany.mavenproject2.AppTest
 ComponentTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
 Results :
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
 [surefire:test]
 Surefire report directory: 
 C:\Users\mz\Documents\NetBeansProjects\mavenproject2\target\surefire-reports\sys
 ---
  T E S T S
 ---

[jira] (SUREFIRE-893) Unsupported provider features should throw exception


[ 
https://jira.codehaus.org/browse/SUREFIRE-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356069#comment-356069
 ] 

Tibor Digana commented on SUREFIRE-893:
---

the features matrix link:
http://maven.apache.org/surefire/maven-surefire-plugin/featurematrix.html

 Unsupported provider features should throw exception
 

 Key: SUREFIRE-893
 URL: https://jira.codehaus.org/browse/SUREFIRE-893
 Project: Maven Surefire
  Issue Type: Improvement
Reporter: Kristian Rosenvold

 The feature matrix indicates that not all providers support all features,
 but some providers do not throw exceptions if the feature is attempted used.
 http://maven.apache.org/plugins/maven-surefire-plugin-2.12.1/plugins/maven-surefire-plugin/featurematrix.html
 Add mechanism to throw exception when a provider does not support a feature.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-867) Add a way to declare all project properties as environmentVariables


[ 
https://jira.codehaus.org/browse/SUREFIRE-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356070#comment-356070
 ] 

Tibor Digana commented on SUREFIRE-867:
---

Any objections to close this issue?

 Add a way to declare all project properties as environmentVariables
 ---

 Key: SUREFIRE-867
 URL: https://jira.codehaus.org/browse/SUREFIRE-867
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
Reporter: Pierre Le Roux
  Labels: proposed-wontfix

 It could be great to have a new option such as 
 *allPropertiesAsEnvironmentVariables* (by default : false) that would 
 retrieve all context properties (project, parent project and activated 
 profile properties) and add it as environment variables.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-867) Add a way to declare all project properties as environmentVariables


 [ 
https://jira.codehaus.org/browse/SUREFIRE-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-867:
-

Assignee: Tibor Digana

 Add a way to declare all project properties as environmentVariables
 ---

 Key: SUREFIRE-867
 URL: https://jira.codehaus.org/browse/SUREFIRE-867
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
Reporter: Pierre Le Roux
Assignee: Tibor Digana
  Labels: proposed-wontfix

 It could be great to have a new option such as 
 *allPropertiesAsEnvironmentVariables* (by default : false) that would 
 retrieve all context properties (project, parent project and activated 
 profile properties) and add it as environment variables.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-840) Print memory usage


[ 
https://jira.codehaus.org/browse/SUREFIRE-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356071#comment-356071
 ] 

Tibor Digana commented on SUREFIRE-840:
---

If still required you can open pull-request in GitHUb, but IMHO you can add a 
Thread in Java shutdown-hook by yourself.

 Print memory usage
 --

 Key: SUREFIRE-840
 URL: https://jira.codehaus.org/browse/SUREFIRE-840
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
Reporter: Simon Brandhof

 The memory usage is helpful when the process is forked. It could look like :
 * When forkMode is once :
 {noformat}
 Results :
 Tests run: 20, Failures: 0, Errors: 0, Skipped: 0
 Tests Memory: 91M/171M
 {noformat}
 * When forkMode is always :
 {noformat}
 Running org.foo.MyTest
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec, 
 Memory usage: 91M/171M
 {noformat}
 * When forkMode is perthread :
 {noformat}
 Results :
 Tests run: 20, Failures: 0, Errors: 0, Skipped: 0
 Tests Memory: 91M/171M, 20M/171M, 87M/200M
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-833) Support for annotated JUnit @Category


[ 
https://jira.codehaus.org/browse/SUREFIRE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356072#comment-356072
 ] 

Tibor Digana commented on SUREFIRE-833:
---

Hey guys, I have a compromised improvement. Providing a configuration entry in 
order to specify JUnit Filter class. It would filter out the tests by custom 
algorithm.
Agree/disagree?

 Support for annotated JUnit @Category
 -

 Key: SUREFIRE-833
 URL: https://jira.codehaus.org/browse/SUREFIRE-833
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Junit 4.x support
Affects Versions: 2.12
Reporter: Jan Goyvaerts
 Attachments: SUREFIRE-833-spraguep-2.patch, 
 SUREFIRE-833-spraguep.patch


 The current implementation of Surefire seems to look for explicit @Category 
 annotations in the test classes. And will only consider those. Suppose I'd 
 like to add a more concise annotation for this:
 @Category(IntegrationTests.class) == JUnit @Category
 @Target({ElementType.TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Documented
 public @interface IntegrationTest {}
 Annotating my test class with @IntegrationTest does not work. Although I 
 think it looks much better than repeating everywhere in my code 
 @Category(com.foo.bar.IntegrationTests.class). For which I add an 
 additional dependency in the interface class btw.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-713) Allow setting of excludes and includes via text files


[ 
https://jira.codehaus.org/browse/SUREFIRE-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356073#comment-356073
 ] 

Tibor Digana commented on SUREFIRE-713:
---

Shouldn't this be closed as duplicate to SUREFIRE-726 ?

 Allow setting of excludes and includes via text files
 -

 Key: SUREFIRE-713
 URL: https://jira.codehaus.org/browse/SUREFIRE-713
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Maven Failsafe Plugin, Maven Surefire Plugin
Affects Versions: Backlog
Reporter: Andrew Bayer
 Attachments: excludeIncludeFile.patch


 It'd be handy in some circumstances to be able to read the excludes (and 
 includes) from text files. This would allow for dynamically determining which 
 tests to skip or include (for whatever reason) before the tests are executed, 
 or for pulling in a list of tests to exclude/include from an external source, 
 etc. We're planning to use this at Cloudera for segregating flaky tests 
 from our primary test runs (and vice versa). Patch attached, though I'm sure 
 it could still use work. 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-632) add a test-failed goal, to only run the tests which failed last time


[ 
https://jira.codehaus.org/browse/SUREFIRE-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356074#comment-356074
 ] 

Tibor Digana commented on SUREFIRE-632:
---

Any objections to close this issue?
Passed four years after opening this issue, maybe not relevant for the Reporter 
anymore.
We have introduced RE-RUN feature in SUREFIRE 2.18.
Is this a feature you would use instead of you rpoposal?

 add a test-failed goal, to only run the tests which failed last time
 

 Key: SUREFIRE-632
 URL: https://jira.codehaus.org/browse/SUREFIRE-632
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
Affects Versions: 2.5
Reporter: james strachan

 if the test goal outputs to target/surefire-reports/failures.txt a little 
 text file of all the failures which occurred in the previous test run, it 
 would be easy to add a new goal *test-failed* which just runs all the test 
 cases which previously failed.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SCM-735) Blame result on branched file is incorrect

2014-11-13 Thread Igor Polubelov (JIRA)


[ 
https://jira.codehaus.org/browse/SCM-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356075#comment-356075
 ] 

Igor Polubelov commented on SCM-735:


Hi, I've attached the patch for the latest sources. It does the same as the 
previous patch and also uses reluctant wild cards and adds -i option in the 
createFilelogCommandLine.

 Blame result on branched file is incorrect
 --

 Key: SCM-735
 URL: https://jira.codehaus.org/browse/SCM-735
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-perforce
Affects Versions: 1.8.1
Reporter: Gregory SSI-YAN-KAI
 Attachments: blame_result_fix.patch, scm.patch


 When a file is branched, its revision id restarts from 1.
 So, 2 different lines can have the same revision id even though they have 
 been submitted in 2 different changelists.
 Since the perforce blame command is based on the revision id of each line, 
 the result might be incorrect.
 The solution I'm proposing in the attached patch is to use changelist number 
 to identify the author of a line.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-279) Wrong hyperlinks on index and modules page

[
https://jira.codehaus.org/browse/MPIR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356076#comment-356076
]

Michael Osipov commented on MPIR-279:
-

Stuart McCulloch give me the final tip on the dev mailing list. Test passes
now. I will proceed with the merge later today.

Wrong hyperlinks on index and modules page
--

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element


[ 
https://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356077#comment-356077
 ] 

Arne Franken commented on SUREFIRE-649:
---

I just updated to Surefire 2.18.

Before the fix, it was possible to set empty and null System Properties, after 
the fix, it's not possible to pass null System Properties (which are in turn 
ignored by Surefire) any more.

Is there a proposed workaround?

We rely on it being possible to optionally set System Properties for Maven 
builds by passing -Dpropertyname to the mvn executable, otherwise the system 
property should be ignored by Surefire (maven-tomcat-plugin behaves the same 
way, it even logs [INFO] skip sysProps propertyname with empty value)

 Might be impossible to have empty strings in systemPropertyVariables element
 

 Key: SUREFIRE-649
 URL: https://jira.codehaus.org/browse/SUREFIRE-649
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Tibor Digana
Priority: Minor
 Fix For: 2.18

 Attachments: surefireEmptyStringIssue.tar.gz


 This stanza:
 systemProperties
   property
 nameemptyProperty/name
 value/value
   /property
 /systemProperties
 ...yields  from System.getProperty(emptyProperty).
 This (supposedly better) stanza:
 systemPropertyVariables
   emptyProperty/emptyProperty
 /systemPropertyVariables
 ...yields null from System.getProperty(emptyProperty).
 A test case is attached that demonstrates the issue.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element


[ 
https://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356079#comment-356079
 ] 

Tibor Digana commented on SUREFIRE-649:
---

The null string means that the system property is unspecified in the 
configuration.
The workaround would be to set null property if getSystemProperty() returns 
empty string in @BeforeClass.

 Might be impossible to have empty strings in systemPropertyVariables element
 

 Key: SUREFIRE-649
 URL: https://jira.codehaus.org/browse/SUREFIRE-649
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Tibor Digana
Priority: Minor
 Fix For: 2.18

 Attachments: surefireEmptyStringIssue.tar.gz


 This stanza:
 systemProperties
   property
 nameemptyProperty/name
 value/value
   /property
 /systemProperties
 ...yields  from System.getProperty(emptyProperty).
 This (supposedly better) stanza:
 systemPropertyVariables
   emptyProperty/emptyProperty
 /systemPropertyVariables
 ...yields null from System.getProperty(emptyProperty).
 A test case is attached that demonstrates the issue.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-732) baseDirectory is ignored with files entries


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-732.


Resolution: Fixed
  Assignee: Kristian Rosenvold

Fixed in r1639362, thanks for the bug report !

 baseDirectory is ignored with files entries
 ---

 Key: MASSEMBLY-732
 URL: https://jira.codehaus.org/browse/MASSEMBLY-732
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.1
Reporter: Phil Webb
Assignee: Kristian Rosenvold
Priority: Minor
 Fix For: 2.5.2


 With version 2.4 an assembly like this:
 {noformat}
 assembly
   idbin/id
   formats
   formatzip/format
   /formats
   baseDirectoryspring-${project.version}/baseDirectory
   includeBaseDirectorytrue/includeBaseDirectory
   files
   file
   
 source${project.build.directory}/${project.artifactId}-${project.version}-full.jar/source
   outputDirectory/lib/outputDirectory
   destName${project.build.finalName}.jar/destName
   /file
   /files
 /assembly
 {noformat}
 would write the file inside the zip under 
 {{spring-$\{project.version\}/lib}}. With 2.5.1 the {{baseDir}} is ignored 
 and files are written under {{/lib}}.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element


[ 
https://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356083#comment-356083
 ] 

Arne Franken commented on SUREFIRE-649:
---

maybe this is a misunderstanding:

Before, when setting an empty SystemProperty myproperty/, Surefire would not 
set that System Property at all for the forked process.
Now, the System Property is set with an empty value.

We actually want Surefire to ignore empty SystemProperty, just as 
maven-tomcat-plugin does.

 Might be impossible to have empty strings in systemPropertyVariables element
 

 Key: SUREFIRE-649
 URL: https://jira.codehaus.org/browse/SUREFIRE-649
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Tibor Digana
Priority: Minor
 Fix For: 2.18

 Attachments: surefireEmptyStringIssue.tar.gz


 This stanza:
 systemProperties
   property
 nameemptyProperty/name
 value/value
   /property
 /systemProperties
 ...yields  from System.getProperty(emptyProperty).
 This (supposedly better) stanza:
 systemPropertyVariables
   emptyProperty/emptyProperty
 /systemPropertyVariables
 ...yields null from System.getProperty(emptyProperty).
 A test case is attached that demonstrates the issue.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-317) useStrictFiltering requires dependency in all included modules


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-317.


   Resolution: Fixed
Fix Version/s: (was: 2.5.2)
   2.2

This appears to be fixed around 2.2

 useStrictFiltering requires dependency in all included modules
 --

 Key: MASSEMBLY-317
 URL: https://jira.codehaus.org/browse/MASSEMBLY-317
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: moduleSet
Affects Versions: 2.2-beta-2
Reporter: Thomas Diesler
 Fix For: 2.2


 With this moduleSet all dependency artifacts must be defined in all included 
 modules
 {code:xml}
 moduleSet
   includes
 includeorg.jboss.ws:jbossws-cxf-server/include
 includeorg.jboss.ws:jbossws-cxf-client/include
   /includes
   binaries
 outputDirectoryserver/default/deploy/jbossws.sar/outputDirectory
 
 outputFileNameMapping${module.artifactId}.${module.extension}/outputFileNameMapping
 unpackfalse/unpack
 dependencySets
   dependencySet
 
 outputFileNameMapping${module.artifactId}.${module.extension}/outputFileNameMapping
 useStrictFilteringtrue/useStrictFiltering
 includes
   include*:cxf-*/include
   include*:geronimo-javamail*/include
   include*:geronimo-ws-metadata*/include
   include*:jaxrpc-api*/include
   include*:jaxws-api*/include
   include*:neethi*/include
   include*:saaj-api*/include
   include*:saaj-impl*/include
   include*:spring-beans*/include
   include*:spring-context*/include
   include*:spring-core*/include
   include*:wsdl4j*/include
   include*:xml-resolver*/include
   include*:XmlSchema*/include
 /includes
   /dependencySet
 /dependencySets
   /binaries
 /moduleSet
 {code}
 I believe this should be changed such that the dependency is satisfied by at 
 least one module.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-702) Add default values for directoryMode / fileMode


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-702.


Resolution: Fixed
  Assignee: Kristian Rosenvold

Added docs on default file modes in r1639379

 Add default values for directoryMode / fileMode
 ---

 Key: MASSEMBLY-702
 URL: https://jira.codehaus.org/browse/MASSEMBLY-702
 Project: Maven Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.4.1
Reporter: Karl-Heinz Marbaise
Assignee: Kristian Rosenvold
Priority: Trivial
 Fix For: 2.5.2


 The default value for directoryMode nor for fileMode is documented.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-708) predefined descriptors lack of permission definition for unix (directoryMode/fileMode)


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-708.


Resolution: Won't Fix
  Assignee: Kristian Rosenvold

There are default values for descriptors in plexus-archiver. These have been 
documented in assembly descriptor for now, no need to duplicate them for 
predefined descriptors

 predefined descriptors lack of permission definition for unix 
 (directoryMode/fileMode)
 --

 Key: MASSEMBLY-708
 URL: https://jira.codehaus.org/browse/MASSEMBLY-708
 Project: Maven Assembly Plugin
  Issue Type: Improvement
Reporter: Karl-Heinz Marbaise
Assignee: Kristian Rosenvold
Priority: Minor
 Fix For: 2.5.2


 The current predefined descriptors do not contain any definition of 
 directoryMode nor fileMode in case of a tar.gz which can be decompressed on 
 linux which also can include some kind of permissions.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-728) Assembly plugin = 2.5 thinks my group ID is too big

2014-11-13 Thread Michael Heuer (JIRA)


[ 
https://jira.codehaus.org/browse/MASSEMBLY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356088#comment-356088
 ] 

Michael Heuer commented on MASSEMBLY-728:
-

@krosenvold, I see the text you added in the faq entry, but it doesn't say 
where to set tarLongFileMode=posix.  Is that a plugin configuration parameter 
or something that goes in the assembly descriptor?

 Assembly plugin = 2.5 thinks my group ID is too big
 

 Key: MASSEMBLY-728
 URL: https://jira.codehaus.org/browse/MASSEMBLY-728
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Andrew Todd
Assignee: Kristian Rosenvold
 Fix For: 2.5.2


 My OS X user's primary group ID is quite large, around 110075129.
 Up until assembly 2.4.1, I have had no troubles. However, in 2.5, I get this 
 error when trying to create an assembly:
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5:single 
 (assemble-command-line) on project crypto-monster: Execution 
 assemble-command-line of goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5:single failed: group id 
 '110075129' is too big (  2097151 ) - [Help 1]
 I am using JDK 7 to build. Have not tested with 8.
 I have noticed that the error seems to be specific to assembly of a .tar.gz 
 artifact. Assembling a .zip file does not cause this error.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-607) Wildcard in dependencySet/includes doesn't match artifact with empty classifier


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MASSEMBLY-607:
-

Fix Version/s: (was: 2.5.2)

 Wildcard in dependencySet/includes doesn't match artifact with empty 
 classifier
 ---

 Key: MASSEMBLY-607
 URL: https://jira.codehaus.org/browse/MASSEMBLY-607
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: dependencySet
Affects Versions: 2.3
 Environment: Windows 7/Maven 3.0.03
Reporter: Alexander Kormushin

 Following dependency set will match only my jar artifacts with any non-empty 
 classifier:
 {code}
 dependencySet
 includes
 includecom.mycompany.*:*:jar:*:*/include
 /includes
 /dependencySet
 {code}
 But it seems wildcard should include empty ones.
 Here is the related code fragment:
 {code:title=.m2\repository\org\apache\maven\shared\maven-common-artifact-filters\1.4\maven-common-artifact-filters-1.4.jar!\org\apache\maven\shared\artifact\filter\PatternIncludesArtifactFilter.class}
 172private boolean matchAgainst( final String value, final List patterns, 
 final boolean regionMatch )
 181// fail immediately if pattern tokens outnumber tokens to match
 182boolean matched = ( patternTokens.length = tokens.length );
 {code}
 I have following values achieving 182 line:
 pattern=[com.mycompany.*, *, jar, *, *]
 tokens=[com.mycompany, myproject, jar, 1.0.0-SNAPSHOT]



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'

2014-11-13 Thread Daniel Huss (JIRA)


[ 
https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356090#comment-356090
 ] 

Daniel Huss commented on MEAR-166:
--

Would love to see this fixed :-)

Here is my use case: 

=== in web module ===
{code:java}
@Path(/hello)
public class HelloResource
{
@Inject
private HelloService helloService;
 ...
}
{code}

I think this simple use case is _impossible_ to get right with 
typeejb-client/type because the whole ejb-client mechanism is fundamentally 
flawed:

* Depending on ejb-client artifacts will still pull all dependencies of the EJB 
implementation into the corresponding dependency scope.
* If separating API from EJB implementation is the purpose of the ejb-client 
feature, the EJB artifact should depend on the API artifact and all API classes 
should be stripped from the EJB artifact. Since both ejb-client and ejb 
originate from the same POM, this is not possible (I think). 
** So we end up with a typeejb/type artifact plus a typeejb-client/type 
artifact, both containing all API classes. In a JEE container such as JBoss AS 
7, this will easily lead to the following situation:
**# The EJB implementaiton sees API class HelloService loaded by class loader 
A
**# The API consumer sees API class HelloService loaded by class loader B
**# A.HelloService is not equal to B.HelloService
**# CDI fails because of unsatisfied dependencies

In my opinion typeejb-client/type should never be used as a maven 
dependency for those reasons. If I could, I'd simply avoid using the 
maven-ejb-plugin by creating two plain packagingjar/packaging projects. 
However, this is not an option because the ear plugin requires typeejb/type 
for ejbModules  (and I do like the ear plugin :-) )


 'skinnyWar' doesn't work well with dependencies of type 'ejb'
 -

 Key: MEAR-166
 URL: https://jira.codehaus.org/browse/MEAR-166
 Project: Maven Ear Plugin
  Issue Type: New Feature
Affects Versions: 2.8, 2.9
 Environment: many different environments I've verified this on
Reporter: Michal Michalski
Priority: Minor
 Fix For: more-investigation


 It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it 
 does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies 
 exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic 
 trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's 
 dependencies should go to EAR's lib.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-728) Assembly plugin = 2.5 thinks my group ID is too big


[ 
https://jira.codehaus.org/browse/MASSEMBLY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356089#comment-356089
 ] 

Kristian Rosenvold commented on MASSEMBLY-728:
--

Upped entry. It's in the plugin goal. Thanks for asking :)


 Assembly plugin = 2.5 thinks my group ID is too big
 

 Key: MASSEMBLY-728
 URL: https://jira.codehaus.org/browse/MASSEMBLY-728
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Andrew Todd
Assignee: Kristian Rosenvold
 Fix For: 2.5.2


 My OS X user's primary group ID is quite large, around 110075129.
 Up until assembly 2.4.1, I have had no troubles. However, in 2.5, I get this 
 error when trying to create an assembly:
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5:single 
 (assemble-command-line) on project crypto-monster: Execution 
 assemble-command-line of goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5:single failed: group id 
 '110075129' is too big (  2097151 ) - [Help 1]
 I am using JDK 7 to build. Have not tested with 8.
 I have noticed that the error seems to be specific to assembly of a .tar.gz 
 artifact. Assembling a .zip file does not cause this error.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element


[ 
https://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356096#comment-356096
 ] 

Arne Franken commented on SUREFIRE-649:
---

as a background:
We have a Spring Framework based application that uses the 
[PropertyPlaceholderConfigurer in System Properties Override 
mode|http://docs.spring.io/spring-framework/docs/2.0.8/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html#SYSTEM_PROPERTIES_MODE_OVERRIDE]

The defaults for properties are managed by the application.

We execute a test with Failsafe, loading the application with the test.

In order to be able to override properties in tests (for example URLs to 
connect against), we use System Properties:

--POM--
properties
myProperty/
/properties
...
failsafe configration
systemPropertyVariables
myProperty${myProperty}/myProperty
/systemPropertyVariables
--POM--

If the plugin is executed without setting -DmyProperty, Surefire 2.16 ignored 
the configuration and the application would use the property default when 
creating the Spring Beans.

Now, an empty String is passed to the JVM, so an empty String is used when 
creating the Spring Beans...

Why was the behaviour changed if it was working fine before and there is syntax 
to set empty System Properties?

Now, there is no way to optionally pass SystemProperties to the process started 
by Surefire...

 Might be impossible to have empty strings in systemPropertyVariables element
 

 Key: SUREFIRE-649
 URL: https://jira.codehaus.org/browse/SUREFIRE-649
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Tibor Digana
Priority: Minor
 Fix For: 2.18

 Attachments: surefireEmptyStringIssue.tar.gz


 This stanza:
 systemProperties
   property
 nameemptyProperty/name
 value/value
   /property
 /systemProperties
 ...yields  from System.getProperty(emptyProperty).
 This (supposedly better) stanza:
 systemPropertyVariables
   emptyProperty/emptyProperty
 /systemPropertyVariables
 ...yields null from System.getProperty(emptyProperty).
 A test case is attached that demonstrates the issue.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element


[ 
https://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356096#comment-356096
 ] 

Arne Franken edited comment on SUREFIRE-649 at 11/13/14 12:03 PM:
--

as a background:
We have a Spring Framework based application that uses the 
[PropertyPlaceholderConfigurer in System Properties Override 
mode|http://docs.spring.io/spring-framework/docs/2.0.8/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html#SYSTEM_PROPERTIES_MODE_OVERRIDE]

The defaults for properties are managed by the application.

We execute a test with Failsafe, loading the application with the test.

In order to be able to override properties in tests (for example URLs to 
connect against), we use System Properties:

#POM#
properties
myProperty/
/properties
...
failsafe configration
systemPropertyVariables
myProperty${myProperty}/myProperty
/systemPropertyVariables
#POM#

If the plugin is executed without setting -DmyProperty, Surefire 2.16 ignored 
the configuration and the application would use the property default when 
creating the Spring Beans.

Now, an empty String is passed to the JVM, so an empty String is used when 
creating the Spring Beans...

Why was the behaviour changed if it was working fine before and there is syntax 
to set empty System Properties?

Now, there is no way to optionally pass SystemProperties to the process started 
by Surefire...


was (Author: afranken):
as a background:
We have a Spring Framework based application that uses the 
[PropertyPlaceholderConfigurer in System Properties Override 
mode|http://docs.spring.io/spring-framework/docs/2.0.8/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html#SYSTEM_PROPERTIES_MODE_OVERRIDE]

The defaults for properties are managed by the application.

We execute a test with Failsafe, loading the application with the test.

In order to be able to override properties in tests (for example URLs to 
connect against), we use System Properties:

--POM--
properties
myProperty/
/properties
...
failsafe configration
systemPropertyVariables
myProperty${myProperty}/myProperty
/systemPropertyVariables
--POM--

If the plugin is executed without setting -DmyProperty, Surefire 2.16 ignored 
the configuration and the application would use the property default when 
creating the Spring Beans.

Now, an empty String is passed to the JVM, so an empty String is used when 
creating the Spring Beans...

Why was the behaviour changed if it was working fine before and there is syntax 
to set empty System Properties?

Now, there is no way to optionally pass SystemProperties to the process started 
by Surefire...

 Might be impossible to have empty strings in systemPropertyVariables element
 

 Key: SUREFIRE-649
 URL: https://jira.codehaus.org/browse/SUREFIRE-649
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Tibor Digana
Priority: Minor
 Fix For: 2.18

 Attachments: surefireEmptyStringIssue.tar.gz


 This stanza:
 systemProperties
   property
 nameemptyProperty/name
 value/value
   /property
 /systemProperties
 ...yields  from System.getProperty(emptyProperty).
 This (supposedly better) stanza:
 systemPropertyVariables
   emptyProperty/emptyProperty
 /systemPropertyVariables
 ...yields null from System.getProperty(emptyProperty).
 A test case is attached that demonstrates the issue.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element


[ 
https://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356096#comment-356096
 ] 

Arne Franken edited comment on SUREFIRE-649 at 11/13/14 12:03 PM:
--

as a background:
We have a Spring Framework based application that uses the 
[PropertyPlaceholderConfigurer in System Properties Override 
mode|http://docs.spring.io/spring-framework/docs/2.0.8/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html#SYSTEM_PROPERTIES_MODE_OVERRIDE]

The defaults for properties are managed by the application.

We execute a test with Failsafe, loading the application with the test.

In order to be able to override properties in tests (for example URLs to 
connect against), we use System Properties:

#POM#
properties
myProperty/
/properties
...
failsafe configration
systemPropertyVariables
myProperty$\{myProperty\}/myProperty
/systemPropertyVariables
#POM#

If the plugin is executed without setting -DmyProperty, Surefire 2.16 ignored 
the configuration and the application would use the property default when 
creating the Spring Beans.

Now, an empty String is passed to the JVM, so an empty String is used when 
creating the Spring Beans...

Why was the behaviour changed if it was working fine before and there is syntax 
to set empty System Properties?

Now, there is no way to optionally pass SystemProperties to the process started 
by Surefire...


was (Author: afranken):
as a background:
We have a Spring Framework based application that uses the 
[PropertyPlaceholderConfigurer in System Properties Override 
mode|http://docs.spring.io/spring-framework/docs/2.0.8/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html#SYSTEM_PROPERTIES_MODE_OVERRIDE]

The defaults for properties are managed by the application.

We execute a test with Failsafe, loading the application with the test.

In order to be able to override properties in tests (for example URLs to 
connect against), we use System Properties:

#POM#
properties
myProperty/
/properties
...
failsafe configration
systemPropertyVariables
myProperty${myProperty}/myProperty
/systemPropertyVariables
#POM#

If the plugin is executed without setting -DmyProperty, Surefire 2.16 ignored 
the configuration and the application would use the property default when 
creating the Spring Beans.

Now, an empty String is passed to the JVM, so an empty String is used when 
creating the Spring Beans...

Why was the behaviour changed if it was working fine before and there is syntax 
to set empty System Properties?

Now, there is no way to optionally pass SystemProperties to the process started 
by Surefire...

 Might be impossible to have empty strings in systemPropertyVariables element
 

 Key: SUREFIRE-649
 URL: https://jira.codehaus.org/browse/SUREFIRE-649
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Tibor Digana
Priority: Minor
 Fix For: 2.18

 Attachments: surefireEmptyStringIssue.tar.gz


 This stanza:
 systemProperties
   property
 nameemptyProperty/name
 value/value
   /property
 /systemProperties
 ...yields  from System.getProperty(emptyProperty).
 This (supposedly better) stanza:
 systemPropertyVariables
   emptyProperty/emptyProperty
 /systemPropertyVariables
 ...yields null from System.getProperty(emptyProperty).
 A test case is attached that demonstrates the issue.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-616) do not included artifacts with scope system as dependencies


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MASSEMBLY-616:
-

Fix Version/s: (was: 2.5.2)

 do not included artifacts with scope system as dependencies
 ---

 Key: MASSEMBLY-616
 URL: https://jira.codehaus.org/browse/MASSEMBLY-616
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: FreeBSD 8, 64bit, openjdk6/7
Reporter: Radim Kolar

 If you are building assembly with dependencies included:
 {code:xml}
 useTransitiveDependenciestrue/useTransitiveDependencies
 {code}
 and one of dependencies has scope like that:
 {code:xml}
 dependencies
 dependency
   groupIdjdk.tools/groupId
   artifactIdjdk.tools/artifactId
   version1.6/version
   scopesystem/scope
   systemPath${java.home}/../lib/tools.jar/systemPath
 /dependency
 /dependencies
 {code}
 then assembly plugin tries to fetch that artifact from repository. Artifact 
 of course is not there.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-597) Duplicate files added to archive when present in both dependencyset and fileset of the same assembly


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-597.


Resolution: Fixed
  Assignee: Kristian Rosenvold

Fixed in r1639465 

 Duplicate files added to archive when present in both dependencyset and 
 fileset of the same assembly
 

 Key: MASSEMBLY-597
 URL: https://jira.codehaus.org/browse/MASSEMBLY-597
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2.2
 Environment: windows 7, Eclipse indigo though the problem is 
 reproducible from command line build. Java 6 32 bit
Reporter: Eric Daigneault
Assignee: Kristian Rosenvold
 Fix For: 2.5.2

 Attachments: ma597.zip


 Comment added to parent bug, could not re-open the issue so I created this 
 sub-task instead.  Comment copied here for convenience :
 
 Either version 2.2.2 of the Assembly plugin has a regression or the issue has 
 not been fixed.  I am currently creating zip files from the assembly that 
 contains duplicate jar files.  
 Some background :  I am using the assembly to create a zip file of an 
 application.  Why Zip ? because the application requires multiple 
 configuration files and spans larger than just Java so I cannot use a uber 
 Jar (I would prefer that but technical limitations out of my control force me 
 otherwise).
 This package is built correctly.
 To make life simpler I made it possible to extend this package with a project 
 that can add extra classes (plugins and such) and configuration from a 
 standard layout in the project that gets picked up by the assembly and merged 
 with the previous vanilla package.  the end result is a fully assembled zip 
 file with all the customized parts in the right place.
 Now, behaviour changed across version wheras previously I would overwrite the 
 original package with the content of the new one, now I have to start from 
 the overrides and complete withe the original files.  Easily fixed through 
 changing the order I declared the filesets in the assembly.  When using 
 filesets strictly nothing gets added twice, though the replace was changed to 
 skip which is a bit counter intuitive.
 BUT
 Since I extend some parts of the original system, I will share some 
 dependencies with this one.  These dependencies are already present in the 
 original package and get added through a file set (I get the package and 
 unzip it in a temporary folder where I integrate it`s content inthe assembly 
 through a fileset).  
 I also add the dependencies of the new customized project, and these get 
 added twice.
 I think there is a regression here when filesets and dependencysets interact 
 where if files are present in both they get added twice in the zip file.  Now 
 I would re-open this current task but it seems I cannot so I will open a sub 
 task instead.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-273) links to modules broken in modules.html of flat multimodule parent project


[ 
https://jira.codehaus.org/browse/MPIR-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356101#comment-356101
 ] 

Michael Osipov commented on MPIR-273:
-

Jörg,

please test the patch from MPIR-279, this might fix your issue as well.

 links to modules broken in modules.html of flat multimodule parent project
 --

 Key: MPIR-273
 URL: https://jira.codehaus.org/browse/MPIR-273
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: index, modules
Affects Versions: 2.6
 Environment: SLES 11
Reporter: Jörg Sesterhenn

 My flat structured multimodule project looks like this:
 /l2m-build/pom.xml - parent module
 /l2m/pom.xml   - child  module
 During site-deploy the links in modules.html to the submodules are falsely 
 generated like:
 ...site/de.test.l2m/l2m-build/1.1.4-SNAPSHOT/l2m-build/l2m/index.html
 While the link in the sitemenu that was generated by menu ref=modules / 
 is correct and looks like:
 ...site/de.test.l2m/l2m/1.1.4-SNAPSHOT/l2m/index.html
 It seems that the path needs to step down one directory ('../l2m/index.html').
 The URL in the POM (of the parent and all child modules) is inherited from 
 the company-parent-pom, where it is defined as
 {code:xml}urldav:http//:some.nice.url.de/${project.groupId}/${project.artifactId}/${project.version}/url{code}
 This is similar to MOJO-1630.
 If you need more information to look into this, please let me know.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-303) Backslash in multi-module project


[ 
https://jira.codehaus.org/browse/MPIR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356102#comment-356102
 ] 

Michael Osipov commented on MPIR-303:
-

Anyone else beside Grzegorz?

 Backslash in multi-module project
 -

 Key: MPIR-303
 URL: https://jira.codehaus.org/browse/MPIR-303
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: plugins
Affects Versions: 2.7
Reporter: Tibor Digana
 Attachments: mpir-303.zip


 We have experienced the backslash in multi-module project Maven Surefire 
 2.18-SNAPSHOT.
 Link should replace Windows \ (gr) with web / (a).



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSHARED-384) Add support for copying symlinks

Kristian Rosenvold created MSHARED-384:
--

 Summary: Add support for copying symlinks
 Key: MSHARED-384
 URL: https://jira.codehaus.org/browse/MSHARED-384
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-shared-utils
Affects Versions: maven-shared-utils-0.7
Reporter: Kristian Rosenvold






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-833) Support for annotated JUnit @Category

2014-11-13 Thread Andreas Gudian (JIRA)


[ 
https://jira.codehaus.org/browse/SUREFIRE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356103#comment-356103
 ] 

Andreas Gudian commented on SUREFIRE-833:
-

I would opt to not add a new parameter for this now. For version 3, I still 
envision that we provide some extension points where users can hook in their 
own implementations to allow stuff like:
* detection of tests to run (e.g. from file system, from classpath, from an 
excel sheet, from some server, what ever...)
* filtering the tests to run (use case right here)
* imposing an order on the test cases (e.g. failed first, depending on 
annotations, other crazy stuff)
* test listeners (provider independent)
* ??

We should really create a ticket for that some day... ;)

 Support for annotated JUnit @Category
 -

 Key: SUREFIRE-833
 URL: https://jira.codehaus.org/browse/SUREFIRE-833
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Junit 4.x support
Affects Versions: 2.12
Reporter: Jan Goyvaerts
 Attachments: SUREFIRE-833-spraguep-2.patch, 
 SUREFIRE-833-spraguep.patch


 The current implementation of Surefire seems to look for explicit @Category 
 annotations in the test classes. And will only consider those. Suppose I'd 
 like to add a more concise annotation for this:
 @Category(IntegrationTests.class) == JUnit @Category
 @Target({ElementType.TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Documented
 public @interface IntegrationTest {}
 Annotating my test class with @IntegrationTest does not work. Although I 
 think it looks much better than repeating everywhere in my code 
 @Category(com.foo.bar.IntegrationTests.class). For which I add an 
 additional dependency in the interface class btw.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPMD-192) Regression MPMD-89 is showing up with Maven 2.2.1 again for maven-pmd-plugin-3.3

2014-11-13 Thread Mirko Friedenhagen (JIRA)


 [ 
https://jira.codehaus.org/browse/MPMD-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mirko Friedenhagen updated MPMD-192:


Assignee: Mirko Friedenhagen
 Summary: Regression MPMD-89 is showing up with Maven 2.2.1 again for 
maven-pmd-plugin-3.3  (was: Failure with Maven 2.2.1 during test with release 
artifact for maven-pmd-plugin version 3.3 )

 Regression MPMD-89 is showing up with Maven 2.2.1 again for 
 maven-pmd-plugin-3.3
 

 Key: MPMD-192
 URL: https://jira.codehaus.org/browse/MPMD-192
 Project: Maven PMD Plugin
  Issue Type: Bug
Affects Versions: 3.3
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
 Java version: 1.7.0_21
 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
Assignee: Mirko Friedenhagen
Priority: Blocker
 Fix For: 3.3

 Attachments: build.log


 Unfotrunately i got the following during the test for the release with Maven 
 2.2.1:
 {code}
 [INFO] Building: MPMD-181-benchmark/pom.xml
 [INFO] run script verify.groovy
 [INFO] ..SUCCESS (4.0 s)
 [INFO] Building: MPMD-181-no-benchmark/pom.xml
 [INFO] run script verify.groovy
 [INFO] ..SUCCESS (4.2 s)
 [INFO] Building: MPMD-182/pom.xml
 [INFO] ..SKIPPED due to JRE version
 [INFO] Building: mpmd-80-included/pom.xml
 [INFO] run script verify.groovy
 [INFO] ..SUCCESS (7.4 s)
 [INFO] Building: mpmd-80-not-included/pom.xml
 [INFO] run script verify.groovy
 [INFO] ..SUCCESS (7.4 s)
 [INFO] Building: mpmd-89/pom.xml
 [INFO] ..FAILED (3.5 s)
 [INFO]   The build exited with code 0. See 
 /Users/kama/Downloads/maven-pmd-plugin-3.3/target/it/mpmd-89/build.log for 
 details.
 [INFO] Building: multi-module/pom.xml
 [INFO] run script verify.bsh
 [INFO] ..SUCCESS (8.9 s)
 [WARNING] DEPRECATED [sourceDirectory]: instead use {@link #sourceDirectories}
 [WARNING] DEPRECATED [testSourceDirectory]: instead use {@link 
 #testSourceDirectories}
 [INFO] [checkstyle:check {execution: checkstyle-check}]
 [INFO]
 [INFO] [invoker:verify {execution: integration-test}]
 [INFO] -
 [INFO] Build Summary:
 [INFO]   Passed: 11, Failed: 1, Errors: 0, Skipped: 2
 [INFO] -
 [ERROR] The following builds failed:
 [ERROR] *  mpmd-89/pom.xml
 [INFO] -
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] 1 build failed. See console output above for details.
 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 1 minute 48 seconds
 [INFO] Finished at: Sat Nov 08 11:28:47 CET 2014
 [INFO] Final Memory: 85M/777M
 [INFO] 
 
 {code}
 I have attached the complete log file further analyzis.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPMD-192) Regression MPMD-89 is showing up with Maven 2.2.1 again for maven-pmd-plugin-3.3

2014-11-13 Thread Mirko Friedenhagen (JIRA)


 [ 
https://jira.codehaus.org/browse/MPMD-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mirko Friedenhagen closed MPMD-192.
---

Resolution: Fixed

See http://svn.apache.org/viewvc?view=revisionrevision=1639522. 
* I am not able to fix this and so someone using Maven 2.2.1 needs to stay with 
maven-pmd-plugin-3.2 or adapt her test cases to end on test.

 Regression MPMD-89 is showing up with Maven 2.2.1 again for 
 maven-pmd-plugin-3.3
 

 Key: MPMD-192
 URL: https://jira.codehaus.org/browse/MPMD-192
 Project: Maven PMD Plugin
  Issue Type: Bug
Affects Versions: 3.3
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
 Java version: 1.7.0_21
 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
Assignee: Mirko Friedenhagen
Priority: Blocker
 Fix For: 3.3

 Attachments: build.log


 Unfotrunately i got the following during the test for the release with Maven 
 2.2.1:
 {code}
 [INFO] Building: MPMD-181-benchmark/pom.xml
 [INFO] run script verify.groovy
 [INFO] ..SUCCESS (4.0 s)
 [INFO] Building: MPMD-181-no-benchmark/pom.xml
 [INFO] run script verify.groovy
 [INFO] ..SUCCESS (4.2 s)
 [INFO] Building: MPMD-182/pom.xml
 [INFO] ..SKIPPED due to JRE version
 [INFO] Building: mpmd-80-included/pom.xml
 [INFO] run script verify.groovy
 [INFO] ..SUCCESS (7.4 s)
 [INFO] Building: mpmd-80-not-included/pom.xml
 [INFO] run script verify.groovy
 [INFO] ..SUCCESS (7.4 s)
 [INFO] Building: mpmd-89/pom.xml
 [INFO] ..FAILED (3.5 s)
 [INFO]   The build exited with code 0. See 
 /Users/kama/Downloads/maven-pmd-plugin-3.3/target/it/mpmd-89/build.log for 
 details.
 [INFO] Building: multi-module/pom.xml
 [INFO] run script verify.bsh
 [INFO] ..SUCCESS (8.9 s)
 [WARNING] DEPRECATED [sourceDirectory]: instead use {@link #sourceDirectories}
 [WARNING] DEPRECATED [testSourceDirectory]: instead use {@link 
 #testSourceDirectories}
 [INFO] [checkstyle:check {execution: checkstyle-check}]
 [INFO]
 [INFO] [invoker:verify {execution: integration-test}]
 [INFO] -
 [INFO] Build Summary:
 [INFO]   Passed: 11, Failed: 1, Errors: 0, Skipped: 2
 [INFO] -
 [ERROR] The following builds failed:
 [ERROR] *  mpmd-89/pom.xml
 [INFO] -
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] 1 build failed. See console output above for details.
 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 1 minute 48 seconds
 [INFO] Finished at: Sat Nov 08 11:28:47 CET 2014
 [INFO] Final Memory: 85M/777M
 [INFO] 
 
 {code}
 I have attached the complete log file further analyzis.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-303) Backslash in multi-module project


 [ 
https://jira.codehaus.org/browse/MPIR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MPIR-303.
---

   Resolution: Fixed
Fix Version/s: 2.8
 Assignee: Michael Osipov

Fixed with [r1639526|http://svn.apache.org/r1639526].

 Backslash in multi-module project
 -

 Key: MPIR-303
 URL: https://jira.codehaus.org/browse/MPIR-303
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: plugins
Affects Versions: 2.7
Reporter: Tibor Digana
Assignee: Michael Osipov
 Fix For: 2.8

 Attachments: mpir-303.zip


 We have experienced the backslash in multi-module project Maven Surefire 
 2.18-SNAPSHOT.
 Link should replace Windows \ (gr) with web / (a).



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-279) Wrong hyperlinks on index and modules page

[
https://jira.codehaus.org/browse/MPIR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Osipov closed MPIR-279.
---

Resolution: Fixed
Fix Version/s: 2.8

Fixed with [r1639526|http://svn.apache.org/r1639526].

Wrong hyperlinks on index and modules page
--

Attachments: OG-Platform2.zip

--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MENFORCER-214) Add prerequisites to maven-enforcer-plugin

Karl-Heinz Marbaise created MENFORCER-214:
-

 Summary: Add prerequisites to maven-enforcer-plugin
 Key: MENFORCER-214
 URL: https://jira.codehaus.org/browse/MENFORCER-214
 Project: Maven Enforcer Plugin
  Issue Type: Improvement
  Components: Plugin
Affects Versions: 1.4
Reporter: Karl-Heinz Marbaise
Priority: Trivial


This needs to be done to show the Maven version at the goals overview page 
correctly.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MENFORCER-214) Add prerequisites to maven-enforcer-plugin


 [ 
https://jira.codehaus.org/browse/MENFORCER-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise updated MENFORCER-214:
--

Fix Version/s: 1.4

 Add prerequisites to maven-enforcer-plugin
 --

 Key: MENFORCER-214
 URL: https://jira.codehaus.org/browse/MENFORCER-214
 Project: Maven Enforcer Plugin
  Issue Type: Improvement
  Components: Plugin
Affects Versions: 1.4
Reporter: Karl-Heinz Marbaise
Priority: Trivial
 Fix For: 1.4


 This needs to be done to show the Maven version at the goals overview page 
 correctly.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MENFORCER-214) Add prerequisites to maven-enforcer-plugin


 [ 
https://jira.codehaus.org/browse/MENFORCER-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise closed MENFORCER-214.
-

Resolution: Fixed
  Assignee: Karl-Heinz Marbaise

Fixed in [r1639528|http://svn.apache.org/r1639528]

 Add prerequisites to maven-enforcer-plugin
 --

 Key: MENFORCER-214
 URL: https://jira.codehaus.org/browse/MENFORCER-214
 Project: Maven Enforcer Plugin
  Issue Type: Improvement
  Components: Plugin
Affects Versions: 1.4
Reporter: Karl-Heinz Marbaise
Assignee: Karl-Heinz Marbaise
Priority: Trivial
 Fix For: 1.4


 This needs to be done to show the Maven version at the goals overview page 
 correctly.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-833) Support for annotated JUnit @Category


[ 
https://jira.codehaus.org/browse/SUREFIRE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356108#comment-356108
 ] 

Tibor Digana commented on SUREFIRE-833:
---

right Andreas. In that case we need to write a concept for 3.0. It should be 
done in a convenient way, e.g. mailing list.

 Support for annotated JUnit @Category
 -

 Key: SUREFIRE-833
 URL: https://jira.codehaus.org/browse/SUREFIRE-833
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Junit 4.x support
Affects Versions: 2.12
Reporter: Jan Goyvaerts
 Attachments: SUREFIRE-833-spraguep-2.patch, 
 SUREFIRE-833-spraguep.patch


 The current implementation of Surefire seems to look for explicit @Category 
 annotations in the test classes. And will only consider those. Suppose I'd 
 like to add a more concise annotation for this:
 @Category(IntegrationTests.class) == JUnit @Category
 @Target({ElementType.TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Documented
 public @interface IntegrationTest {}
 Annotating my test class with @IntegrationTest does not work. Although I 
 think it looks much better than repeating everywhere in my code 
 @Category(com.foo.bar.IntegrationTests.class). For which I add an 
 additional dependency in the interface class btw.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-242) Incorrect translations list for GPL v3 (illegible letters for Catalan and Arabic)


 [ 
https://jira.codehaus.org/browse/MPIR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reassigned MPIR-242:
---

Assignee: Michael Osipov

 Incorrect translations list for GPL v3 (illegible letters for Catalan and 
 Arabic)
 -

 Key: MPIR-242
 URL: https://jira.codehaus.org/browse/MPIR-242
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: license
Affects Versions: 2.4
 Environment: Apache Maven 3.0.3 
 (rNON-CANONICAL_2011-04-10_05-06_zfsdt; 2011-04-10 05:06:31+0200)
 Maven home: /usr/local/apache-maven/apache-maven-3.0.3
 Java version: 1.6.0_18, vendor: Sun Microsystems Inc.
 Java home: /usr/lib/jvm/java-6-openjdk/jre
 Default locale: de_DE, platform encoding: UTF-8
 OS name: linux, version: 2.6.18-028stab092.1, arch: amd64, family: 
 unix
Reporter: Heinrich Schuchardt
Assignee: Michael Osipov
Priority: Minor
 Attachments: license.html, pom.xml, screenshot2.png


 Dear maintainer,
 the license report for GPL v3 contains a translation list. This translation 
 list contains illegible letters for languages Catalan and Arabic:
 Skip translations list
 English [en]
 ÃÂ§Ã#132;ÃÂ¹ÃÂ±ÃÂ¨Ã#138;ÃÂ© [ar]
 catalÃ  [ca]
 Deutsch [de]
 Use appended pom.xml for testing.
 Best regards
 Heinrich Schuchardt



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-242) Incorrect translations list for GPL v3 (illegible letters for Catalan and Arabic)


[ 
https://jira.codehaus.org/browse/MPIR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356109#comment-356109
 ] 

Michael Osipov commented on MPIR-242:
-

Hi Heinrich, the issue is quiet stupid simple. The License Report assumes that 
is downloads some content from a URL without knowning that his is a HTML file 
which carries already an encoding flag.

The easiest fix is: Try with {{project.build.sourceEncoding}}, if not provided 
default to platform or UTF-8?

The best is to take the encoding in the header into account.

 Incorrect translations list for GPL v3 (illegible letters for Catalan and 
 Arabic)
 -

 Key: MPIR-242
 URL: https://jira.codehaus.org/browse/MPIR-242
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: license
Affects Versions: 2.4
 Environment: Apache Maven 3.0.3 
 (rNON-CANONICAL_2011-04-10_05-06_zfsdt; 2011-04-10 05:06:31+0200)
 Maven home: /usr/local/apache-maven/apache-maven-3.0.3
 Java version: 1.6.0_18, vendor: Sun Microsystems Inc.
 Java home: /usr/lib/jvm/java-6-openjdk/jre
 Default locale: de_DE, platform encoding: UTF-8
 OS name: linux, version: 2.6.18-028stab092.1, arch: amd64, family: 
 unix
Reporter: Heinrich Schuchardt
Priority: Minor
 Attachments: license.html, pom.xml, screenshot2.png


 Dear maintainer,
 the license report for GPL v3 contains a translation list. This translation 
 list contains illegible letters for languages Catalan and Arabic:
 Skip translations list
 English [en]
 ÃÂ§Ã#132;ÃÂ¹ÃÂ±ÃÂ¨Ã#138;ÃÂ© [ar]
 catalÃ  [ca]
 Deutsch [de]
 Use appended pom.xml for testing.
 Best regards
 Heinrich Schuchardt



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-263) JDK Rev not correctly determined if compile source is an interpolated property


 [ 
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reassigned MPIR-263:
---

Assignee: Michael Osipov

 JDK Rev not correctly determined if compile source is an interpolated property
 --

 Key: MPIR-263
 URL: https://jira.codehaus.org/browse/MPIR-263
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: summary
Affects Versions: 2.6
 Environment: Maven 2.2.1 and 3.0.3
Reporter: Michael Osipov
Assignee: Michael Osipov

 If you define {{maven.compiler.source}} in the {{properties}} section or 
 per command line, that value is not taken into account in report generation. 
 The source and target version is retrieved from the static model.
 I have filed a similar issue with the JavaDoc Pluing MJAVADOC-310.
 If someone could use an interpolated model that would solve the issue. At 
 least this should be in the FAQ list.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-242) Incorrect translations list for GPL v3 (illegible letters for Catalan and Arabic)


[ 
https://jira.codehaus.org/browse/MPIR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356109#comment-356109
 ] 

Michael Osipov edited comment on MPIR-242 at 11/13/14 4:25 PM:
---

Hi Heinrich, the issue is quiet stupid and simple. The License Report assumes 
that it downloads some content from a URL without knowning that his is a HTML 
file which carries already encoding information.

The easiest fix is: Try with {{project.build.sourceEncoding}}, if not provided 
default to platform or UTF-8?

The best is to take the encoding in the header into account.


was (Author: michael-o):
Hi Heinrich, the issue is quiet stupid simple. The License Report assumes that 
is downloads some content from a URL without knowning that his is a HTML file 
which carries already an encoding flag.

The easiest fix is: Try with {{project.build.sourceEncoding}}, if not provided 
default to platform or UTF-8?

The best is to take the encoding in the header into account.

 Incorrect translations list for GPL v3 (illegible letters for Catalan and 
 Arabic)
 -

 Key: MPIR-242
 URL: https://jira.codehaus.org/browse/MPIR-242
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: license
Affects Versions: 2.4
 Environment: Apache Maven 3.0.3 
 (rNON-CANONICAL_2011-04-10_05-06_zfsdt; 2011-04-10 05:06:31+0200)
 Maven home: /usr/local/apache-maven/apache-maven-3.0.3
 Java version: 1.6.0_18, vendor: Sun Microsystems Inc.
 Java home: /usr/lib/jvm/java-6-openjdk/jre
 Default locale: de_DE, platform encoding: UTF-8
 OS name: linux, version: 2.6.18-028stab092.1, arch: amd64, family: 
 unix
Reporter: Heinrich Schuchardt
Assignee: Michael Osipov
Priority: Minor
 Attachments: license.html, pom.xml, screenshot2.png


 Dear maintainer,
 the license report for GPL v3 contains a translation list. This translation 
 list contains illegible letters for languages Catalan and Arabic:
 Skip translations list
 English [en]
 ÃÂ§Ã#132;ÃÂ¹ÃÂ±ÃÂ¨Ã#138;ÃÂ© [ar]
 catalÃ  [ca]
 Deutsch [de]
 Use appended pom.xml for testing.
 Best regards
 Heinrich Schuchardt



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MPIR-242) Incorrect translations list for GPL v3 (illegible letters for Catalan and Arabic)


 [ 
https://jira.codehaus.org/browse/MPIR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MPIR-242:


Attachment: pom.xml

POM with Maven 3.1.x compat.

 Incorrect translations list for GPL v3 (illegible letters for Catalan and 
 Arabic)
 -

 Key: MPIR-242
 URL: https://jira.codehaus.org/browse/MPIR-242
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: license
Affects Versions: 2.4
 Environment: Apache Maven 3.0.3 
 (rNON-CANONICAL_2011-04-10_05-06_zfsdt; 2011-04-10 05:06:31+0200)
 Maven home: /usr/local/apache-maven/apache-maven-3.0.3
 Java version: 1.6.0_18, vendor: Sun Microsystems Inc.
 Java home: /usr/lib/jvm/java-6-openjdk/jre
 Default locale: de_DE, platform encoding: UTF-8
 OS name: linux, version: 2.6.18-028stab092.1, arch: amd64, family: 
 unix
Reporter: Heinrich Schuchardt
Assignee: Michael Osipov
Priority: Minor
 Attachments: license.html, pom.xml, pom.xml, screenshot2.png


 Dear maintainer,
 the license report for GPL v3 contains a translation list. This translation 
 list contains illegible letters for languages Catalan and Arabic:
 Skip translations list
 English [en]
 ÃÂ§Ã#132;ÃÂ¹ÃÂ±ÃÂ¨Ã#138;ÃÂ© [ar]
 catalÃ  [ca]
 Deutsch [de]
 Use appended pom.xml for testing.
 Best regards
 Heinrich Schuchardt



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element


[ 
https://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356117#comment-356117
 ] 

Tibor Digana commented on SUREFIRE-649:
---

As far as I remember the Spring you can call a method of A bean in B bean.
bean 
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=locationvaluedatabase.properties/value/property
/bean
bean id=conv class=your.company.Converter

bean id=dataSource ...
property name=password value=#{conv.treatEmptyAsNull(${jdbc.password})} /
/bean

The fix in surefire was done in the same way with environment variables and 
system properties, so that java.lang.System#getenv(String) and 
#getProperty(String) return null only for unspecified properties.
The other issue of Maven itself is that null or not existing POM properties are 
always interpreted as empty string, so yet there's no way to distinguish 
between null and empty string.

 Might be impossible to have empty strings in systemPropertyVariables element
 

 Key: SUREFIRE-649
 URL: https://jira.codehaus.org/browse/SUREFIRE-649
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Tibor Digana
Priority: Minor
 Fix For: 2.18

 Attachments: surefireEmptyStringIssue.tar.gz


 This stanza:
 systemProperties
   property
 nameemptyProperty/name
 value/value
   /property
 /systemProperties
 ...yields  from System.getProperty(emptyProperty).
 This (supposedly better) stanza:
 systemPropertyVariables
   emptyProperty/emptyProperty
 /systemPropertyVariables
 ...yields null from System.getProperty(emptyProperty).
 A test case is attached that demonstrates the issue.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJAVADOC-414) Artifacts missing from test classpath.


 [ 
https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte reopened MJAVADOC-414:



Reopening since the plugin still does not produce correct test javadocs. Please 
see the updated example project demonstrating the issue. Executing 'mvn 
javadoc:test-javadoc' the plugin produces

{code}
1 warning
[WARNING] Javadoc Warnings
[WARNING] /tmp/MJAVADOC-414/src/test/java/localhost/test/AppTest.java:6: error: 
cannot find symbol
[WARNING] import localhost.App;
[WARNING] ^
[WARNING] symbol:   class App
[WARNING] location: package localhost
{code}

Downgrading the plugin to version 2.9.1, no such warnings are produced.


 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10, test documentation fails to 
 find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJAVADOC-414) Artifacts missing from test classpath.


 [ 
https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MJAVADOC-414:
---

Attachment: mjavadoc-414.zip

Updated the example project demonstrating the issue. Executing 'mvn 
javadoc:test-javadoc' plugin version 2.10.1 produces the following warning:

{code}
1 warning
[WARNING] Javadoc Warnings
[WARNING] /tmp/MJAVADOC-414/src/test/java/localhost/test/AppTest.java:6: error: 
cannot find symbol
[WARNING] import localhost.App;
[WARNING] ^
[WARNING] symbol:   class App
[WARNING] location: package localhost
{code}

Downgrading to version 2.9.1 no such warnings are produced.


 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip, mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10, test documentation fails to 
 find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJAVADOC-414) Artifacts missing from test classpath.


 [ 
https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MJAVADOC-414:
---

Affects Version/s: (was: 2.10)

 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10.1
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip, mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10, test documentation fails to 
 find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJAVADOC-414) Artifacts missing from test classpath.


 [ 
https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MJAVADOC-414:
---

Affects Version/s: 2.10.1

 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10.1
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip, mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10, test documentation fails to 
 find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJAVADOC-414) Artifacts missing from test classpath.


 [ 
https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MJAVADOC-414:
---

Description: Upgrading the javadoc plugin to version 2.10 or 2.10.1, test 
documentation fails to find classpath elements from 'test' scope.  (was: 
Upgrading the javadoc plugin to version 2.10, test documentation fails to find 
classpath elements from 'test' scope.)

 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10.1
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip, mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10 or 2.10.1, test documentation 
 fails to find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSOURCES-77) Upgrade maven-archiver to 2.6

Karl-Heinz Marbaise created MSOURCES-77:
---

 Summary: Upgrade maven-archiver to 2.6
 Key: MSOURCES-77
 URL: https://jira.codehaus.org/browse/MSOURCES-77
 Project: Maven Source Plugin
  Issue Type: Improvement
Affects Versions: next-release
Reporter: Karl-Heinz Marbaise
Priority: Minor


[Release Notes for maven-archiver 
2.6|http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=18325]

* Bugs:
**[MSHARED-241] - Use last plexus-archiver version
** [MSHARED-360] - Upgrade plexus-archiver to 2.6.1 (was 2.6) and plexus-utils 
to 3.0.18 for java7+ symlink support
** [MSHARED-368] - Update plexus-interpolation to 1.21 to avoid potential 
thread safety issues
* Improvements:
** [MSHARED-224] - Add documentation on the useUniqueVersions to the index page
** [MSHARED-270] - Add Implementation-URL to DefaultImplementationEntries
** [MSHARED-273] - Update documentation for the Created-By manifest entry
** [MSHARED-363] - Update version of plexus-archiver to 2.7
Tasks:
** [MSHARED-373] - Upgrade Maven baseline to 2.2.1
** [MSHARED-374] - Upgrade Plexus Archiver to 2.8.1
** [MSHARED-375] - Upgrade Plexus Utils to 3.0.20
** [MSHARED-376] - Upgrade Maven Shared Utils to 0.7




--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSOURCES-77) Upgrade maven-archiver to 2.6


 [ 
https://jira.codehaus.org/browse/MSOURCES-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise updated MSOURCES-77:


Fix Version/s: next-release

 Upgrade maven-archiver to 2.6
 -

 Key: MSOURCES-77
 URL: https://jira.codehaus.org/browse/MSOURCES-77
 Project: Maven Source Plugin
  Issue Type: Improvement
Affects Versions: next-release
Reporter: Karl-Heinz Marbaise
Priority: Minor
 Fix For: next-release


 [Release Notes for maven-archiver 
 2.6|http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=18325]
 * Bugs:
 **[MSHARED-241] - Use last plexus-archiver version
 ** [MSHARED-360] - Upgrade plexus-archiver to 2.6.1 (was 2.6) and 
 plexus-utils to 3.0.18 for java7+ symlink support
 ** [MSHARED-368] - Update plexus-interpolation to 1.21 to avoid potential 
 thread safety issues
 * Improvements:
 ** [MSHARED-224] - Add documentation on the useUniqueVersions to the index 
 page
 ** [MSHARED-270] - Add Implementation-URL to DefaultImplementationEntries
 ** [MSHARED-273] - Update documentation for the Created-By manifest entry
 ** [MSHARED-363] - Update version of plexus-archiver to 2.7
 Tasks:
 ** [MSHARED-373] - Upgrade Maven baseline to 2.2.1
 ** [MSHARED-374] - Upgrade Plexus Archiver to 2.8.1
 ** [MSHARED-375] - Upgrade Plexus Utils to 3.0.20
 ** [MSHARED-376] - Upgrade Maven Shared Utils to 0.7



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSOURCES-77) Upgrade maven-archiver from 2.5 to 2.6


 [ 
https://jira.codehaus.org/browse/MSOURCES-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise updated MSOURCES-77:


Summary: Upgrade maven-archiver from 2.5 to 2.6  (was: Upgrade 
maven-archiver to 2.6)

 Upgrade maven-archiver from 2.5 to 2.6
 --

 Key: MSOURCES-77
 URL: https://jira.codehaus.org/browse/MSOURCES-77
 Project: Maven Source Plugin
  Issue Type: Improvement
Affects Versions: next-release
Reporter: Karl-Heinz Marbaise
Priority: Minor
 Fix For: next-release


 [Release Notes for maven-archiver 
 2.6|http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=18325]
 * Bugs:
 **[MSHARED-241] - Use last plexus-archiver version
 ** [MSHARED-360] - Upgrade plexus-archiver to 2.6.1 (was 2.6) and 
 plexus-utils to 3.0.18 for java7+ symlink support
 ** [MSHARED-368] - Update plexus-interpolation to 1.21 to avoid potential 
 thread safety issues
 * Improvements:
 ** [MSHARED-224] - Add documentation on the useUniqueVersions to the index 
 page
 ** [MSHARED-270] - Add Implementation-URL to DefaultImplementationEntries
 ** [MSHARED-273] - Update documentation for the Created-By manifest entry
 ** [MSHARED-363] - Update version of plexus-archiver to 2.7
 Tasks:
 ** [MSHARED-373] - Upgrade Maven baseline to 2.2.1
 ** [MSHARED-374] - Upgrade Plexus Archiver to 2.8.1
 ** [MSHARED-375] - Upgrade Plexus Utils to 3.0.20
 ** [MSHARED-376] - Upgrade Maven Shared Utils to 0.7



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSOURCES-77) Upgrade maven-archiver from 2.5 to 2.6


 [ 
https://jira.codehaus.org/browse/MSOURCES-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise closed MSOURCES-77.
---

Resolution: Fixed
  Assignee: Karl-Heinz Marbaise

Fixed in [r1639562|http://svn.apache.org/r1639562].

 Upgrade maven-archiver from 2.5 to 2.6
 --

 Key: MSOURCES-77
 URL: https://jira.codehaus.org/browse/MSOURCES-77
 Project: Maven Source Plugin
  Issue Type: Improvement
Affects Versions: next-release
Reporter: Karl-Heinz Marbaise
Assignee: Karl-Heinz Marbaise
Priority: Minor
 Fix For: next-release


 [Release Notes for maven-archiver 
 2.6|http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=18325]
 * Bugs:
 **[MSHARED-241] - Use last plexus-archiver version
 ** [MSHARED-360] - Upgrade plexus-archiver to 2.6.1 (was 2.6) and 
 plexus-utils to 3.0.18 for java7+ symlink support
 ** [MSHARED-368] - Update plexus-interpolation to 1.21 to avoid potential 
 thread safety issues
 * Improvements:
 ** [MSHARED-224] - Add documentation on the useUniqueVersions to the index 
 page
 ** [MSHARED-270] - Add Implementation-URL to DefaultImplementationEntries
 ** [MSHARED-273] - Update documentation for the Created-By manifest entry
 ** [MSHARED-363] - Update version of plexus-archiver to 2.7
 Tasks:
 ** [MSHARED-373] - Upgrade Maven baseline to 2.2.1
 ** [MSHARED-374] - Upgrade Plexus Archiver to 2.8.1
 ** [MSHARED-375] - Upgrade Plexus Utils to 3.0.20
 ** [MSHARED-376] - Upgrade Maven Shared Utils to 0.7



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-733) Plugin no longer prepends final name when packaging files specified using 'files/file' elements.

Christian Schulte created MASSEMBLY-733:
---

 Summary: Plugin no longer prepends final name when packaging files 
specified using 'files/file' elements.
 Key: MASSEMBLY-733
 URL: https://jira.codehaus.org/browse/MASSEMBLY-733
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.1
 Environment: $ mvn -version
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 
2014-08-11T22:58:10+02:00)
Java version: 1.7.0_65, vendor: Oracle Corporation
Default locale: de_DE, platform encoding: UTF-8

Reporter: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-733) Plugin no longer prepends final name when packaging files specified using 'files/file' elements.


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MASSEMBLY-733:


Attachment: MASSEMBLY-733.zip

Example project demonstrating the issue. Executing 'mvn package', plugin 
version 2.5.1 creates the following directory structure in the archives:

{code}
$ unzip target/my-final-name-bin.zip 
Archive:  target/my-final-name-bin.zip
   creating: root/
  inflating: root/bin.xml
{code}

{code}
$ tar xfvz target/my-final-name-bin.tar.gz   
root/bin.xml
{code}

{code}
$ tar xfvj target/my-final-name-bin.tar.bz2
root/bin.xml
{code}

Downgrading the plugin to version 2.4.1, the correct directory structure is 
created:

{code}
$ unzip target/my-final-name-bin.zip
Archive:  target/my-final-name-bin.zip
   creating: my-final-name/
   creating: my-final-name/root/
  inflating: my-final-name/root/bin.xml 
{code}

{code}
$ tar xfvz target/my-final-name-bin.tar.gz   
my-final-name/root/bin.xml
{code}

{code}
$ tar xfvj target/my-final-name-bin.tar.bz2
my-final-name/root/bin.xml
{code}

Directory 'my-final-name' is missing using version 2.5.1.

 Plugin no longer prepends final name when packaging files specified using 
 'files/file' elements.
 

 Key: MASSEMBLY-733
 URL: https://jira.codehaus.org/browse/MASSEMBLY-733
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.1
 Environment: $ mvn -version
 Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 
 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: MASSEMBLY-733.zip






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MASSEMBLY-671) Cryptic debug warning message needs improvement and/or documentation