[jira] (MASSEMBLY-645) File name of dependency depends on how it is reachable
[ https://jira.codehaus.org/browse/MASSEMBLY-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-645: - Comment: was deleted (was: The upgrade of archiver to 2.6.1 will probably fix this ) > File name of dependency depends on how it is reachable > -- > > Key: MASSEMBLY-645 > URL: https://jira.codehaus.org/browse/MASSEMBLY-645 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.4 >Reporter: Tuure Laurinolli >Priority: Critical > > Please see demonstration at https://github.com/tazle/maven-issue-demo > After mvn package, the resulting maven-issue-demo-1.0.0-SNAPSHOT-bin.zip > contains the following libraries: > maven-issue-demo-1.0.0-SNAPSHOT/lib/httpcore-4.3-alpha2-SNAPSHOT.jar > maven-issue-demo-1.0.0-SNAPSHOT/lib/httpclient-4.3-alpha2-20130227.160252-28.jar > For some reason httpcore has a -SNAPSHOT version whereas httpclient has a > unique version. This is clearly not desirable, since e.g. the classpath > generator in JAR plugin generates either -SNAPSHOT names or unique names but > not both. > Some analysis: > Originally versions of both libraries are unique. During resolution, some are > changed to -SNAPSHOT versions instead. This appears to affect packages that > are both direct and transitive dependencies. > Some debug output from a modified assembly plugin, with additional debug > output: > [DEBUG] Artifacts before resolution: > [DEBUG] artifact: org.apache.httpcomponents:httpcore:jar:4.3-alpha2-SNAPSHOT, > version: 4.3-alpha2-20130220.230238-15, base version: 4.3-alpha2-SNAPSHOT, > resolved: true, scope: compile > [DEBUG] artifact: > org.apache.httpcomponents:httpclient:jar:4.3-alpha2-SNAPSHOT, version: > 4.3-alpha2-20130227.160252-28, base version: 4.3-alpha2-SNAPSHOT, resolved: > true, scope: compile > [DEBUG] Resolving project dependencies transitively. > [DEBUG] maven-issue-demo:maven-issue-demo:jar:1.0.0-SNAPSHOT (selected for > null) > [DEBUG] org.apache.httpcomponents:httpcore:jar:4.3-alpha2-SNAPSHOT:compile > (selected for compile) > [DEBUG] > org.apache.httpcomponents:httpclient:jar:4.3-alpha2-SNAPSHOT:compile > (selected for compile) > [DEBUG] org.apache.httpcomponents:httpcore:jar:4.3-alpha1:compile > (removed - nearer found: 4.3-alpha2-SNAPSHOT) > [DEBUG] commons-logging:commons-logging:jar:1.1.1:compile (selected for > compile) > [DEBUG] commons-codec:commons-codec:jar:1.6:compile (selected for compile) > [DEBUG] While resolving dependencies of > maven-issue-demo:maven-issue-demo:jar:1.0.0-SNAPSHOT: > [DEBUG] Statistics for Scope filter [null-scope=true, compile=true, > runtime=true, test=false, provided=false, system=false] > [DEBUG] The following scope filters were not used: > o Runtime > o Test > o Provided > o System > [DEBUG] resolved artifact: > org.apache.httpcomponents:httpcore:jar:4.3-alpha2-SNAPSHOT, version: > 4.3-alpha2-SNAPSHOT, baseVersion: 4.3-alpha2-SNAPSHOT > [DEBUG] resolved artifact: > org.apache.httpcomponents:httpclient:jar:4.3-alpha2-SNAPSHOT, version: > 4.3-alpha2-20130227.160252-28, baseVersion: 4.3-alpha2-SNAPSHOT > [DEBUG] resolved artifact: commons-logging:commons-logging:jar:1.1.1, > version: 1.1.1, baseVersion: 1.1.1 > [DEBUG] resolved artifact: commons-codec:commons-codec:jar:1.6, version: 1.6, > baseVersion: 1.6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-571) moduleSet dependencies processed incorrectly
[
https://jira.codehaus.org/browse/MASSEMBLY-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-571.
Resolution: Not A Bug
Fix Version/s: 2.5.1
Assignee: Kristian Rosenvold
The outputFileMapping you have specified is expected to write to the artifact
output, so the behaviour is incorrect. Due the fix for MASSEMBLY-727 the
recommended solution for this is probably to just remove the
outputFileNameMapping element altogether since the new default value is
probably sufficient for most users
> moduleSet dependencies processed incorrectly
>
>
> Key: MASSEMBLY-571
> URL: https://jira.codehaus.org/browse/MASSEMBLY-571
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: moduleSet
>Affects Versions: 2.2.1
> Environment: any
>Reporter: Paul Green
>Assignee: Kristian Rosenvold
>Priority: Critical
> Fix For: 2.5.1
>
>
> Following configuration:
> {code:xml}
>
>
> com.example:extra-hiper-app
>
>
>
> my-app.${extension}
> output/lib
> false
> true
>
>
>
> ${artifactId}-${version}.${extension}
>
>
>
>
> {code}
> Results in bunch of:
> {noformat}
> [INFO] lib/my-app-0.0.1.${extension} already added, skipping
> {noformat}
> with assembly plugin in version 2.2.1
> NOTE: but it works correctly (and as expected with version: 2.2-beta-1)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-571) moduleSet dependencies processed incorrectly
[
https://jira.codehaus.org/browse/MASSEMBLY-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355522#comment-355522
]
Kristian Rosenvold edited comment on MASSEMBLY-571 at 11/4/14 2:27 AM:
---
The outputFileMapping you have specified is expected to write to the artifact
output, so the behaviour is correct. Due the fix for MASSEMBLY-727 the
recommended solution for this is probably to just remove the
outputFileNameMapping element altogether since the new default value is
probably sufficient for most users
was (Author: krosenvold):
The outputFileMapping you have specified is expected to write to the artifact
output, so the behaviour is incorrect. Due the fix for MASSEMBLY-727 the
recommended solution for this is probably to just remove the
outputFileNameMapping element altogether since the new default value is
probably sufficient for most users
> moduleSet dependencies processed incorrectly
>
>
> Key: MASSEMBLY-571
> URL: https://jira.codehaus.org/browse/MASSEMBLY-571
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: moduleSet
>Affects Versions: 2.2.1
> Environment: any
>Reporter: Paul Green
>Assignee: Kristian Rosenvold
>Priority: Critical
> Fix For: 2.5.1
>
>
> Following configuration:
> {code:xml}
>
>
> com.example:extra-hiper-app
>
>
>
> my-app.${extension}
> output/lib
> false
> true
>
>
>
> ${artifactId}-${version}.${extension}
>
>
>
>
> {code}
> Results in bunch of:
> {noformat}
> [INFO] lib/my-app-0.0.1.${extension} already added, skipping
> {noformat}
> with assembly plugin in version 2.2.1
> NOTE: but it works correctly (and as expected with version: 2.2-beta-1)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-727) Implied dependencysets have incorrect outputfilemapping
[ https://jira.codehaus.org/browse/MASSEMBLY-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-727. Resolution: Fixed Assignee: Kristian Rosenvold Fixed in r1636535. IT updated > Implied dependencysets have incorrect outputfilemapping > --- > > Key: MASSEMBLY-727 > URL: https://jira.codehaus.org/browse/MASSEMBLY-727 > Project: Maven Assembly Plugin > Issue Type: Bug >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > > An implied dependency set from a module set inherits the outputmapping of the > binaries element. Can be seen from massembly-395 testcase not working wihtout > having a specified outputmapping -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-727) Implied dependencysets have incorrect outputfilemapping
[ https://jira.codehaus.org/browse/MASSEMBLY-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-727: - Fix Version/s: 2.5.1 > Implied dependencysets have incorrect outputfilemapping > --- > > Key: MASSEMBLY-727 > URL: https://jira.codehaus.org/browse/MASSEMBLY-727 > Project: Maven Assembly Plugin > Issue Type: Bug >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.5.1 > > > An implied dependency set from a module set inherits the outputmapping of the > binaries element. Can be seen from massembly-395 testcase not working wihtout > having a specified outputmapping -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-211) wildcard ignore in requireReleaseDeps
Arne Brix created MENFORCER-211: --- Summary: wildcard ignore in requireReleaseDeps Key: MENFORCER-211 URL: https://jira.codehaus.org/browse/MENFORCER-211 Project: Maven Enforcer Plugin Issue Type: Improvement Affects Versions: 1.3.1 Reporter: Arne Brix Priority: Minor the bannedDependencies rule allows one to specify artifact lists using wildcards: org.apache.*:maven-*:* we are using the requireReleaseDeps rule for our release builds. We would like to exclude dependencies with scope test because they don't contribute to the final artifact. We tried the syntax documented for bannedDependencies, but it didn't work: No Snapshots Allowed! true *:*:*:*:test true -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-211) wildcard ignore in requireReleaseDeps
[
https://jira.codehaus.org/browse/MENFORCER-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arne Brix updated MENFORCER-211:
Description:
the bannedDependencies rule allows one to specify artifact lists using
wildcards:
org.apache.*:maven-*:*
we are using the requireReleaseDeps rule for our release builds.
We would like to exclude dependencies with scope test because they don't
contribute to the final artifact.
We tried the syntax documented for bannedDependencies, but it didn't work:
{code:xml}
No Snapshots Allowed!
true
*:*:*:*:test
true
{code}
was:
the bannedDependencies rule allows one to specify artifact lists using
wildcards:
org.apache.*:maven-*:*
we are using the requireReleaseDeps rule for our release builds.
We would like to exclude dependencies with scope test because they don't
contribute to the final artifact.
We tried the syntax documented for bannedDependencies, but it didn't work:
No Snapshots Allowed!
true
*:*:*:*:test
true
> wildcard ignore in requireReleaseDeps
> -
>
> Key: MENFORCER-211
> URL: https://jira.codehaus.org/browse/MENFORCER-211
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Affects Versions: 1.3.1
>Reporter: Arne Brix
>Priority: Minor
>
> the bannedDependencies rule allows one to specify artifact lists using
> wildcards:
> org.apache.*:maven-*:*
> we are using the requireReleaseDeps rule for our release builds.
> We would like to exclude dependencies with scope test because they don't
> contribute to the final artifact.
> We tried the syntax documented for bannedDependencies, but it didn't work:
> {code:xml}
>
>
>
> No Snapshots Allowed!
> true
>
> *:*:*:*:test
>
>
>
> true
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-211) wildcard ignore in requireReleaseDeps
[
https://jira.codehaus.org/browse/MENFORCER-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arne Brix updated MENFORCER-211:
Description:
the bannedDependencies rule allows one to specify artifact lists using
wildcards:
{code:xml}
org.apache.*:maven-*:*
{code}
we are using the requireReleaseDeps rule for our release builds.
We would like to exclude dependencies with scope test because they don't
contribute to the final artifact.
We tried the syntax documented for bannedDependencies, but it didn't work:
{code:xml}
No Snapshots Allowed!
true
*:*:*:*:test
true
{code}
was:
the bannedDependencies rule allows one to specify artifact lists using
wildcards:
org.apache.*:maven-*:*
we are using the requireReleaseDeps rule for our release builds.
We would like to exclude dependencies with scope test because they don't
contribute to the final artifact.
We tried the syntax documented for bannedDependencies, but it didn't work:
{code:xml}
No Snapshots Allowed!
true
*:*:*:*:test
true
{code}
> wildcard ignore in requireReleaseDeps
> -
>
> Key: MENFORCER-211
> URL: https://jira.codehaus.org/browse/MENFORCER-211
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Affects Versions: 1.3.1
>Reporter: Arne Brix
>Priority: Minor
>
> the bannedDependencies rule allows one to specify artifact lists using
> wildcards:
> {code:xml}
> org.apache.*:maven-*:*
> {code}
> we are using the requireReleaseDeps rule for our release builds.
> We would like to exclude dependencies with scope test because they don't
> contribute to the final artifact.
> We tried the syntax documented for bannedDependencies, but it didn't work:
> {code:xml}
>
>
>
> No Snapshots Allowed!
> true
>
> *:*:*:*:test
>
>
>
> true
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-236) Compilation error due to MCOMPILER-157 in deploy phase
[
https://jira.codehaus.org/browse/MCOMPILER-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355541#comment-355541
]
Petter Måhlén commented on MCOMPILER-236:
-
I'm seeing this as well without explicitly configuring an annotation processor
for the compiler plugin. I am using AutoValue, though, meaning that there's at
least one annotation processor at work. FWIW, compilation usually works when I
do 'clean compile', but not just 'compile'.
> Compilation error due to MCOMPILER-157 in deploy phase
> --
>
> Key: MCOMPILER-236
> URL: https://jira.codehaus.org/browse/MCOMPILER-236
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Maven 3.2.3, Java 1.8.0_25
>Reporter: Federico Gaule
>
> After upgrading from 3.1 to 3.2 i'm experiencing compilation errors when
> running deploy phase.
> It's a mult module project where plugin is configured in master pom:
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
>
> ${compiler.version}
> ${compiler.version}
> UTF-8
>
>
> -parameters
>
>
> {code}
> And in one of the modules like this:
> {code:xml}
>
>
> org.apache.maven.plugins
>
> maven-compiler-plugin
>
>
>
>
>
> org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor
>
>
>
>
> {code}
> Common builds are all ok, but when using deploy phase i got a compiler error
> {noformat}
> An exception has occurred in the compiler (1.8.0_25). Please file a bug at
> the Java Developer Connection (http://java.sun.com/webapps/bugreport) after
> checking the Bug Parade for duplicates. Include your program and the
> following diagnostic in your report. Thank you.
> java.lang.IllegalStateException: endPosTable already set
> at
> com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
> at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
> at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
> at
> com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
> at
> com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.(JavacProcessingEnvironment.java:892)
> at
> com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
> at
> com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
> at
> com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
> at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
> at com.sun.tools.javac.main.Main.compile(Main.java:523)
> at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
> at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
> at
> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
> at
> org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169)
> at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:823)
> at
> org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.Lifecyc
[jira] (MPLUGIN-273) Classes using Java 8 Lambdas cause goal descriptor to fail
[ https://jira.codehaus.org/browse/MPLUGIN-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35#comment-35 ] Brian Trezise commented on MPLUGIN-273: --- I'm experiencing this same issue. See my question posted on StackOverflow for details: http://stackoverflow.com/questions/26737447/maven-plugin-build-fails-when-lambdas-are-used Should I post a new bug? > Classes using Java 8 Lambdas cause goal descriptor to fail > -- > > Key: MPLUGIN-273 > URL: https://jira.codehaus.org/browse/MPLUGIN-273 > Project: Maven Plugin Tools > Issue Type: Bug > Components: maven-plugin-annotations >Affects Versions: 3.3 > Environment: Maven 3.2.3, maven-plugin-annotations 3.3 >Reporter: Martin Dreier >Assignee: Robert Scholte > Attachments: callstack.txt, java8-maven-plugin.zip > > > When the annotations scanner encounters a class which uses Java 8 Lambdas, > the scanning fails. Removing the lambda construct resolves the error. > Reproduction: > 1) Extract the attached maven project > 2) run mvn install in the project -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-273) Classes using Java 8 Lambdas cause goal descriptor to fail
[ https://jira.codehaus.org/browse/MPLUGIN-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Trezise updated MPLUGIN-273: -- Comment: was deleted (was: I'm experiencing this same issue. See my question posted on StackOverflow for details: http://stackoverflow.com/questions/26737447/maven-plugin-build-fails-when-lambdas-are-used Should I post a new bug?) > Classes using Java 8 Lambdas cause goal descriptor to fail > -- > > Key: MPLUGIN-273 > URL: https://jira.codehaus.org/browse/MPLUGIN-273 > Project: Maven Plugin Tools > Issue Type: Bug > Components: maven-plugin-annotations >Affects Versions: 3.3 > Environment: Maven 3.2.3, maven-plugin-annotations 3.3 >Reporter: Martin Dreier >Assignee: Robert Scholte > Attachments: callstack.txt, java8-maven-plugin.zip > > > When the annotations scanner encounters a class which uses Java 8 Lambdas, > the scanning fails. Removing the lambda construct resolves the error. > Reproduction: > 1) Extract the attached maven project > 2) run mvn install in the project -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1112) Remove uneccessary newlines in console output for test results with no error
[
https://jira.codehaus.org/browse/SUREFIRE-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian reassigned SUREFIRE-1112:
Assignee: Andreas Gudian
> Remove uneccessary newlines in console output for test results with no error
>
>
> Key: SUREFIRE-1112
> URL: https://jira.codehaus.org/browse/SUREFIRE-1112
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Andreas Gudian
>Assignee: Andreas Gudian
>
> {code}
> Results :
> Tests run: 60, Failures: 0, Errors: 0, Skipped: 0
> {code}
> I'm pretty sure it has something to do with the extended test result handling
> / printing for the flaky tests feature.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1112) Remove uneccessary newlines in console output for test results with no error
Andreas Gudian created SUREFIRE-1112:
Summary: Remove uneccessary newlines in console output for test
results with no error
Key: SUREFIRE-1112
URL: https://jira.codehaus.org/browse/SUREFIRE-1112
Project: Maven Surefire
Issue Type: Bug
Reporter: Andreas Gudian
{code}
Results :
Tests run: 60, Failures: 0, Errors: 0, Skipped: 0
{code}
I'm pretty sure it has something to do with the extended test result handling /
printing for the flaky tests feature.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1113) Build does not fail when successPercentage for @org.testng.annotations.Test() is not met
Benoit Lagae created SUREFIRE-1113:
--
Summary: Build does not fail when successPercentage for
@org.testng.annotations.Test() is not met
Key: SUREFIRE-1113
URL: https://jira.codehaus.org/browse/SUREFIRE-1113
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin, TestNG support
Affects Versions: 2.18
Environment: TestNG 6.8.8, maven-surefire-plugin 2.19-SNAPSHOT
(53a40eef48ea)
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
2014-08-11T22:58:10+02:00)
Maven home: C:\Program Files\apache-maven-3.2.3
Java version: 1.7.0_67, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_67\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Benoit Lagae
Attachments: surefiretest.zip
When a TestNG test with annotation methods invocationCount = x and
successPercentage = y fails, this does not break the Maven build of the
project. I have attached a minimal Maven project with only the pom and a single
test class, which contains three dummy tests which should all fail:
@Test
public void testFailsCorrectly() { fail("dummy"); }
@Test(invocationCount = x)
public void testCounterWorksAndTestFails() { fail("dummy"); }
@Test(invocationCount = x, successPercentage = y)
public void testShouldFailButDoesnt() { fail("dummy"); }
The first two comply, but the third one doesn't, as is implied in the name of
the method. I created this project from scratch, i.e. not from an IDE: manual
creation of folders, code and pom in Notepad++, ...
I have attached both the project and the info I thought could be relevant from
my test runs of the project ('diagnostics' folder). Below are the results of
the individual method runs:
If we comment out the other tests, and only make testShouldFailButDoesnt run,
then the build succeeds while it shouldn't. See the results in
surefiretest/diagnostics/only_faulty_test/console_output.txt
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-609) Misbehavior on multi-module projects, outputDirectory not being interpolated properly
[
https://jira.codehaus.org/browse/MASSEMBLY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MASSEMBLY-609:
-
Summary: Misbehavior on multi-module projects, outputDirectory not being
interpolated properly (was: Misbehavior on multi-module projects)
> Misbehavior on multi-module projects, outputDirectory not being interpolated
> properly
> -
>
> Key: MASSEMBLY-609
> URL: https://jira.codehaus.org/browse/MASSEMBLY-609
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: (attached)
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>Reporter: Alexander Tumin
>Priority: Blocker
> Attachments: parent.zip
>
>
> With set to true; tag value is
> not being interpolated on a module-by-module basis as said in
> [documentation|http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html]
> - instead of substituting ${artifactId} with value of each processed modules
> it is always being substituted with the value of module which calls to the
> assembly plugin.
> In other words, instead of the following desired directory structure:
> distribution/target/distribution-1.0-bin/modules/child1/child1-1.0.jar
> distribution/target/distribution-1.0-bin/modules/child2/child2-1.0.jar
> distribution/target/distribution-1.0-bin/modules/child3/child3-1.0.jar
> i am getting flatenned
> distribution/target/distribution-1.0-bin/modules/distribution/child1-1.0.jar
> distribution/target/distribution-1.0-bin/modules/distribution/child2-1.0.jar
> distribution/target/distribution-1.0-bin/modules/distribution/child3-1.0.jar
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-558) Assembly does not include runtime-dependency if test-dependency with shorter path exists
[
https://jira.codehaus.org/browse/MASSEMBLY-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355560#comment-355560
]
Kristian Rosenvold commented on MASSEMBLY-558:
--
I suspect this issue is fixed with 2.5.1. Please test when 2.5.1 is released
> Assembly does not include runtime-dependency if test-dependency with shorter
> path exists
>
>
> Key: MASSEMBLY-558
> URL: https://jira.codehaus.org/browse/MASSEMBLY-558
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.2
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Java version: 1.5.0_12, vendor: Sun Microsystems Inc.
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
>Reporter: Frank Jakop
>
> In my project there's an artifact, which can be resolved by 2 different paths
> (scopes in brackets)
> {noformat}
> a) Project->projA(compile)->projB(compile)->myArtifact(runtime)
> b) Project->projB(test)->myArtifact(runtime)
> {noformat}
> The relevant part of the distribution descriptor is the following
> {code:xml}
>
> zip
>
>
>
> /lib
> true
> false
> runtime
>
>
> {code}
> So when I run assembly:assembly I wonder, why myArtifact isn't included in my
> zip. I now think, that assembly favours the shorter path b) despite the
> test-scope over the longer but correct path a).
> Since test-scope dependencies should have nothing to do with distribution (if
> not included explicitly) myArtifact should have be included in my zip.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-582) Plugin omits transitive runtime dependencies where artifact is present with test-scope in current project
[
https://jira.codehaus.org/browse/MASSEMBLY-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-582.
Resolution: Fixed
Fix Version/s: 2.5.1
Assignee: Kristian Rosenvold
This issue has been fixed for 2.5.1
> Plugin omits transitive runtime dependencies where artifact is present with
> test-scope in current project
> -
>
> Key: MASSEMBLY-582
> URL: https://jira.codehaus.org/browse/MASSEMBLY-582
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Linux, Sun 64-bit JDK 1.6.24
>Reporter: Michael
>Assignee: Kristian Rosenvold
> Fix For: 2.5.1
>
> Attachments: map-jira-1.zip
>
>
> Let's say I have Project1, which has a runtime dependency on an artifact,
> e.g. Log4j, and Project2 which is defined to have a runtime dependency on
> Project1. Project2 defines a dependency on Log4j with test-scope.
> {noformat}
> P1 --runtime--> P2 --runtime--> Log4j
> |
> test
> |
> V
> Log4j
> {noformat}
> If I define a descriptor in Project2 to include runtime dependencies, the
> Log4j artifact is not included in the resulting ZIP unless it is removed from
> Project2's dependencies first.
> This can be replicated through the use of the attached map-jira-1.zip files.
> 1) Unzip to the filesystem
> 2) Execute mvn package from the maven-assembly-jira1 directory
> 3) Inspect the contents of the ZIP in project2/target (on *nix: unzip -l
> project2/target/*.zip). Note the absence of Log4j.
> 4) Edit project2/pom.xml to comment-out the dependency on Log4j.
> 5) Execute mvn package from the maven-assembly-jira1 directory
> 6) Inspect the contents of the ZIP in project2/target. Note the inclusion of
> Log4j.
> This may not be entirely surprising to this plugin's developers. This is a
> specific issue for us since several projects define APIs and separate
> implementations. We depend on the API at compile-time and for testing use
> some implementation thereof. For example, we depend on SLF4j API and leave
> definition of the runtime logging implementation to some runtime,
> base-project (in this example, Project1). For testing purposes we need to
> define an SLF4j implementation, which just so happens (fancy that) to be the
> one we use in production. Our resulting deployable is created without the
> correct dependency set.
> I would have expected to receive all the runtime, transitive dependencies of
> my dependencies whether or not I declare a test dependency on those
> artifacts.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1113) Build does not fail when successPercentage for @org.testng.annotations.Test() is not met
[
https://jira.codehaus.org/browse/SUREFIRE-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Lagae updated SUREFIRE-1113:
---
Description:
When a TestNG test with annotation methods invocationCount = x and
successPercentage = y fails, this does not break the Maven build of the
project. I have attached a minimal Maven project with only the pom and a single
test class, which contains three dummy tests which should all fail:
{code}
@Test
public void testFailsCorrectly() { fail("dummy"); }
@Test(invocationCount = x)
public void testCounterWorksAndTestFails() { fail("dummy"); }
@Test(invocationCount = x, successPercentage = y)
public void testShouldFailButDoesnt() { fail("dummy"); }
{code}
The first two comply, but the third one doesn't, as is implied in the name of
the method. I created this project from scratch, i.e. not from an IDE: manual
creation of folders, code and pom in Notepad++, ...
I have attached both the project and the info I thought could be relevant from
my test runs of the project ('diagnostics' folder). Below are the results of
the individual method runs:
{code}
{code}
If we comment out the other tests, and only make testShouldFailButDoesnt run,
then the build succeeds while it shouldn't. See the results in
surefiretest/diagnostics/only_faulty_test/console_output.txt
was:
When a TestNG test with annotation methods invocationCount = x and
successPercentage = y fails, this does not break the Maven build of the
project. I have attached a minimal Maven project with only the pom and a single
test class, which contains three dummy tests which should all fail:
@Test
public void testFailsCorrectly() { fail("dummy"); }
@Test(invocationCount = x)
public void testCounterWorksAndTestFails() { fail("dummy"); }
@Test(invocationCount = x, successPercentage = y)
public void testShouldFailButDoesnt() { fail("dummy"); }
The first two comply, but the third one doesn't, as is implied in the name of
the method. I created this project from scratch, i.e. not from an IDE: manual
creation of folders, code and pom in Notepad++, ...
I have attached both the project and the info I thought could be relevant from
my test runs of the project ('diagnostics' folder). Below are the results of
the individual method runs:
If we comment out the other tests, and only make testShouldFailButDoesnt run,
then the build succeeds while it shouldn't. See the results in
surefiretest/diagnostics/only_faulty_test/console_output.txt
> Build does not fail when successPercentage for @org.testng.annotations.Test()
> is not met
>
>
> Key: SUREFIRE-1113
> URL: https://jira.codehaus.org/browse/SUREFIRE-1113
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 2.18
> Environment: TestNG 6.8.8, maven-surefire-plugin 2.19-SNAPSHOT
> (53a40eef48ea)
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-11T22:58:10+02:00)
> Maven home: C:\Program Files\apache-maven-3.2.3
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_67\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Benoit Lagae
> Attachments: surefiretest.zip
>
>
> When a TestNG test with annotation methods invocationCount = x and
> successPercentage = y fails, this does not break the Maven build of the
> project. I have attached a minimal Maven project with only the pom and a
> single test class, which contains three dummy tests which should all fail:
> {code}
> @Test
> public void testFailsCorrectly() { fail("dummy"); }
> @Test(invocationCount = x)
> public void testCounterWorksAndTestFails() { fail("dummy"); }
> @Test(invocationCount = x, successPercentage = y)
> public void testShouldFailButDoesnt() { fail("dummy"); }
> {code}
> The first two comply, but the third one doesn't, as is implied in the name of
> the method. I created this project from scratch, i.e. not from an IDE: manual
> creation of folders, code and pom in Notepad++, ...
> I have attached both the project and the info I thought could be relevant
> from my test runs of the project ('diagnostics' folder). Below are the
> results of the individual method runs:
> {code}
>
>
>
>
>
> signature="testShouldFailButDoesnt()[pri:0,
> instance:blagae.StatisticsTest@575598a]" name="testShouldFailButDoesnt"/>
> signature="testShouldFailButDoesnt()[pri:0,
> instance:blagae.StatisticsTest@575598a]" name="testShouldFailButDoesnt"/>
>
>
> {code}
> If we comment out the other tests, and only make testShouldFailButDoesnt run,
> then the build succeeds while it shouldn't. See the resul
[jira] (MASSEMBLY-357) transitive dependencies erroneously excluded from dependencySet in some cases
[
https://jira.codehaus.org/browse/MASSEMBLY-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-357.
Resolution: Fixed
Fix Version/s: 2.5.1
Assignee: Kristian Rosenvold
This has been fixed in 2.5.1 since individual dependency sets now are seaparate
resolution requests
> transitive dependencies erroneously excluded from dependencySet in some cases
> -
>
> Key: MASSEMBLY-357
> URL: https://jira.codehaus.org/browse/MASSEMBLY-357
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.2-beta-2
>Reporter: John Casey
>Assignee: Kristian Rosenvold
> Fix For: 2.5.1
>
>
> Given the following dependencies in a POM:
> {code:xml}
>
> commons-codec
> commons-codec
> 1.3
>
>
> commons-httpclient
> commons-httpclient
> 3.1
>
> {code}
> ..and the following assembly descriptor snippet:
> {code:xml}
>
>
> commons-codec*
>
> codec
> false
> true
>
>
>
> commons-httpclient*
>
> httpclient
> true
> true
> false
>
> {code}
> commons-codec *should* wind up in both the codec and httpclient dirs, but
> it's only in the codec dir. The reason for this is found in the
> maven-artifact code used to resolve dependencies. Since commons-codec is
> present as a direct dependency, it's *removed* from the sub-tree rooted by
> commons-httpclient, and its dependency trail doesn't contain even a whisper
> of this sub-tree structure. Since the transitive inclusions in dependencySets
> are calculated using artifact identifications (dependencyConflictId and id
> itself), along with the dependency trail it contains, the assembly plugin
> can't see the association between commons-httpclient and commons-codec,
> resulting in incomplete filtering for the dependencySet.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-202) Upgrade to maven-plugins version 25 to 26
[ https://jira.codehaus.org/browse/MEAR-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355505#comment-355505 ] Karl-Heinz Marbaise edited comment on MEAR-202 at 11/4/14 1:03 PM: --- Fixed in [r1636449|http://svn.apache.org/r1636449]. Follow up in [r1636691|http://svn.apache.org/r1636691]. was (Author: khmarbaise): Fixed in [r1636449|http://svn.apache.org/r1636449]. > Upgrade to maven-plugins version 25 to 26 > - > > Key: MEAR-202 > URL: https://jira.codehaus.org/browse/MEAR-202 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.10 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 2.10 > > > Upgrade maven-plugins version from 25 to 26. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-212) Upgrade maven-plugin-plugin from 3.2 to 3.3
Karl-Heinz Marbaise created MENFORCER-212: - Summary: Upgrade maven-plugin-plugin from 3.2 to 3.3 Key: MENFORCER-212 URL: https://jira.codehaus.org/browse/MENFORCER-212 Project: Maven Enforcer Plugin Issue Type: Improvement Affects Versions: 1.4 Reporter: Karl-Heinz Marbaise Priority: Minor Upgrade of maven-plugin-plugin from 3.2 to 3.3 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-212) Upgrade maven-plugin-plugin from 3.2 to 3.3
[ https://jira.codehaus.org/browse/MENFORCER-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MENFORCER-212: -- Fix Version/s: 1.4 > Upgrade maven-plugin-plugin from 3.2 to 3.3 > --- > > Key: MENFORCER-212 > URL: https://jira.codehaus.org/browse/MENFORCER-212 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.4 > > > Upgrade of maven-plugin-plugin from 3.2 to 3.3 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-212) Upgrade maven-plugin-plugin from 3.2 to 3.3
[ https://jira.codehaus.org/browse/MENFORCER-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MENFORCER-212. - Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1636692|http://svn.apache.org/r1636692] > Upgrade maven-plugin-plugin from 3.2 to 3.3 > --- > > Key: MENFORCER-212 > URL: https://jira.codehaus.org/browse/MENFORCER-212 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.4 > > > Upgrade of maven-plugin-plugin from 3.2 to 3.3 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-336) Upgrade to maven-plugins version 25 to 26
Karl-Heinz Marbaise created MWAR-336: Summary: Upgrade to maven-plugins version 25 to 26 Key: MWAR-336 URL: https://jira.codehaus.org/browse/MWAR-336 Project: Maven WAR Plugin Issue Type: Improvement Affects Versions: 3.0 Reporter: Karl-Heinz Marbaise Priority: Minor Upgrade maven-plugin parent from version 25 to 26. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-336) Upgrade to maven-plugins version 25 to 26
[ https://jira.codehaus.org/browse/MWAR-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MWAR-336: - Fix Version/s: 3.0 > Upgrade to maven-plugins version 25 to 26 > - > > Key: MWAR-336 > URL: https://jira.codehaus.org/browse/MWAR-336 > Project: Maven WAR Plugin > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 3.0 > > > Upgrade maven-plugin parent from version 25 to 26. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-328) Upgrade to Maven 3.0.5 compatiblity
[ https://jira.codehaus.org/browse/MWAR-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MWAR-328: - Fix Version/s: (was: next-release) 3.0 > Upgrade to Maven 3.0.5 compatiblity > --- > > Key: MWAR-328 > URL: https://jira.codehaus.org/browse/MWAR-328 > Project: Maven WAR Plugin > Issue Type: Improvement >Affects Versions: backlog >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 3.0 > > > Update to prerequisites 3.0.5. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-190) Upgrade to maven-plugins version 25 to 26
[ https://jira.codehaus.org/browse/MJAR-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MJAR-190: - Fix Version/s: 2.5.1 > Upgrade to maven-plugins version 25 to 26 > - > > Key: MJAR-190 > URL: https://jira.codehaus.org/browse/MJAR-190 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 2.5.1 > > > Upgrade to maven-plugin version 25 to 26. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-190) Upgrade to maven-plugins version 25 to 26
Karl-Heinz Marbaise created MJAR-190: Summary: Upgrade to maven-plugins version 25 to 26 Key: MJAR-190 URL: https://jira.codehaus.org/browse/MJAR-190 Project: Maven JAR Plugin Issue Type: Improvement Affects Versions: 2.5.1 Reporter: Karl-Heinz Marbaise Priority: Minor Upgrade to maven-plugin version 25 to 26. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-202) Upgrade to maven-plugins version 25 to 26
[ https://jira.codehaus.org/browse/MEAR-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355505#comment-355505 ] Karl-Heinz Marbaise edited comment on MEAR-202 at 11/4/14 1:52 PM: --- Fixed in [r1636449|http://svn.apache.org/r1636449]. Follow up in [r1636691|http://svn.apache.org/r1636691]. Follow up in [r1636704|http://svn.apache.org/r1636704]. was (Author: khmarbaise): Fixed in [r1636449|http://svn.apache.org/r1636449]. Follow up in [r1636691|http://svn.apache.org/r1636691]. > Upgrade to maven-plugins version 25 to 26 > - > > Key: MEAR-202 > URL: https://jira.codehaus.org/browse/MEAR-202 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.10 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 2.10 > > > Upgrade maven-plugins version from 25 to 26. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-190) Upgrade to maven-plugins version 25 to 26
[ https://jira.codehaus.org/browse/MJAR-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MJAR-190. Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1636726|http://svn.apache.org/r1636726]. > Upgrade to maven-plugins version 25 to 26 > - > > Key: MJAR-190 > URL: https://jira.codehaus.org/browse/MJAR-190 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 2.5.1 > > > Upgrade to maven-plugin version 25 to 26. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1113) Build does not fail when successPercentage for @org.testng.annotations.Test() is not met
[
https://jira.codehaus.org/browse/SUREFIRE-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355588#comment-355588
]
Andreas Gudian commented on SUREFIRE-1113:
--
I am pretty sure this is a duplicate of SUREFIRE-654 - which was fixed just
recently and is part of todays 2.18 release.
So please check if you still have problems with it in 2.18 (which landed on
Maven-Central just minutes ago).
If it still doesn't work, we'd have to look further into it.
> Build does not fail when successPercentage for @org.testng.annotations.Test()
> is not met
>
>
> Key: SUREFIRE-1113
> URL: https://jira.codehaus.org/browse/SUREFIRE-1113
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 2.18
> Environment: TestNG 6.8.8, maven-surefire-plugin 2.19-SNAPSHOT
> (53a40eef48ea)
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-11T22:58:10+02:00)
> Maven home: C:\Program Files\apache-maven-3.2.3
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_67\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Benoit Lagae
> Attachments: surefiretest.zip
>
>
> When a TestNG test with annotation methods invocationCount = x and
> successPercentage = y fails, this does not break the Maven build of the
> project. I have attached a minimal Maven project with only the pom and a
> single test class, which contains three dummy tests which should all fail:
> {code}
> @Test
> public void testFailsCorrectly() { fail("dummy"); }
> @Test(invocationCount = x)
> public void testCounterWorksAndTestFails() { fail("dummy"); }
> @Test(invocationCount = x, successPercentage = y)
> public void testShouldFailButDoesnt() { fail("dummy"); }
> {code}
> The first two comply, but the third one doesn't, as is implied in the name of
> the method. I created this project from scratch, i.e. not from an IDE: manual
> creation of folders, code and pom in Notepad++, ...
> I have attached both the project and the info I thought could be relevant
> from my test runs of the project ('diagnostics' folder). Below are the
> results of the individual method runs:
> {code}
>
>
>
>
>
> signature="testShouldFailButDoesnt()[pri:0,
> instance:blagae.StatisticsTest@575598a]" name="testShouldFailButDoesnt"/>
> signature="testShouldFailButDoesnt()[pri:0,
> instance:blagae.StatisticsTest@575598a]" name="testShouldFailButDoesnt"/>
>
>
> {code}
> If we comment out the other tests, and only make testShouldFailButDoesnt run,
> then the build succeeds while it shouldn't. See the results in
> surefiretest/diagnostics/only_faulty_test/console_output.txt
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] [Created] (MASFRES-12) Documentation links to non existent page
Alessandro Polverini created MASFRES-12: --- Summary: Documentation links to non existent page Key: MASFRES-12 URL: https://issues.apache.org/jira/browse/MASFRES-12 Project: Apache Maven Resource Bundles Issue Type: Bug Environment: Web browsing Reporter: Alessandro Polverini In the page https://maven.apache.org/guides/mini/guide-central-repository-upload.html there is a link to the page with the guidelines to follow to upload packages to the central maven repository, and it's not working: https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (SUREFIRE-1112) Remove uneccessary newlines in console output for test results with no error
[
https://jira.codehaus.org/browse/SUREFIRE-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355593#comment-355593
]
Tibor Digana commented on SUREFIRE-1112:
I am able to reproduce this issue.
Maybe the simplest way would be to find the commit# which caused this problem.
> Remove uneccessary newlines in console output for test results with no error
>
>
> Key: SUREFIRE-1112
> URL: https://jira.codehaus.org/browse/SUREFIRE-1112
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Andreas Gudian
>Assignee: Andreas Gudian
>
> {code}
> Results :
> Tests run: 60, Failures: 0, Errors: 0, Skipped: 0
> {code}
> I'm pretty sure it has something to do with the extended test result handling
> / printing for the flaky tests feature.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5718) Change 'provides' from Object to Properties in Toolchains.xml
[
https://jira.codehaus.org/browse/MNG-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5718:
---
Issue Type: Improvement (was: Bug)
> Change 'provides' from Object to Properties in Toolchains.xml
> -
>
> Key: MNG-5718
> URL: https://jira.codehaus.org/browse/MNG-5718
> Project: Maven
> Issue Type: Improvement
> Components: Toolchains
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.2.4
>
>
> Officially the content of the {{}} element in a toolchain was free
> of structure, although we only know Properties-like structures. To be able to
> support the merging of toolchains ( MNG-5714 ) it is better to drop the free
> structure and change it to Properties.
> This is backwards compatible for the {{jdk}} toolchain.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5718) Change 'provides' from Object to Properties in toolchains.xml
[
https://jira.codehaus.org/browse/MNG-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5718:
---
Summary: Change 'provides' from Object to Properties in toolchains.xml
(was: Change 'provides' from Object to Properties in Toolchains.xml)
> Change 'provides' from Object to Properties in toolchains.xml
> -
>
> Key: MNG-5718
> URL: https://jira.codehaus.org/browse/MNG-5718
> Project: Maven
> Issue Type: Improvement
> Components: Toolchains
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.2.4
>
>
> Officially the content of the {{}} element in a toolchain was free
> of structure, although we only know Properties-like structures. To be able to
> support the merging of toolchains ( MNG-5714 ) it is better to drop the free
> structure and change it to Properties.
> This is backwards compatible for the {{jdk}} toolchain.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5720) Change 'configuration' from Object to Properties in toolchains.xml
Herve Boutemy created MNG-5720: -- Summary: Change 'configuration' from Object to Properties in toolchains.xml Key: MNG-5720 URL: https://jira.codehaus.org/browse/MNG-5720 Project: Maven Issue Type: Improvement Components: Toolchains Affects Versions: 3.2.3 Reporter: Herve Boutemy Officially the content of the element in a toolchain was free of structure, although we only know Properties-like structures. To improve the automatic handling by Modello, it is better to drop the free structure and change it to Properties like it was done in MNG-5718 for . The jdk toolchain will be modified accordingly, being transparent for users. But any custom toolchain implementation will need to be updated. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5718) Change 'provides' from Object to Properties in toolchains.xml
[
https://jira.codehaus.org/browse/MNG-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5718:
---
Description:
Officially the content of the {{}} element in a toolchain was free of
structure, although we only know Properties-like structures. To be able to
support the merging of toolchains ( MNG-5714 ) it is better to drop the free
structure and change it to Properties.
The {{jdk}} toolchain will be modified accordingly, being transparent for users.
But any custom toolchain implementation will need to be updated.
was:
Officially the content of the {{}} element in a toolchain was free of
structure, although we only know Properties-like structures. To be able to
support the merging of toolchains ( MNG-5714 ) it is better to drop the free
structure and change it to Properties.
This is backwards compatible for the {{jdk}} toolchain.
> Change 'provides' from Object to Properties in toolchains.xml
> -
>
> Key: MNG-5718
> URL: https://jira.codehaus.org/browse/MNG-5718
> Project: Maven
> Issue Type: Improvement
> Components: Toolchains
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.2.4
>
>
> Officially the content of the {{}} element in a toolchain was free
> of structure, although we only know Properties-like structures. To be able to
> support the merging of toolchains ( MNG-5714 ) it is better to drop the free
> structure and change it to Properties.
> The {{jdk}} toolchain will be modified accordingly, being transparent for
> users.
> But any custom toolchain implementation will need to be updated.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5720) Change 'configuration' from Object to Properties in toolchains.xml
[
https://jira.codehaus.org/browse/MNG-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5720:
---
Description:
Officially the content of the {{}} element in a toolchain was
free of structure, although we only know Properties-like structures.
To improve the automatic handling by Modello, it is better to drop the free
structure and change it to Properties like it was done in MNG-5718 for
.
The {{jdk}} toolchain will be modified accordingly, being transparent for users.
But any custom toolchain implementation will need to be updated.
was:
Officially the content of the element in a toolchain was free
of structure, although we only know Properties-like structures.
To improve the automatic handling by Modello, it is better to drop the free
structure and change it to Properties like it was done in MNG-5718 for
.
The jdk toolchain will be modified accordingly, being transparent for users.
But any custom toolchain implementation will need to be updated.
> Change 'configuration' from Object to Properties in toolchains.xml
> --
>
> Key: MNG-5720
> URL: https://jira.codehaus.org/browse/MNG-5720
> Project: Maven
> Issue Type: Improvement
> Components: Toolchains
>Affects Versions: 3.2.3
>Reporter: Herve Boutemy
>
> Officially the content of the {{}} element in a toolchain was
> free of structure, although we only know Properties-like structures.
> To improve the automatic handling by Modello, it is better to drop the free
> structure and change it to Properties like it was done in MNG-5718 for
> .
> The {{jdk}} toolchain will be modified accordingly, being transparent for
> users.
> But any custom toolchain implementation will need to be updated.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5720) Change 'configuration' from Object to Properties in toolchains.xml
[
https://jira.codehaus.org/browse/MNG-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5720:
---
Fix Version/s: 3.2.4
> Change 'configuration' from Object to Properties in toolchains.xml
> --
>
> Key: MNG-5720
> URL: https://jira.codehaus.org/browse/MNG-5720
> Project: Maven
> Issue Type: Improvement
> Components: Toolchains
>Affects Versions: 3.2.3
>Reporter: Herve Boutemy
> Fix For: 3.2.4
>
>
> Officially the content of the {{}} element in a toolchain was
> free of structure, although we only know Properties-like structures.
> To improve the automatic handling by Modello, it is better to drop the free
> structure and change it to Properties like it was done in MNG-5718 for
> .
> The {{jdk}} toolchain will be modified accordingly, being transparent for
> users.
> But any custom toolchain implementation will need to be updated.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MTOOLCHAINS-6) Cannot create custom toolchain type
[
https://jira.codehaus.org/browse/MTOOLCHAINS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355594#comment-355594
]
Herve Boutemy commented on MTOOLCHAINS-6:
-
custom toolchain implementation updated to support changes from Maven 3.2.4
(MNG-5718 and MNG-5720) in [r1636790|http://svn.apache.org/r1636790]
> Cannot create custom toolchain type
> ---
>
> Key: MTOOLCHAINS-6
> URL: https://jira.codehaus.org/browse/MTOOLCHAINS-6
> Project: Maven Toolchains Plugin
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Win 7 Pro SP1 64 Bit, mvn 3.0.4, JDK 1.7.0_45
>Reporter: Markus KARG
>Priority: Blocker
>
> The web site says that it is possible to use other toolchains besides .
> Actually the site links to a nonexistent TBD page. This is very ugly.
> Please tell the truth on the web page: It is simply impossible to use any
> other toolschain type besides !
> It would be really cool, if someone could simply write:
> {code:xml}
>
> installshield
>
> isx
> 10.0
> macrovision
>
>
> C:\Program Files (x86)\InstallShield
> X
>
>
> {code}
> ...and the plugin would in turn simply provide a property that one can read
> in the POM using {{$\{installshieldHome}}} -- without any need to write Java
> code, register custom types, provide more xml, whatever!
> This seems to be such an obvious need that I just cannot believe that it does
> not already work exactly that way in the 1.0 release of the toolchains
> plugin...! :-)
> I really beg for that! :-)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MTOOLCHAINS-6) Cannot create custom toolchain type
[
https://jira.codehaus.org/browse/MTOOLCHAINS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355598#comment-355598
]
Mirko Friedenhagen commented on MTOOLCHAINS-6:
--
AFAIK protocol buffer maven plugin uses toolchain as well for the protoc
location.
> Cannot create custom toolchain type
> ---
>
> Key: MTOOLCHAINS-6
> URL: https://jira.codehaus.org/browse/MTOOLCHAINS-6
> Project: Maven Toolchains Plugin
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Win 7 Pro SP1 64 Bit, mvn 3.0.4, JDK 1.7.0_45
>Reporter: Markus KARG
>Priority: Blocker
>
> The web site says that it is possible to use other toolchains besides .
> Actually the site links to a nonexistent TBD page. This is very ugly.
> Please tell the truth on the web page: It is simply impossible to use any
> other toolschain type besides !
> It would be really cool, if someone could simply write:
> {code:xml}
>
> installshield
>
> isx
> 10.0
> macrovision
>
>
> C:\Program Files (x86)\InstallShield
> X
>
>
> {code}
> ...and the plugin would in turn simply provide a property that one can read
> in the POM using {{$\{installshieldHome}}} -- without any need to write Java
> code, register custom types, provide more xml, whatever!
> This seems to be such an obvious need that I just cannot believe that it does
> not already work exactly that way in the 1.0 release of the toolchains
> plugin...! :-)
> I really beg for that! :-)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MTOOLCHAINS-6) Cannot create custom toolchain type
[
https://jira.codehaus.org/browse/MTOOLCHAINS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355601#comment-355601
]
Herve Boutemy commented on MTOOLCHAINS-6:
-
oh, yes, it seems there is a fork with custom toolchains support:
http://sergei-ivanov.github.io/maven-protoc-plugin/examples/protobuf-toolchain.html
/ https://github.com/sergei-ivanov/maven-protoc-plugin
thank you for the pointer (notice the plugin is not published to central: this
is an extension not maintained by core protobuf project)
I'll add it to our list of toolchain's aware plugins
http://maven.apache.org/guides/mini/guide-using-toolchains.html, to list not
only jdk-toolchain-aware plugins, but other toolchains too
and in protobuf, there is a good idea I'll integrate into the IT: have the
plugin provide both the plugin and the toolchain, and mark it as extension,
since I suppose custom toochains will often be tied to one plugin only (like
protobuf), and not multiple (like jdk)
> Cannot create custom toolchain type
> ---
>
> Key: MTOOLCHAINS-6
> URL: https://jira.codehaus.org/browse/MTOOLCHAINS-6
> Project: Maven Toolchains Plugin
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Win 7 Pro SP1 64 Bit, mvn 3.0.4, JDK 1.7.0_45
>Reporter: Markus KARG
>Priority: Blocker
>
> The web site says that it is possible to use other toolchains besides .
> Actually the site links to a nonexistent TBD page. This is very ugly.
> Please tell the truth on the web page: It is simply impossible to use any
> other toolschain type besides !
> It would be really cool, if someone could simply write:
> {code:xml}
>
> installshield
>
> isx
> 10.0
> macrovision
>
>
> C:\Program Files (x86)\InstallShield
> X
>
>
> {code}
> ...and the plugin would in turn simply provide a property that one can read
> in the POM using {{$\{installshieldHome}}} -- without any need to write Java
> code, register custom types, provide more xml, whatever!
> This seems to be such an obvious need that I just cannot believe that it does
> not already work exactly that way in the 1.0 release of the toolchains
> plugin...! :-)
> I really beg for that! :-)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-204) Upgrade maven-archiver dependency to v2.6
Anders Hammar created MEAR-204: -- Summary: Upgrade maven-archiver dependency to v2.6 Key: MEAR-204 URL: https://jira.codehaus.org/browse/MEAR-204 Project: Maven Ear Plugin Issue Type: Improvement Environment: n/a Reporter: Anders Hammar Priority: Minor Upgrade maven-archiver dependency to v2.6 (latest version currently available as of ticket creation). Also align version of plexus-archiver (v2.8.1). Release Notes - Maven Archiver - Version 2.6 Bug 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 Improvement 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 Task 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)
