[jira] (SUREFIRE-1101) Surefire does not shutdown thread-pools programatically after test run has finished.
[ https://jira.codehaus.org/browse/SUREFIRE-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353842#comment-353842 ] Tibor Digana commented on SUREFIRE-1101: https://github.com/apache/maven-surefire/pull/51 > Surefire does not shutdown thread-pools programatically after test run has > finished. > > > Key: SUREFIRE-1101 > URL: https://jira.codehaus.org/browse/SUREFIRE-1101 > Project: Maven Surefire > Issue Type: Improvement > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.16, 2.17 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.18 > > > The threads executing tests in parallel should be shutdown after the test run > has finished. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-70) Support for multiple source folders
[
https://jira.codehaus.org/browse/MCHECKSTYLE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353837#comment-353837
]
Anthony Whitford commented on MCHECKSTYLE-70:
-
I was able to restore prior functionality with the following configuration:
{code:xml}
src/main/java
src/test/java
{code}
> Support for multiple source folders
> ---
>
> Key: MCHECKSTYLE-70
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-70
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Jan Palmquist
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 2.13
>
>
> It would be great if this plugin would support multiple source folders added
> by http://mojo.codehaus.org/build-helper-maven-plugin/ (or similar), and by
> default inspect sources from these folders instead of just
> $\{project.build.sourceDirectory}. Correspondingly with respect to test
> sources if those are configured to be included.
> There are other plugins available solving this problem (somehow), eg:
> * http://mojo.codehaus.org/jdepend-maven-plugin/
> * http://mojo.codehaus.org/findbugs-maven-plugin/
> Maybe they can give some inspiration for how to make this possible?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MREPOSITORY-34) Failure during Release in integration tests
[ https://jira.codehaus.org/browse/MREPOSITORY-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MREPOSITORY-34: --- Fix Version/s: 2.4 > Failure during Release in integration tests > --- > > Key: MREPOSITORY-34 > URL: https://jira.codehaus.org/browse/MREPOSITORY-34 > Project: Maven Repository Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Karl-Heinz Marbaise > Fix For: 2.4 > > Attachments: > org.apache.maven.plugins.repository.it.BundleCreateIT.txt, > org.apache.maven.plugins.repository.it.BundlePackIT.txt > > > During the release the integration test fail cause the plugin itself is not > installed into the correct local repository -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MREPOSITORY-34) Failure during Release in integration tests
[ https://jira.codehaus.org/browse/MREPOSITORY-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MREPOSITORY-34: --- Attachment: org.apache.maven.plugins.repository.it.BundlePackIT.txt > Failure during Release in integration tests > --- > > Key: MREPOSITORY-34 > URL: https://jira.codehaus.org/browse/MREPOSITORY-34 > Project: Maven Repository Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Karl-Heinz Marbaise > Fix For: 2.4 > > Attachments: > org.apache.maven.plugins.repository.it.BundleCreateIT.txt, > org.apache.maven.plugins.repository.it.BundlePackIT.txt > > > During the release the integration test fail cause the plugin itself is not > installed into the correct local repository -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MREPOSITORY-34) Failure during Release in integration tests
[ https://jira.codehaus.org/browse/MREPOSITORY-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MREPOSITORY-34: --- Attachment: org.apache.maven.plugins.repository.it.BundleCreateIT.txt > Failure during Release in integration tests > --- > > Key: MREPOSITORY-34 > URL: https://jira.codehaus.org/browse/MREPOSITORY-34 > Project: Maven Repository Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Karl-Heinz Marbaise > Fix For: 2.4 > > Attachments: > org.apache.maven.plugins.repository.it.BundleCreateIT.txt, > org.apache.maven.plugins.repository.it.BundlePackIT.txt > > > During the release the integration test fail cause the plugin itself is not > installed into the correct local repository -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MREPOSITORY-34) Failure during Release in integration tests
[ https://jira.codehaus.org/browse/MREPOSITORY-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MREPOSITORY-34: --- Attachment: (was: org.apache.maven.plugins.repository.it.BundleCreateIT.txt) > Failure during Release in integration tests > --- > > Key: MREPOSITORY-34 > URL: https://jira.codehaus.org/browse/MREPOSITORY-34 > Project: Maven Repository Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Karl-Heinz Marbaise > Fix For: 2.4 > > Attachments: > org.apache.maven.plugins.repository.it.BundleCreateIT.txt, > org.apache.maven.plugins.repository.it.BundlePackIT.txt > > > During the release the integration test fail cause the plugin itself is not > installed into the correct local repository -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MREPOSITORY-34) Failure during Release in integration tests
Karl-Heinz Marbaise created MREPOSITORY-34: -- Summary: Failure during Release in integration tests Key: MREPOSITORY-34 URL: https://jira.codehaus.org/browse/MREPOSITORY-34 Project: Maven Repository Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Karl-Heinz Marbaise Attachments: org.apache.maven.plugins.repository.it.BundleCreateIT.txt During the release the integration test fail cause the plugin itself is not installed into the correct local repository -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-233) Default build mode doesn't recompile all dependencies, causing NoSuchMethodError/NoSuchFieldError at runtime
[
https://jira.codehaus.org/browse/MCOMPILER-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-233:
-
Description:
I build a project with 'mvn package', change the type of a field/method in one
source file, run 'mvn package' again and it only rebuilds the changed file, and
not the other classes that depend on it.
This can cause NoSuchMethodError/NoSuchFieldError when/if the code is reached
at runtime. (at least Java 1.7 didn't detect this at class load time).
Due to http://jira.codehaus.org/browse/MCOMPILER-209 it is not entirely obvious
how to turn off these partial builds, for example if I put
true in my pom.xml then
both source files are recompiled and the program works correclty so I would
think that incremental compilation is NOT used in that case? Confusing.
It appears that the only reliable way to build a project is to run 'mvn clean
package' instead of just 'mvn package'.
Maven should probably print a warning when using the partial builds, and the
documentation should be updated to warn of these inconsistencies.
Or perhaps you could run a final checking step after all files are compiled
that checks whether the .class files are all still consistent (like a linker
step).
Self-contained testcase:
{noformat}
#!/bin/sh
set -e
{noformat}
\# Setup initial project
{{mvn archetype:generate -DgroupId=com.example.bug -DartifactId=build-bug
-DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false}}
{{cd build-bug}}
{code:title=src/main/java/com/example/bug/App.java}
package com.example.bug;
public class App
{
public static void main( String[] args )
{
System.out.println( new Other().foo() );
}
}
{code}
{code:title=src/main/java/com/example/bug/Other.java }
package com.example.bug;
public class Other {
Integer foo() { return new Integer(42); }
}
{code}
{{mvn package java -cp target/build-bug-1.0-SNAPSHOT.jar com.example.bug.App}}
\# Make a change
sed -i -e 's/Integer/Long/g' src/main/java/com/example/bug/Other.java
\# Watch how incremental compilation breaks everything
{{mvn -X package >build.log}}
{{java -cp target/build-bug-1.0-SNAPSHOT.jar com.example.bug.App}}
was:
I build a project with 'mvn package', change the type of a field/method in one
source file, run 'mvn package' again and it only rebuilds the changed file, and
not the other classes that depend on it.
This can cause NoSuchMethodError/NoSuchFieldError when/if the code is reached
at runtime. (at least Java 1.7 didn't detect this at class load time).
Due to http://jira.codehaus.org/browse/MCOMPILER-209 it is not entirely obvious
how to turn off these partial builds, for example if I put
true in my pom.xml then
both source files are recompiled and the program works correclty so I would
think that incremental compilation is NOT used in that case? Confusing.
It appears that the only reliable way to build a project is to run 'mvn clean
package' instead of just 'mvn package'.
Maven should probably print a warning when using the partial builds, and the
documentation should be updated to warn of these inconsistencies.
Or perhaps you could run a final checking step after all files are compiled
that checks whether the .class files are all still consistent (like a linker
step).
Self-contained testcase:
#!/bin/sh
set -e
# Setup initial project
mvn archetype:generate -DgroupId=com.example.bug -DartifactId=build-bug
-DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
cd build-bug
cat >src/main/java/com/example/bug/App.java Default build mode doesn't recompile all dependencies, causing
> NoSuchMethodError/NoSuchFieldError at runtime
>
>
> Key: MCOMPILER-233
> URL: https://jira.codehaus.org/browse/MCOMPILER-233
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2, 3.0
> Environment: Linux amd64
>Reporter: Török Edwin
> Attachments: build.log
>
>
> I build a project with 'mvn package', change the type of a field/method in
> one source file, run 'mvn package' again and it only rebuilds the changed
> file, and not the other classes that depend on it.
> This can cause NoSuchMethodError/NoSuchFieldError when/if the code is reached
> at runtime. (at least Java 1.7 didn't detect this at class load time).
> Due to http://jira.codehaus.org/browse/MCOMPILER-209 it is not entirely
> obvious how to turn off these partial builds, for example if I put
> true in my pom.xml
> then both source files are recompiled and the program works correclty so I
> would think that incremental compilation is NOT used in that case? Confusing.
> I
[jira] (MREPOSITORY-33) Improve stabebility of Integration tests
[ https://jira.codehaus.org/browse/MREPOSITORY-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MREPOSITORY-33. -- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1629742|http://svn.apache.org/r1629742]. > Improve stabebility of Integration tests > > > Key: MREPOSITORY-33 > URL: https://jira.codehaus.org/browse/MREPOSITORY-33 > Project: Maven Repository Plugin > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Trivial > Fix For: 2.4 > > > Several different maven versions etc. using results in failing integration > tests. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MREPOSITORY-33) Improve stabebility of Integration tests
[ https://jira.codehaus.org/browse/MREPOSITORY-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MREPOSITORY-33: --- Fix Version/s: 2.4 > Improve stabebility of Integration tests > > > Key: MREPOSITORY-33 > URL: https://jira.codehaus.org/browse/MREPOSITORY-33 > Project: Maven Repository Plugin > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Karl-Heinz Marbaise >Priority: Trivial > Fix For: 2.4 > > > Several different maven versions etc. using results in failing integration > tests. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MREPOSITORY-33) Improve stabebility of Integration tests
Karl-Heinz Marbaise created MREPOSITORY-33: -- Summary: Improve stabebility of Integration tests Key: MREPOSITORY-33 URL: https://jira.codehaus.org/browse/MREPOSITORY-33 Project: Maven Repository Plugin Issue Type: Improvement Affects Versions: 2.4 Reporter: Karl-Heinz Marbaise Priority: Trivial Several different maven versions etc. using results in failing integration tests. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-228) cannot assign a value to final variable in lamda
[
https://jira.codehaus.org/browse/MCOMPILER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-228.
Resolution: Not A Bug
Assignee: Robert Scholte
To be precise: it was not a maven-compiler-plugin issue, but an Oracle JDK bug.
IT has been added in [r1629739|http://svn.apache.org/r1629739]
> cannot assign a value to final variable in lamda
>
>
> Key: MCOMPILER-228
> URL: https://jira.codehaus.org/browse/MCOMPILER-228
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: Windows 7 64 bit, Maven 3.2.2, JDK 64 bit 8u5
>Reporter: Robert Kish
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: FinalExample.java, MCOMPILER-228.patch
>
>
> Code example compiles in Eclipse, but not with Maven Compiler Plugin. Code is
> like below (inside a lamda expression)
> {code}
> final x;
> if (some condition)
> x = a;
> else if (some other condition)
> x = b;
> else
> x = c;
> {code}
> See attached example source.
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile)
> on project MediaIndexer: Compilation failure: Compilation failure:
> [ERROR] /C:/MAPS/MediaIndexer/src/main/java/example/FinalExample.java:[11,13]
> cannot assign a value to final variable compareTo
> [ERROR] /C:/MAPS/MediaIndexer/src/main/java/example/FinalExample.java:[14,13]
> cannot assign a value to final variable compareTo
> [ERROR] /C:/MAPS/MediaIndexer/src/main/java/example/FinalExample.java:[17,13]
> cannot assign a value to final variable compareTo
> {noformat}
> The workaround is to remove final for the variable and just ensure that the
> value is assigned in each code path.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-228) cannot assign a value to final variable in lamda
[
https://jira.codehaus.org/browse/MCOMPILER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353829#comment-353829
]
Robert Scholte edited comment on MCOMPILER-228 at 10/6/14 2:25 PM:
---
To be precise: it was not a maven-compiler-plugin issue, but an Oracle JDK bug.
IT has been added in [r1629739|http://svn.apache.org/r1629739]
JDK1.8.0_40 also contains the fix.
was (Author: rfscholte):
To be precise: it was not a maven-compiler-plugin issue, but an Oracle JDK bug.
IT has been added in [r1629739|http://svn.apache.org/r1629739]
> cannot assign a value to final variable in lamda
>
>
> Key: MCOMPILER-228
> URL: https://jira.codehaus.org/browse/MCOMPILER-228
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: Windows 7 64 bit, Maven 3.2.2, JDK 64 bit 8u5
>Reporter: Robert Kish
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: FinalExample.java, MCOMPILER-228.patch
>
>
> Code example compiles in Eclipse, but not with Maven Compiler Plugin. Code is
> like below (inside a lamda expression)
> {code}
> final x;
> if (some condition)
> x = a;
> else if (some other condition)
> x = b;
> else
> x = c;
> {code}
> See attached example source.
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile)
> on project MediaIndexer: Compilation failure: Compilation failure:
> [ERROR] /C:/MAPS/MediaIndexer/src/main/java/example/FinalExample.java:[11,13]
> cannot assign a value to final variable compareTo
> [ERROR] /C:/MAPS/MediaIndexer/src/main/java/example/FinalExample.java:[14,13]
> cannot assign a value to final variable compareTo
> [ERROR] /C:/MAPS/MediaIndexer/src/main/java/example/FinalExample.java:[17,13]
> cannot assign a value to final variable compareTo
> {noformat}
> The workaround is to remove final for the variable and just ensure that the
> value is assigned in each code path.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-131) Excluding tests with command line pattern
[
https://jira.codehaus.org/browse/SUREFIRE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353821#comment-353821
]
Valters Vingolds commented on SUREFIRE-131:
---
This would really be helpful for skipping a test on CI environment, where it is
known to work erratically. (For example, E2E test that is flaky, and we don't
want it invalidating the whole staging build.)
The key is we don't want to modify a pom.xml file, it should be done via
command line option.
> Excluding tests with command line pattern
> -
>
> Key: SUREFIRE-131
> URL: https://jira.codehaus.org/browse/SUREFIRE-131
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 2.0 (2.2 plugin)
> Environment: All environments running JUnit tests
>Reporter: Johannes Carlén
>Priority: Minor
> Fix For: Backlog
>
>
> I'd like to be able to exclude certain tests from being run. An example of
> this could be a scenario where I'd like just the unit tests and not the
> integration tests to run. In our case, we name all integration test with the
> postfix "IntTest" instead of just "Test".
> This is now possible through configuring the plugin in the pom, however it is
> not possible to decide at the command line if I just like to run some tests
> and not all.
> Example of use with this implementation would be:
> mvn -Dexclude=*IntTest test
> which would run all tests - excluding those that ends with IntTest
> The amount of code needed for implementation is minimal. In
> SurefirePlugin.java:
> Just add a property - something like:
> /**
> * Specify this parameter to exclude test by their name. It follows
> * the same conventions as the test parameter.
> *
> * @parameter expression="${exclude}"
> *
> */
> private String exclude;
> Add this code at line 527
> if ( this.exclude != null )
> {
> String exclude = "**/" + this.exclude + ".java";
> excludes.add(exclude);
> getLog().debug( "Excluding test with pattern :" + exclude
> );
> }
> ...and that's all.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-362) Support removing default manifest entries with maven-archiver plugin
Richard Neish created MSHARED-362: - Summary: Support removing default manifest entries with maven-archiver plugin Key: MSHARED-362 URL: https://jira.codehaus.org/browse/MSHARED-362 Project: Maven Shared Components Issue Type: Improvement Components: maven-archiver Affects Versions: maven-archiver-2.5, maven-archiver-2.4.2 Reporter: Richard Neish Priority: Minor As described in the StackOverflow question at http://stackoverflow.com/q/25098307/274350 maven-archiver should allow the user to remove the default manifest entries, such as "Built-By:" Currently it is possible to set an empty value for these default entries, but not to remove them from the manifest. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-180) Artifacts with same artifactId/version are ignored in packaging
[
https://jira.codehaus.org/browse/MEAR-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353760#comment-353760
]
Reto Hablützel commented on MEAR-180:
-
Why not just generate a truly unique ID? That is, include the groupId in the
name? And then, if the two are still the same, it should probably behave as it
does if somehow else a dependency is specified twice.
> Artifacts with same artifactId/version are ignored in packaging
> ---
>
> Key: MEAR-180
> URL: https://jira.codehaus.org/browse/MEAR-180
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Reto Hablützel
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.10
>
> Attachments: ear-silent-ignore.zip
>
>
> The attached sample consists of an ear that references two other projects,
> both of which have the *same artifactId and the same versionId*, but *not the
> same groupId*.
> Both are to be packaged in the lib folder, but only the first will make it
> in, because the maven ear plugin identifies them only by their artifactId and
> version. This means that when it sees the second dependency, it thinks it was
> already in there.
> Note that I already brought this up on the mailing list:
> https://mail-archives.apache.org/mod_mbox/maven-users/201402.mbox/browser
> Follow these steps to recreate the issue based on the attached sample:
> {quote}
> Install 'utilities' project in 'collections':
> collections/utilities> mvn install
> Install 'utilities' project in 'email':
> email/utilities> mvn install
> Package 'ear' project:
> ear> mvn package
> Look at contents of ear and notice how only one jar is included:
> ear> unzip -v target/ear-1.0.0.ear
> Now use the debug flag to see why only one gets included:
> ear> mvn --debug clean package
> Partial output:
> \[INFO\] Copying artifact \[jar:ch.rethab.email:utilities:1.0.0\] to
> \[utilities-1.0.0.jar\]
> \[DEBUG\] Skipping artifact \[jar:ch.rethab.collections:utilities:1.0.0\],
> as it is already up to date at \[utilities-1.0.0.jar\]
> {quote}
> Note that this sample shows how dependent libraries are ignored, but I think
> it is also an issue if you have two ejbs with the same name and version -
> though that is probably far less likely.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
