[jira] (MJAVADOC-398) Classes from build output directory can cause failure
[ https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353178#comment-353178 ] Michael Osipov commented on MJAVADOC-398: - Hi David, thanks for your report. A best, we would have two test cases, one which makes Maven fail when classes are present and one which makes it fail when classes are missing. This could be added to an IT. I will have a look at MJAVADOC-406 in the next days. Classes from build output directory can cause failure - Key: MJAVADOC-398 URL: https://jira.codehaus.org/browse/MJAVADOC-398 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Reporter: Michal Srb Assignee: Michael Osipov Fix For: 2.10 maven-javadoc-plugin adds compiled classes from build output directory to javadoc's classpath. There are certain cases when this can lead to either incorrect serialized-form.html page or failure (in case of jdk8). See [1] for more details. I think that having classes from build output directory on javadoc's classpath is not necessary. It may cause only problems and user can call javadoc:javadoc before actual build anyway. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-398) Classes from build output directory can cause failure
[ https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353178#comment-353178 ] Michael Osipov edited comment on MJAVADOC-398 at 9/25/14 2:11 AM: -- Hi David, thanks for your report. At best, we would have two test cases, one which makes Maven fail when classes are present and one which makes it fail when classes are missing. This could be added to an IT. I will have a look at MJAVADOC-406 in the next days. was (Author: michael-o): Hi David, thanks for your report. A best, we would have two test cases, one which makes Maven fail when classes are present and one which makes it fail when classes are missing. This could be added to an IT. I will have a look at MJAVADOC-406 in the next days. Classes from build output directory can cause failure - Key: MJAVADOC-398 URL: https://jira.codehaus.org/browse/MJAVADOC-398 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Reporter: Michal Srb Assignee: Michael Osipov Fix For: 2.10 maven-javadoc-plugin adds compiled classes from build output directory to javadoc's classpath. There are certain cases when this can lead to either incorrect serialized-form.html page or failure (in case of jdk8). See [1] for more details. I think that having classes from build output directory on javadoc's classpath is not necessary. It may cause only problems and user can call javadoc:javadoc before actual build anyway. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTRUN-189) Allow users to specify custom Ant loggers
Ion Savin created MANTRUN-189: - Summary: Allow users to specify custom Ant loggers Key: MANTRUN-189 URL: https://jira.codehaus.org/browse/MANTRUN-189 Project: Maven Antrun Plugin Issue Type: New Feature Affects Versions: 1.7 Reporter: Ion Savin Attachments: MAVENRUN-189.patch Ant allows you to specify a custom or a built-in logger other than the default one using the -logger command line flag: https://ant.apache.org/manual/listeners.html The org.apache.tools.ant.listener.ProfileLogger is one example which could be useful for maven-antrun-plugin as well as it allows you to debug slow targets directly from maven. This change allows you to configure a custom logger in maven-antrun-plugin using the logger/ configuration element. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTRUN-189) Allow users to specify custom Ant loggers
[ https://jira.codehaus.org/browse/MANTRUN-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ion Savin updated MANTRUN-189: -- Attachment: MAVENRUN-189.patch Allow users to specify custom Ant loggers - Key: MANTRUN-189 URL: https://jira.codehaus.org/browse/MANTRUN-189 Project: Maven Antrun Plugin Issue Type: New Feature Affects Versions: 1.7 Reporter: Ion Savin Attachments: MAVENRUN-189.patch Ant allows you to specify a custom or a built-in logger other than the default one using the -logger command line flag: https://ant.apache.org/manual/listeners.html The org.apache.tools.ant.listener.ProfileLogger is one example which could be useful for maven-antrun-plugin as well as it allows you to debug slow targets directly from maven. This change allows you to configure a custom logger in maven-antrun-plugin using the logger/ configuration element. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTRUN-189) Allow users to specify custom Ant loggers
[ https://jira.codehaus.org/browse/MANTRUN-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ion Savin updated MANTRUN-189: -- Attachment: (was: MAVENRUN-189.patch) Allow users to specify custom Ant loggers - Key: MANTRUN-189 URL: https://jira.codehaus.org/browse/MANTRUN-189 Project: Maven Antrun Plugin Issue Type: New Feature Affects Versions: 1.7 Reporter: Ion Savin Attachments: MAVENRUN-189.patch Ant allows you to specify a custom or a built-in logger other than the default one using the -logger command line flag: https://ant.apache.org/manual/listeners.html The org.apache.tools.ant.listener.ProfileLogger is one example which could be useful for maven-antrun-plugin as well as it allows you to debug slow targets directly from maven. This change allows you to configure a custom logger in maven-antrun-plugin using the logger/ configuration element. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTRUN-189) Allow users to specify custom Ant loggers
[ https://jira.codehaus.org/browse/MANTRUN-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ion Savin updated MANTRUN-189: -- Patch Submitted: Yes Allow users to specify custom Ant loggers - Key: MANTRUN-189 URL: https://jira.codehaus.org/browse/MANTRUN-189 Project: Maven Antrun Plugin Issue Type: New Feature Affects Versions: 1.7 Reporter: Ion Savin Attachments: MAVENRUN-189.patch Ant allows you to specify a custom or a built-in logger other than the default one using the -logger command line flag: https://ant.apache.org/manual/listeners.html The org.apache.tools.ant.listener.ProfileLogger is one example which could be useful for maven-antrun-plugin as well as it allows you to debug slow targets directly from maven. This change allows you to configure a custom logger in maven-antrun-plugin using the logger/ configuration element. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTRUN-189) Allow users to specify custom Ant loggers
[ https://jira.codehaus.org/browse/MANTRUN-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ion Savin updated MANTRUN-189: -- Attachment: MAVENRUN-189.patch Allow users to specify custom Ant loggers - Key: MANTRUN-189 URL: https://jira.codehaus.org/browse/MANTRUN-189 Project: Maven Antrun Plugin Issue Type: New Feature Affects Versions: 1.7 Reporter: Ion Savin Attachments: MAVENRUN-189.patch Ant allows you to specify a custom or a built-in logger other than the default one using the -logger command line flag: https://ant.apache.org/manual/listeners.html The org.apache.tools.ant.listener.ProfileLogger is one example which could be useful for maven-antrun-plugin as well as it allows you to debug slow targets directly from maven. This change allows you to configure a custom logger in maven-antrun-plugin using the logger/ configuration element. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-798) JUnit47 provider could print immediatly the test class name, as JUnit4, instead of waiting for the test to finish.
[
https://jira.codehaus.org/browse/SUREFIRE-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-798.
-
Resolution: Not A Bug
as designed
JUnit47 provider could print immediatly the test class name, as JUnit4,
instead of waiting for the test to finish.
--
Key: SUREFIRE-798
URL: https://jira.codehaus.org/browse/SUREFIRE-798
Project: Maven Surefire
Issue Type: Improvement
Components: Junit 4.7+ (parallel) support
Affects Versions: 2.10
Environment: all
Reporter: Nicolas Liochon
Priority: Minor
With a test that takes some time, for example
{noformat}
public class Test0 {
@Test
public void testT0() throws Exception {
Thread.sleep(6000);
}
}
{noformat}
With JUnit4, we have first
{noformat}Running Test0{noformat}
Then, 6 seconds later
{noformat}Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
6.002 sec{noformat}
With JUnit47, we wait for 6 seconds, then the two lines appear simultaneously.
The former behavior is better, because it allows to kill the test if we know
that this test should not take so long. It also gives the feeling that you
know what's going on :-).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-194) Output during creation of Ear is not correct
Karl-Heinz Marbaise created MEAR-194:
Summary: Output during creation of Ear is not correct
Key: MEAR-194
URL: https://jira.codehaus.org/browse/MEAR-194
Project: Maven Ear Plugin
Issue Type: Improvement
Affects Versions: 2.9.1
Reporter: Karl-Heinz Marbaise
Priority: Minor
Currently during the creation of the ear the output shows something like this:
{code}
[INFO] Building jar: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
{code}
It should be changed into:
{code}
[INFO] Building ear: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
{code}
which is more consistent.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-194) Output during creation of Ear is not correct
[
https://jira.codehaus.org/browse/MEAR-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MEAR-194:
-
Fix Version/s: 2.10
Output during creation of Ear is not correct
Key: MEAR-194
URL: https://jira.codehaus.org/browse/MEAR-194
Project: Maven Ear Plugin
Issue Type: Improvement
Affects Versions: 2.9.1
Reporter: Karl-Heinz Marbaise
Priority: Minor
Fix For: 2.10
Currently during the creation of the ear the output shows something like this:
{code}
[INFO] Building jar: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
{code}
It should be changed into:
{code}
[INFO] Building ear: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
{code}
which is more consistent.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-398) Classes from build output directory can cause failure
[ https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353191#comment-353191 ] Michal Srb commented on MJAVADOC-398: - Hello guys, I would like to deeply apologize to everyone affected by this issue. I should have been more attentive. Here's what really happened: I proposed this change: https://github.com/apache/maven-plugins/pull/25/files But from some reason, different change ended up in maven-plugins repo: https://github.com/apache/maven-plugins/commit/102c98d6f519736b832deb0ae67e1a01bad1b1c0 I guess it must have been some unfortunate mistake or glitch in some tool. I am truly sorry for all the inconvenience caused by this. Classes from build output directory can cause failure - Key: MJAVADOC-398 URL: https://jira.codehaus.org/browse/MJAVADOC-398 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Reporter: Michal Srb Assignee: Michael Osipov Fix For: 2.10 maven-javadoc-plugin adds compiled classes from build output directory to javadoc's classpath. There are certain cases when this can lead to either incorrect serialized-form.html page or failure (in case of jdk8). See [1] for more details. I think that having classes from build output directory on javadoc's classpath is not necessary. It may cause only problems and user can call javadoc:javadoc before actual build anyway. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-407) cannot parse annotations : when generating javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353192#comment-353192
]
Michal Srb commented on MJAVADOC-407:
-
Hello guys,
I would like to deeply apologize to everyone affected by this issue. The
problem with MJAVADOC-398 is that, by some mistake, different than proposed
change ended up in the Apache repository. It must have been some unfortunate
mistake or glitch in some tool. Please see MJAVADOC-398 for more details.
cannot parse annotations : when generating javadoc
---
Key: MJAVADOC-407
URL: https://jira.codehaus.org/browse/MJAVADOC-407
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux and windows.
Maven 3.0.4 , JDK 1.6.0.43
Reporter: jeff porter
Assignee: Dennis Lundberg
Fix For: 2.10.1
Attachments: AbstractJavadocMojo.java.patch
See full issue text at :
http://stackoverflow.com/questions/25971832/javadoc-generation-failed-classcastexception-com-sun-tools-javadoc-classdocim
I'm getting the following error when I do
{noformat}mvn clean deploy -DperformRelease=true
[ERROR] Exit code: 1 - .java:3: package javax.inject does not exist
[ERROR] import javax.inject.Named;
[ERROR]
[ERROR] TransactionServiceExternalImpl.java:5: cannot find symbol
[ERROR] symbol: class Named
[ERROR] @Named(transactionServiceExternal)
[ERROR]
[ERROR] java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl
cannot be cast to com.sun.javadoc.AnnotationTypeDoc{noformat}
The POM is this...
{code:xml}groupIdcom.xxx/groupId
artifactIdts-impl/artifactId
version2.4.0-SNAPSHOT/version
dependencies
dependency
groupIdjavax.inject/groupId
artifactIdjavax.inject/artifactId
version1/version
/dependency
/dependencies{code}
There is only one class...
{code:java}import javax.inject.Named;
@Named(transactionServiceExternal)
public class TransactionServiceExternalImpl
{
}{code}
I get the error with
jdk1.5.0_22
jdk1.6.0_29
jdk1.6.0_43
jdk1.6.0_43_32bit
But NOT with...
jdk1.7.0_05
Anyone have any ideas?
Notes: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
I now know that the reason is that the Maven Javadoc Plugin has changed from
2.9.1 to 2.10. and this is the cause of the problem.
I can see this warning...
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing. [WARNING]
'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-deploy-plugin is missing.
By setting the following in my pom
org.apache.maven.plugins maven-javadoc-plugin 2.9.1 attach-javadocs jar
I can fix the version back to the last release.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MANTRUN-190) Upgrade Ant to 1.9.x
Ion Savin created MANTRUN-190: - Summary: Upgrade Ant to 1.9.x Key: MANTRUN-190 URL: https://jira.codehaus.org/browse/MANTRUN-190 Project: Maven Antrun Plugin Issue Type: New Feature Affects Versions: 1.7 Reporter: Ion Savin Upgrade the underlying Ant dependency fro, 1.8.2 to 1.9.4 (latest). The new version resolves slow external process execution issues: https://issues.apache.org/bugzilla/show_bug.cgi?id=54128 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTRUN-190) Upgrade Ant to 1.9.x
[ https://jira.codehaus.org/browse/MANTRUN-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ion Savin updated MANTRUN-190: -- Attachment: MANTRUN-190.patch Upgrade Ant to 1.9.x Key: MANTRUN-190 URL: https://jira.codehaus.org/browse/MANTRUN-190 Project: Maven Antrun Plugin Issue Type: New Feature Affects Versions: 1.7 Reporter: Ion Savin Attachments: MANTRUN-190.patch Upgrade the underlying Ant dependency fro, 1.8.2 to 1.9.4 (latest). The new version resolves slow external process execution issues: https://issues.apache.org/bugzilla/show_bug.cgi?id=54128 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-407) cannot parse annotations : when generating javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353193#comment-353193
]
Emeric MARTINEAU commented on MJAVADOC-407:
---
Ok, if I understand well your issue with OpenJDK 8, you need exclude only build
output directory (xxx\targer\) from classpath.
That meens is this line that cause your issue :
{code}
private String getClasspath()
throws MavenReportException
{
...
classpathElements.addAll( getProjectBuildOutputDirs( project ) );
{code}
That's right ?
If there, it's easy to purpose patch.
But comment :
http://jira.codehaus.org/browse/MJAVADOC-398?focusedCommentId=353169page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-353169
raise many question.
cannot parse annotations : when generating javadoc
---
Key: MJAVADOC-407
URL: https://jira.codehaus.org/browse/MJAVADOC-407
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux and windows.
Maven 3.0.4 , JDK 1.6.0.43
Reporter: jeff porter
Assignee: Dennis Lundberg
Fix For: 2.10.1
Attachments: AbstractJavadocMojo.java.patch
See full issue text at :
http://stackoverflow.com/questions/25971832/javadoc-generation-failed-classcastexception-com-sun-tools-javadoc-classdocim
I'm getting the following error when I do
{noformat}mvn clean deploy -DperformRelease=true
[ERROR] Exit code: 1 - .java:3: package javax.inject does not exist
[ERROR] import javax.inject.Named;
[ERROR]
[ERROR] TransactionServiceExternalImpl.java:5: cannot find symbol
[ERROR] symbol: class Named
[ERROR] @Named(transactionServiceExternal)
[ERROR]
[ERROR] java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl
cannot be cast to com.sun.javadoc.AnnotationTypeDoc{noformat}
The POM is this...
{code:xml}groupIdcom.xxx/groupId
artifactIdts-impl/artifactId
version2.4.0-SNAPSHOT/version
dependencies
dependency
groupIdjavax.inject/groupId
artifactIdjavax.inject/artifactId
version1/version
/dependency
/dependencies{code}
There is only one class...
{code:java}import javax.inject.Named;
@Named(transactionServiceExternal)
public class TransactionServiceExternalImpl
{
}{code}
I get the error with
jdk1.5.0_22
jdk1.6.0_29
jdk1.6.0_43
jdk1.6.0_43_32bit
But NOT with...
jdk1.7.0_05
Anyone have any ideas?
Notes: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
I now know that the reason is that the Maven Javadoc Plugin has changed from
2.9.1 to 2.10. and this is the cause of the problem.
I can see this warning...
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing. [WARNING]
'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-deploy-plugin is missing.
By setting the following in my pom
org.apache.maven.plugins maven-javadoc-plugin 2.9.1 attach-javadocs jar
I can fix the version back to the last release.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-407) cannot parse annotations : when generating javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353195#comment-353195
]
Michal Srb commented on MJAVADOC-407:
-
@Emeric
Correct, that's the line. But making it configurable is probably a good idea.
javadoc tool seems to be full of surprises.
cannot parse annotations : when generating javadoc
---
Key: MJAVADOC-407
URL: https://jira.codehaus.org/browse/MJAVADOC-407
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux and windows.
Maven 3.0.4 , JDK 1.6.0.43
Reporter: jeff porter
Assignee: Dennis Lundberg
Fix For: 2.10.1
Attachments: AbstractJavadocMojo.java.patch
See full issue text at :
http://stackoverflow.com/questions/25971832/javadoc-generation-failed-classcastexception-com-sun-tools-javadoc-classdocim
I'm getting the following error when I do
{noformat}mvn clean deploy -DperformRelease=true
[ERROR] Exit code: 1 - .java:3: package javax.inject does not exist
[ERROR] import javax.inject.Named;
[ERROR]
[ERROR] TransactionServiceExternalImpl.java:5: cannot find symbol
[ERROR] symbol: class Named
[ERROR] @Named(transactionServiceExternal)
[ERROR]
[ERROR] java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl
cannot be cast to com.sun.javadoc.AnnotationTypeDoc{noformat}
The POM is this...
{code:xml}groupIdcom.xxx/groupId
artifactIdts-impl/artifactId
version2.4.0-SNAPSHOT/version
dependencies
dependency
groupIdjavax.inject/groupId
artifactIdjavax.inject/artifactId
version1/version
/dependency
/dependencies{code}
There is only one class...
{code:java}import javax.inject.Named;
@Named(transactionServiceExternal)
public class TransactionServiceExternalImpl
{
}{code}
I get the error with
jdk1.5.0_22
jdk1.6.0_29
jdk1.6.0_43
jdk1.6.0_43_32bit
But NOT with...
jdk1.7.0_05
Anyone have any ideas?
Notes: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
I now know that the reason is that the Maven Javadoc Plugin has changed from
2.9.1 to 2.10. and this is the cause of the problem.
I can see this warning...
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing. [WARNING]
'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-deploy-plugin is missing.
By setting the following in my pom
org.apache.maven.plugins maven-javadoc-plugin 2.9.1 attach-javadocs jar
I can fix the version back to the last release.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-406) The functionality of MJAVADOC-398 should be configurable
[
https://jira.codehaus.org/browse/MJAVADOC-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353199#comment-353199
]
Michael Osipov commented on MJAVADOC-406:
-
As it turns out, this commit was incorrect. Are you able to test a SNAPSHOT
which I will upload soon?
The functionality of MJAVADOC-398 should be configurable
Key: MJAVADOC-406
URL: https://jira.codehaus.org/browse/MJAVADOC-406
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: Martin Skurla
Assignee: Dennis Lundberg
Priority: Critical
Fix For: 2.10.1
The functionality/change behavior of MJAVADOC-398 should definitely be
configurable.
In our project we have to manually put a lot of dependencies into
{{additionalDependencies}} section to restore the previously working
behaviour which is a huge pain and does not scale (as we will be forced to
update the dependencies every time dependencies are added to projects).
Please provide a javadoc configuration for turning on/off the functionality
added in MJAVADOC-398.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-398) Classes from build output directory can cause failure
[ https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353198#comment-353198 ] Michael Osipov commented on MJAVADOC-398: - Dammit, I have, indeed, deleted the wrong line without noticing it. Classes from build output directory can cause failure - Key: MJAVADOC-398 URL: https://jira.codehaus.org/browse/MJAVADOC-398 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Reporter: Michal Srb Assignee: Michael Osipov Fix For: 2.10 maven-javadoc-plugin adds compiled classes from build output directory to javadoc's classpath. There are certain cases when this can lead to either incorrect serialized-form.html page or failure (in case of jdk8). See [1] for more details. I think that having classes from build output directory on javadoc's classpath is not necessary. It may cause only problems and user can call javadoc:javadoc before actual build anyway. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-406) The functionality of MJAVADOC-398 should be configurable
[
https://jira.codehaus.org/browse/MJAVADOC-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MJAVADOC-406:
---
Assignee: Michael Osipov (was: Dennis Lundberg)
The functionality of MJAVADOC-398 should be configurable
Key: MJAVADOC-406
URL: https://jira.codehaus.org/browse/MJAVADOC-406
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: Martin Skurla
Assignee: Michael Osipov
Priority: Critical
Fix For: 2.10.1
The functionality/change behavior of MJAVADOC-398 should definitely be
configurable.
In our project we have to manually put a lot of dependencies into
{{additionalDependencies}} section to restore the previously working
behaviour which is a huge pain and does not scale (as we will be forced to
update the dependencies every time dependencies are added to projects).
Please provide a javadoc configuration for turning on/off the functionality
added in MJAVADOC-398.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-406) Regression: MJAVADOC-398 commit changed wrong line
[
https://jira.codehaus.org/browse/MJAVADOC-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-406:
Summary: Regression: MJAVADOC-398 commit changed wrong line (was: The
functionality of MJAVADOC-398 should be configurable)
Regression: MJAVADOC-398 commit changed wrong line
--
Key: MJAVADOC-406
URL: https://jira.codehaus.org/browse/MJAVADOC-406
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: Martin Skurla
Assignee: Michael Osipov
Priority: Critical
Fix For: 2.10.1
The functionality/change behavior of MJAVADOC-398 should definitely be
configurable.
In our project we have to manually put a lot of dependencies into
{{additionalDependencies}} section to restore the previously working
behaviour which is a huge pain and does not scale (as we will be forced to
update the dependencies every time dependencies are added to projects).
Please provide a javadoc configuration for turning on/off the functionality
added in MJAVADOC-398.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1098) runOrder=balanced is not working
[
https://jira.codehaus.org/browse/SUREFIRE-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353203#comment-353203
]
Tibor Digana commented on SUREFIRE-1098:
Miyata, the order in parallel execution cannot be guaranteed.
I cannot tell the thread-pool which test class to take first.
Cannot guarantee that all four tests would finish at the same time.
The only guarantee is that both Threads would always process yet unexecuted
test.
runOrder=balanced is not working
Key: SUREFIRE-1098
URL: https://jira.codehaus.org/browse/SUREFIRE-1098
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.12.2, 2.12.3, 2.12.4, 2.13, 2.14, 2.14.1, 2.15, 2.16,
2.17
Environment: JDK 7 on Linux
JUnit 4.11
Reporter: Miyata Jumpei
It seems that the runOrder parameter with balanced value is not working.
For example, I created a project with the following setting.
{code}
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.17/version
configuration
parallelclasses/parallel
runOrderbalanced/runOrder
threadCount2/threadCount
perCoreThreadCountfalse/perCoreThreadCount
/configuration
/plugin
{code}
Then, execute the following tests.
TestA: 1 second
TestB: 2 seconds
TestC: 3 seconds
TestD: 4 seconds
The expected order is the following from the second time.
Thread 1: TestD #8594; TestA
Thread 2: TestC #8594; TestB
However, the actual order is the following.
Thread 1: TestB #8594; TestD
Thread 2: TestC #8594; TestA
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1098) runOrder=balanced is not working
[
https://jira.codehaus.org/browse/SUREFIRE-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353204#comment-353204
]
Miyata Jumpei commented on SUREFIRE-1098:
-
In the current implementation, it seems that the static file is different
between read and written.
It makes no sense.
I wrote the reason in the pull-request.
It must not be the expected behaviour.
In 2.11, 2.12 and 2.12.1, the tests are executed in the order of long time.
runOrder=balanced is not working
Key: SUREFIRE-1098
URL: https://jira.codehaus.org/browse/SUREFIRE-1098
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.12.2, 2.12.3, 2.12.4, 2.13, 2.14, 2.14.1, 2.15, 2.16,
2.17
Environment: JDK 7 on Linux
JUnit 4.11
Reporter: Miyata Jumpei
It seems that the runOrder parameter with balanced value is not working.
For example, I created a project with the following setting.
{code}
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.17/version
configuration
parallelclasses/parallel
runOrderbalanced/runOrder
threadCount2/threadCount
perCoreThreadCountfalse/perCoreThreadCount
/configuration
/plugin
{code}
Then, execute the following tests.
TestA: 1 second
TestB: 2 seconds
TestC: 3 seconds
TestD: 4 seconds
The expected order is the following from the second time.
Thread 1: TestD #8594; TestA
Thread 2: TestC #8594; TestB
However, the actual order is the following.
Thread 1: TestB #8594; TestD
Thread 2: TestC #8594; TestA
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-413) bootclasspathArtifacts override values on bootclasspath
Rafael Fontes created MJAVADOC-413: -- Summary: bootclasspathArtifacts override values on bootclasspath Key: MJAVADOC-413 URL: https://jira.codehaus.org/browse/MJAVADOC-413 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10 Environment: Anyone Reporter: Rafael Fontes I'm using a custom doclet, and in order to make it properly work I need to add the rt.jar to the bootclasspath. Since i'm defining the bootclasspathArtifacts both can't coexist. The solution is to define all the dependency jars in the bootclasspath. And it's very usefull the use of the bootclasspathArtifacts. The error that i descibre above that appear in the lack of the rt.jar is: Exit code: 1 - com.sun.tools.javac.util.FatalError: Fatal Error: Unable to find package java.lang in classpath or bootclasspath -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-413) bootclasspathArtifacts override values on bootclasspath
[ https://jira.codehaus.org/browse/MJAVADOC-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Fontes updated MJAVADOC-413: --- Environment: Any (was: Anyone) bootclasspathArtifacts override values on bootclasspath --- Key: MJAVADOC-413 URL: https://jira.codehaus.org/browse/MJAVADOC-413 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10 Environment: Any Reporter: Rafael Fontes I'm using a custom doclet, and in order to make it properly work I need to add the rt.jar to the bootclasspath. Since i'm defining the bootclasspathArtifacts both can't coexist. The solution is to define all the dependency jars in the bootclasspath. And it's very usefull the use of the bootclasspathArtifacts. The error that i descibre above that appear in the lack of the rt.jar is: Exit code: 1 - com.sun.tools.javac.util.FatalError: Fatal Error: Unable to find package java.lang in classpath or bootclasspath -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-413) bootclasspathArtifacts override values on bootclasspath
[
https://jira.codehaus.org/browse/MJAVADOC-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Fontes updated MJAVADOC-413:
---
Description:
I'm using a custom doclet, and in order to make it properly work I need to add
the rt.jar to the bootclasspath, this only happens using the
maven-javadoc-plugin. I'm defining the bootclasspathArtifacts as expected, but
due the need to add the rt.jar i have tried to also add the bootclasspath
already with a value (bootclasspath${java.home}\lib\rt.jar;/bootclasspath).
There is a workaround, don't use the bootclasspathArtifacts and define
everything that is need on the bootclasspath. But using the Artifacts its the
best way to do it.
The error that i descibre above that appear in the lack of the rt.jar is:
Exit code: 1 - com.sun.tools.javac.util.FatalError: Fatal Error: Unable to find
package java.lang in classpath or bootclasspath
was:
I'm using a custom doclet, and in order to make it properly work I need to add
the rt.jar to the bootclasspath. Since i'm defining the bootclasspathArtifacts
both can't coexist.
The solution is to define all the dependency jars in the bootclasspath. And
it's very usefull the use of the bootclasspathArtifacts.
The error that i descibre above that appear in the lack of the rt.jar is:
Exit code: 1 - com.sun.tools.javac.util.FatalError: Fatal Error: Unable to find
package java.lang in classpath or bootclasspath
bootclasspathArtifacts override values on bootclasspath
---
Key: MJAVADOC-413
URL: https://jira.codehaus.org/browse/MJAVADOC-413
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Any
Reporter: Rafael Fontes
I'm using a custom doclet, and in order to make it properly work I need to
add the rt.jar to the bootclasspath, this only happens using the
maven-javadoc-plugin. I'm defining the bootclasspathArtifacts as expected,
but due the need to add the rt.jar i have tried to also add the bootclasspath
already with a value
(bootclasspath${java.home}\lib\rt.jar;/bootclasspath).
There is a workaround, don't use the bootclasspathArtifacts and define
everything that is need on the bootclasspath. But using the Artifacts its the
best way to do it.
The error that i descibre above that appear in the lack of the rt.jar is:
Exit code: 1 - com.sun.tools.javac.util.FatalError: Fatal Error: Unable to
find package java.lang in classpath or bootclasspath
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-176) Suppress warning output
[ https://jira.codehaus.org/browse/MSHADE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSHADE-176. - Resolution: Won't Fix Assignee: Robert Scholte Suppress warning output --- Key: MSHADE-176 URL: https://jira.codehaus.org/browse/MSHADE-176 Project: Maven Shade Plugin Issue Type: Improvement Reporter: Taylor Jones Assignee: Robert Scholte Fix For: 2.4 Attachments: suppressWarnings_option.patch The warnings Shade outputs are useful, but there are some cases where nothing can actually be done about them. Recently, I encountered this with the Neo4j libraries; there is one overlapping class between two critical JARs (kernel and rest), and no way to resolve this via exclusions. In these cases, everything works just fine. At best, the warnings are just noise, but we also have some build processes in place that will fail on Maven warnings. I figured this would be a pretty simple thing to just suppress, but Shade doesn't seem to have a way to do this. I've included a simple patchset to address this which adds a new option to the configuration called suppressWarnings. There isn't a unit test attached, unfortunately. I'm not quite sure how to unit test logging output in this fashion without something akin to Mockito. I figured you guys wouldn't appreciate me adding dependencies out of the blue but if a unit test is required, I can give it a shot. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-406) Regression: MJAVADOC-398 commit changed wrong line
[
https://jira.codehaus.org/browse/MJAVADOC-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353215#comment-353215
]
David J. Liszewski commented on MJAVADOC-406:
-
Thanks Michael.
How would I test it with {{maven-release-plugin}}, as that was failing in
{{release:perform}} which doesn't have an option to allow SNAPSHOT dependencies?
Regression: MJAVADOC-398 commit changed wrong line
--
Key: MJAVADOC-406
URL: https://jira.codehaus.org/browse/MJAVADOC-406
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: Martin Skurla
Assignee: Michael Osipov
Priority: Critical
Fix For: 2.10.1
The functionality/change behavior of MJAVADOC-398 should definitely be
configurable.
In our project we have to manually put a lot of dependencies into
{{additionalDependencies}} section to restore the previously working
behaviour which is a huge pain and does not scale (as we will be forced to
update the dependencies every time dependencies are added to projects).
Please provide a javadoc configuration for turning on/off the functionality
added in MJAVADOC-398.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-398) Classes from build output directory can cause failure
[ https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353219#comment-353219 ] Herve Boutemy commented on MJAVADOC-398: notice that it is another proof of some well know good practice that is so hard to do on daily operations: bq. don't fix anything without previously creating an IT to prove that the fix does the expected job I know that it's really rude, because for such little fixes, creating the IT is much more work than the fix itself and some people tend to not understand why patches told fixing something are not applied experience learned the hard way (TM): you're not the first, that's something you won't forget :) Classes from build output directory can cause failure - Key: MJAVADOC-398 URL: https://jira.codehaus.org/browse/MJAVADOC-398 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Reporter: Michal Srb Assignee: Michael Osipov Fix For: 2.10 maven-javadoc-plugin adds compiled classes from build output directory to javadoc's classpath. There are certain cases when this can lead to either incorrect serialized-form.html page or failure (in case of jdk8). See [1] for more details. I think that having classes from build output directory on javadoc's classpath is not necessary. It may cause only problems and user can call javadoc:javadoc before actual build anyway. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1098) runOrder=balanced is not working
[
https://jira.codehaus.org/browse/SUREFIRE-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1098:
-
Fix Version/s: 2.18
runOrder=balanced is not working
Key: SUREFIRE-1098
URL: https://jira.codehaus.org/browse/SUREFIRE-1098
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.12.2, 2.12.3, 2.12.4, 2.13, 2.14, 2.14.1, 2.15, 2.16,
2.17
Environment: JDK 7 on Linux
JUnit 4.11
Reporter: Miyata Jumpei
Fix For: 2.18
It seems that the runOrder parameter with balanced value is not working.
For example, I created a project with the following setting.
{code}
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.17/version
configuration
parallelclasses/parallel
runOrderbalanced/runOrder
threadCount2/threadCount
perCoreThreadCountfalse/perCoreThreadCount
/configuration
/plugin
{code}
Then, execute the following tests.
TestA: 1 second
TestB: 2 seconds
TestC: 3 seconds
TestD: 4 seconds
The expected order is the following from the second time.
Thread 1: TestD #8594; TestA
Thread 2: TestC #8594; TestB
However, the actual order is the following.
Thread 1: TestB #8594; TestD
Thread 2: TestC #8594; TestA
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1098) runOrder=balanced is not working
[
https://jira.codehaus.org/browse/SUREFIRE-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353220#comment-353220
]
Andreas Gudian commented on SUREFIRE-1098:
--
Tibor, could you take a look if the the suggested fix has an effect?
IIRC, the j.u.concurrent.ThreadPoolExecutor takes the next work item to process
from the top of the queue, while newly submitted tasks land at the tail of the
queue (which is the purpose of calling it a queue). So feeding the tests into
the thread pool executor ordered by descending execution time (which I think is
what balanced would try to do), should have the desired effect.
runOrder=balanced is not working
Key: SUREFIRE-1098
URL: https://jira.codehaus.org/browse/SUREFIRE-1098
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.12.2, 2.12.3, 2.12.4, 2.13, 2.14, 2.14.1, 2.15, 2.16,
2.17
Environment: JDK 7 on Linux
JUnit 4.11
Reporter: Miyata Jumpei
Fix For: 2.18
It seems that the runOrder parameter with balanced value is not working.
For example, I created a project with the following setting.
{code}
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.17/version
configuration
parallelclasses/parallel
runOrderbalanced/runOrder
threadCount2/threadCount
perCoreThreadCountfalse/perCoreThreadCount
/configuration
/plugin
{code}
Then, execute the following tests.
TestA: 1 second
TestB: 2 seconds
TestC: 3 seconds
TestD: 4 seconds
The expected order is the following from the second time.
Thread 1: TestD #8594; TestA
Thread 2: TestC #8594; TestB
However, the actual order is the following.
Thread 1: TestB #8594; TestD
Thread 2: TestC #8594; TestA
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1096) ClassCastException: Fork test for TestNG with xmlsuite
[ https://jira.codehaus.org/browse/SUREFIRE-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian reassigned SUREFIRE-1096: Assignee: Andreas Gudian ClassCastException: Fork test for TestNG with xmlsuite -- Key: SUREFIRE-1096 URL: https://jira.codehaus.org/browse/SUREFIRE-1096 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.14, 2.15, 2.16, 2.17 Reporter: Michal Bocek Assignee: Andreas Gudian When i setup surefire for forking tests via: forkCount3/forkCount reuseForkstrue/reuseForks parallelfalse/parallel And i'm using TestNG provider with xml suite definition: suiteXmlFiles suiteXmlFilesuite.xml/suiteXmlFile /suiteXmlFiles I'm getting exception: Caused by: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.Class at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:201) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:160) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:806) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:701) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:629) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1096) ClassCastException: Fork test for TestNG with xmlsuite
[ https://jira.codehaus.org/browse/SUREFIRE-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353223#comment-353223 ] Andreas Gudian commented on SUREFIRE-1096: -- That exception is really emberrasing and we should deal with that case properly. But: forkCount=3 and reuseForks=true won't have much effect when using a suite.xml anyway. Surefire creates the forked JVMs, but TestNG is responsible for executing the units of work that we feed in. Typically, we feed in the test classes, which we would do indiviually in case of reuseForks=true and forkCount1. In this case, we only have one unit of work that Surefire understands: that suite.xml. What we could (and should) support is to correctly feed in the suite.xml, and if there is more than one specified, feed them in separately in the different JVM forks. I'll set the issue to fixVersion 2.18, but it's more likely that it won't make it into this one. I would then push it to the next release. In the meantime, it should work for you with forkCount=1. Is that OK? ClassCastException: Fork test for TestNG with xmlsuite -- Key: SUREFIRE-1096 URL: https://jira.codehaus.org/browse/SUREFIRE-1096 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.14, 2.15, 2.16, 2.17 Reporter: Michal Bocek Assignee: Andreas Gudian Fix For: 2.18 When i setup surefire for forking tests via: forkCount3/forkCount reuseForkstrue/reuseForks parallelfalse/parallel And i'm using TestNG provider with xml suite definition: suiteXmlFiles suiteXmlFilesuite.xml/suiteXmlFile /suiteXmlFiles I'm getting exception: Caused by: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.Class at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:201) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:160) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:806) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:701) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:629) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1096) ClassCastException: Fork test for TestNG with xmlsuite
[ https://jira.codehaus.org/browse/SUREFIRE-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian updated SUREFIRE-1096: - Fix Version/s: 2.18 ClassCastException: Fork test for TestNG with xmlsuite -- Key: SUREFIRE-1096 URL: https://jira.codehaus.org/browse/SUREFIRE-1096 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.14, 2.15, 2.16, 2.17 Reporter: Michal Bocek Assignee: Andreas Gudian Fix For: 2.18 When i setup surefire for forking tests via: forkCount3/forkCount reuseForkstrue/reuseForks parallelfalse/parallel And i'm using TestNG provider with xml suite definition: suiteXmlFiles suiteXmlFilesuite.xml/suiteXmlFile /suiteXmlFiles I'm getting exception: Caused by: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.Class at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:201) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:160) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:806) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:701) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:629) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-398) Classes from build output directory can cause failure
[ https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353224#comment-353224 ] Michael Osipov commented on MJAVADOC-398: - [~hboutemy], true words. Very true. That would ultimately mean that we need to require a test case from the reporters in order to process the bug and finally fix it with an IT. Even it is so simple to fix. Classes from build output directory can cause failure - Key: MJAVADOC-398 URL: https://jira.codehaus.org/browse/MJAVADOC-398 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Reporter: Michal Srb Assignee: Michael Osipov Fix For: 2.10 maven-javadoc-plugin adds compiled classes from build output directory to javadoc's classpath. There are certain cases when this can lead to either incorrect serialized-form.html page or failure (in case of jdk8). See [1] for more details. I think that having classes from build output directory on javadoc's classpath is not necessary. It may cause only problems and user can call javadoc:javadoc before actual build anyway. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1023) Report generation fails with StringIndexOutOfBoundsException
[
https://jira.codehaus.org/browse/SUREFIRE-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian reassigned SUREFIRE-1023:
Assignee: Andreas Gudian
Report generation fails with StringIndexOutOfBoundsException
Key: SUREFIRE-1023
URL: https://jira.codehaus.org/browse/SUREFIRE-1023
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Report Plugin
Affects Versions: 2.15
Environment: Linux with Maven 3.0.5
Reporter: Pavel Orehov
Assignee: Andreas Gudian
Priority: Blocker
When Maven generating report for big project (3K+ junit tests) getting the
following error:
{code}
[exec] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report
(default-cli) on project ana_classes: Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1 - [Help 1]
[exec] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report
(default-cli) on project ana_classes: Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[exec] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[exec] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[exec] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[exec] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[exec] at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[exec] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[exec] at java.lang.reflect.Method.invoke(Method.java:597)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[exec] Caused by: org.apache.maven.plugin.PluginExecutionException:
Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1
[exec] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[exec] ... 19 more
[exec] Caused by: java.lang.StringIndexOutOfBoundsException: String
index out of range: -1
[exec] at java.lang.String.substring(String.java:1937)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.getErrorLineNumber(SurefireReportGenerator.java:677)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.constructFailureDetails(SurefireReportGenerator.java:640)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:104)
[exec] at
org.apache.maven.plugins.surefire.report.AbstractSurefireReportMojo.executeReport(AbstractSurefireReportMojo.java:184)
[exec] at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
[exec] at
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:99)
[exec] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[exec] ... 20 more
{code}
--
This message was sent by Atlassian JIRA
[jira] (SUREFIRE-1023) Report generation fails with StringIndexOutOfBoundsException
[
https://jira.codehaus.org/browse/SUREFIRE-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1023:
-
Description:
When Maven generating report for big project (3K+ junit tests) getting the
following error:
{code}
[exec] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report (default-cli)
on project ana_classes: Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1 - [Help 1]
[exec] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report
(default-cli) on project ana_classes: Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[exec] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[exec] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[exec] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[exec] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[exec] at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[exec] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[exec] at java.lang.reflect.Method.invoke(Method.java:597)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[exec] Caused by: org.apache.maven.plugin.PluginExecutionException:
Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1
[exec] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[exec] ... 19 more
[exec] Caused by: java.lang.StringIndexOutOfBoundsException: String index
out of range: -1
[exec] at java.lang.String.substring(String.java:1937)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.getErrorLineNumber(SurefireReportGenerator.java:677)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.constructFailureDetails(SurefireReportGenerator.java:640)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:104)
[exec] at
org.apache.maven.plugins.surefire.report.AbstractSurefireReportMojo.executeReport(AbstractSurefireReportMojo.java:184)
[exec] at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
[exec] at
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:99)
[exec] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[exec] ... 20 more
{code}
was:
When Maven generating report for big project (3K+ junit tests) getting the
following error:
[exec] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report (default-cli)
on project ana_classes: Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1 - [Help 1]
[exec] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report
(default-cli) on project ana_classes: Execution
[jira] (MJAVADOC-406) Regression: MJAVADOC-398 commit changed wrong line
[
https://jira.codehaus.org/browse/MJAVADOC-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353225#comment-353225
]
Michael Osipov commented on MJAVADOC-406:
-
David, you do not depend on a SNAPSHOT dependency but on a SNAPSHOT plugin. But
I guess that would have the same outcome. You can test it the following way:
1. Have Maven download the SNAPSHOT from Apache Snaphots Repo
2. Change the version number manually to something non-SNAPSHOT
3. Try your {{mvn release:prepare release:perform}}.
Regression: MJAVADOC-398 commit changed wrong line
--
Key: MJAVADOC-406
URL: https://jira.codehaus.org/browse/MJAVADOC-406
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: Martin Skurla
Assignee: Michael Osipov
Priority: Critical
Fix For: 2.10.1
The functionality/change behavior of MJAVADOC-398 should definitely be
configurable.
In our project we have to manually put a lot of dependencies into
{{additionalDependencies}} section to restore the previously working
behaviour which is a huge pain and does not scale (as we will be forced to
update the dependencies every time dependencies are added to projects).
Please provide a javadoc configuration for turning on/off the functionality
added in MJAVADOC-398.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-749) Parallel methods should run in separate classloaders
[ https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353227#comment-353227 ] Andreas Gudian commented on SUREFIRE-749: - I must agree with Kristian and Tibor here. Running parallel tests in different isolated classloaders is IMHO something that would be counterproductive to what the parallel execution within one JVM is to bring in. For real isolation between concurrent tests, there are our fork options (forkCount, reuseForks). However, that creates concurrency on test class level only and not on method (@Test) level. Personally, if I had that use case, I would just create an appropriate JUnit runner implementation - which should actually be quite streight forward and not that hard to do (taking for instance BlockJunit4ClassRunner as a starting point). So I'd also vote to close this as wont-fix. Parallel methods should run in separate classloaders Key: SUREFIRE-749 URL: https://jira.codehaus.org/browse/SUREFIRE-749 Project: Maven Surefire Issue Type: New Feature Components: Junit 4.7+ (parallel) support Affects Versions: 2.8.1 Reporter: Gili When running in parallel-method or parallel-both mode, each @Test should run in its own ClassLoader. I'm running into a lot of problems involving the use of static variables in 3rd-party libraries. Here are two examples: 1. slf4j: http://bugzilla.slf4j.org/show_bug.cgi?id=176 2. guice: http://code.google.com/p/google-guice/issues/detail?id=635 I believe running in isolated ClassLoaders would fix both problems and it makes a lot of sense from a test isolation point of view so we should do it anyway. I believe Surefire's forkMode is defined in terms of isolated JVMs instead of ClassLoaders. Furthermore, it only seems to support per-Class isolation instead of per-@Test isolation. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-406) Regression: MJAVADOC-398 commit changed wrong line
[
https://jira.codehaus.org/browse/MJAVADOC-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353228#comment-353228
]
Robert Scholte commented on MJAVADOC-406:
-
There's absolutely no reason to do this with the maven-release-plugin. Just use
the same arguments as {{release:perform}} does: {{mvn deploy site-deploy
-Prelease-profile}}
Regression: MJAVADOC-398 commit changed wrong line
--
Key: MJAVADOC-406
URL: https://jira.codehaus.org/browse/MJAVADOC-406
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: Martin Skurla
Assignee: Michael Osipov
Priority: Critical
Fix For: 2.10.1
The functionality/change behavior of MJAVADOC-398 should definitely be
configurable.
In our project we have to manually put a lot of dependencies into
{{additionalDependencies}} section to restore the previously working
behaviour which is a huge pain and does not scale (as we will be forced to
update the dependencies every time dependencies are added to projects).
Please provide a javadoc configuration for turning on/off the functionality
added in MJAVADOC-398.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1023) Report generation fails with StringIndexOutOfBoundsException
[
https://jira.codehaus.org/browse/SUREFIRE-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1023:
-
Fix Version/s: 2.18
Report generation fails with StringIndexOutOfBoundsException
Key: SUREFIRE-1023
URL: https://jira.codehaus.org/browse/SUREFIRE-1023
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Report Plugin
Affects Versions: 2.15
Environment: Linux with Maven 3.0.5
Reporter: Pavel Orehov
Assignee: Andreas Gudian
Priority: Blocker
Fix For: 2.18
When Maven generating report for big project (3K+ junit tests) getting the
following error:
{code}
[exec] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report
(default-cli) on project ana_classes: Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1 - [Help 1]
[exec] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report
(default-cli) on project ana_classes: Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[exec] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[exec] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[exec] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[exec] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[exec] at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[exec] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[exec] at java.lang.reflect.Method.invoke(Method.java:597)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[exec] Caused by: org.apache.maven.plugin.PluginExecutionException:
Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1
[exec] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[exec] ... 19 more
[exec] Caused by: java.lang.StringIndexOutOfBoundsException: String
index out of range: -1
[exec] at java.lang.String.substring(String.java:1937)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.getErrorLineNumber(SurefireReportGenerator.java:677)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.constructFailureDetails(SurefireReportGenerator.java:640)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:104)
[exec] at
org.apache.maven.plugins.surefire.report.AbstractSurefireReportMojo.executeReport(AbstractSurefireReportMojo.java:184)
[exec] at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
[exec] at
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:99)
[exec] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[exec] ... 20 more
{code}
--
This message was sent by
[jira] (SUREFIRE-1096) ClassCastException: Fork test for TestNG with xmlsuite
[ https://jira.codehaus.org/browse/SUREFIRE-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353229#comment-353229 ] Michal Bocek commented on SUREFIRE-1096: Sounds good. At the moment we decided to use different strategy of test execution but it will be nice to know that more suites.xml files will be possible to execute in forked jvms. Thank you. ClassCastException: Fork test for TestNG with xmlsuite -- Key: SUREFIRE-1096 URL: https://jira.codehaus.org/browse/SUREFIRE-1096 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.14, 2.15, 2.16, 2.17 Reporter: Michal Bocek Assignee: Andreas Gudian Fix For: 2.18 When i setup surefire for forking tests via: forkCount3/forkCount reuseForkstrue/reuseForks parallelfalse/parallel And i'm using TestNG provider with xml suite definition: suiteXmlFiles suiteXmlFilesuite.xml/suiteXmlFile /suiteXmlFiles I'm getting exception: Caused by: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.Class at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:201) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:160) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:806) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:701) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:629) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1023) Report generation fails with StringIndexOutOfBoundsException
[
https://jira.codehaus.org/browse/SUREFIRE-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian closed SUREFIRE-1023.
Resolution: Fixed
I took a shot and I'm pretty sure I've hit it. My guess is, that Pavel uses
some test framework (cucumber or something like that) that creates its own type
of failure stack traces with lines that do not end with {{..:lineNumber)}},
as the typical Java stack traces do.
@Pavel, if possible, try the latest surefire 2.18-SNAPSHOT build to check if
the issue is fixed for you.
Report generation fails with StringIndexOutOfBoundsException
Key: SUREFIRE-1023
URL: https://jira.codehaus.org/browse/SUREFIRE-1023
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Report Plugin
Affects Versions: 2.15
Environment: Linux with Maven 3.0.5
Reporter: Pavel Orehov
Assignee: Andreas Gudian
Priority: Blocker
Fix For: 2.18
When Maven generating report for big project (3K+ junit tests) getting the
following error:
{code}
[exec] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report
(default-cli) on project ana_classes: Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1 - [Help 1]
[exec] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report
(default-cli) on project ana_classes: Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[exec] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[exec] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[exec] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[exec] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[exec] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[exec] at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[exec] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[exec] at java.lang.reflect.Method.invoke(Method.java:597)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[exec] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[exec] Caused by: org.apache.maven.plugin.PluginExecutionException:
Execution default-cli of goal
org.apache.maven.plugins:maven-surefire-report-plugin:2.15:report failed:
String index out of range: -1
[exec] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
[exec] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[exec] ... 19 more
[exec] Caused by: java.lang.StringIndexOutOfBoundsException: String
index out of range: -1
[exec] at java.lang.String.substring(String.java:1937)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.getErrorLineNumber(SurefireReportGenerator.java:677)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.constructFailureDetails(SurefireReportGenerator.java:640)
[exec] at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:104)
[exec] at
org.apache.maven.plugins.surefire.report.AbstractSurefireReportMojo.executeReport(AbstractSurefireReportMojo.java:184)
[exec] at
[jira] (SUREFIRE-1077) NPE problem will happen if you set testng status to fail at afterInvocation method
[
https://jira.codehaus.org/browse/SUREFIRE-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1077:
-
Description:
In our test program, we have some soft assert, which require us set the test
result to false at afterInovcation (IInvokedMethodListener) method, after we
did that, surefire plugin will throw a NPE exception, the stacktrace looks like
this:
{code}
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.61 sec
FAILURE!
test1(com.surefire.SimpleTest) Time elapsed: 0.044 sec FAILURE!
java.lang.NullPointerException: null
at
org.apache.maven.surefire.report.SmartStackTraceParser.init(SmartStackTraceParser.java:56)
at
org.apache.maven.surefire.report.PojoStackTraceWriter.smartTrimmedStackTrace(PojoStackTraceWriter.java:60)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:328)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:312)
at
org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:258)
at
org.apache.maven.surefire.booter.ForkingRunListener.testFailed(ForkingRunListener.java:137)
at
org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:105)
at org.testng.internal.Invoker.runTestListeners(Invoker.java:1895)
at org.testng.internal.Invoker.runTestListeners(Invoker.java:1879)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:778)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
at org.testng.SuiteRunner.run(SuiteRunner.java:254)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
at org.testng.TestNG.run(TestNG.java:1057)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:126)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110)
at
org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
{code}
I will attach a simple project to reproduce this problem.
was:
In our test program, we have some soft assert, which require us set the test
result to false at afterInovcation (IInvokedMethodListener) method, after we
did that, surefire plugin will throw a NPE exception, the stacktrace looks like
this:
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.61 sec
FAILURE!
test1(com.surefire.SimpleTest) Time elapsed: 0.044 sec FAILURE!
java.lang.NullPointerException: null
at
org.apache.maven.surefire.report.SmartStackTraceParser.init(SmartStackTraceParser.java:56)
at
org.apache.maven.surefire.report.PojoStackTraceWriter.smartTrimmedStackTrace(PojoStackTraceWriter.java:60)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:328)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:312)
at
org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:258)
at
[jira] (SUREFIRE-1096) ClassCastException: Fork test for TestNG with xmlsuite
[
https://jira.codehaus.org/browse/SUREFIRE-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1096:
-
Description:
When i setup surefire for forking tests via:
{code}
forkCount3/forkCount
reuseForkstrue/reuseForks
parallelfalse/parallel
{code}
And i'm using TestNG provider with xml suite definition:
{code}
suiteXmlFiles
suiteXmlFilesuite.xml/suiteXmlFile
/suiteXmlFiles
{code}
I'm getting exception:
{code}
Caused by: java.lang.ClassCastException: java.io.File cannot be cast to
java.lang.Class
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:201)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:160)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:806)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:701)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:629)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
{code}
was:
When i setup surefire for forking tests via:
forkCount3/forkCount
reuseForkstrue/reuseForks
parallelfalse/parallel
And i'm using TestNG provider with xml suite definition:
suiteXmlFiles
suiteXmlFilesuite.xml/suiteXmlFile
/suiteXmlFiles
I'm getting exception:
Caused by: java.lang.ClassCastException: java.io.File cannot be cast to
java.lang.Class
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:201)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:160)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:806)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:701)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:629)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
ClassCastException: Fork test for TestNG with xmlsuite
--
Key: SUREFIRE-1096
URL: https://jira.codehaus.org/browse/SUREFIRE-1096
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.14, 2.15, 2.16, 2.17
Reporter: Michal Bocek
Assignee: Andreas Gudian
Fix For: 2.18
When i setup surefire for forking tests via:
{code}
forkCount3/forkCount
reuseForkstrue/reuseForks
parallelfalse/parallel
{code}
And i'm using TestNG provider with xml suite definition:
{code}
suiteXmlFiles
suiteXmlFilesuite.xml/suiteXmlFile
/suiteXmlFiles
{code}
I'm getting exception:
{code}
Caused by: java.lang.ClassCastException: java.io.File cannot be cast to
java.lang.Class
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:201)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:160)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:806)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:701)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:629)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-406) Regression: MJAVADOC-398 commit changed wrong line
[
https://jira.codehaus.org/browse/MJAVADOC-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353232#comment-353232
]
Michael Osipov commented on MJAVADOC-406:
-
David, I just have deployed a new
[SNAPSHOT|https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/maven/plugins/maven-javadoc-plugin/2.11-SNAPSHOT/maven-javadoc-plugin-2.11-20140925.191134-19.jar]
which restores the previous behavior and really fixed MJAVADOC-398. Please
test and report.
Regression: MJAVADOC-398 commit changed wrong line
--
Key: MJAVADOC-406
URL: https://jira.codehaus.org/browse/MJAVADOC-406
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: Martin Skurla
Assignee: Michael Osipov
Priority: Critical
Fix For: 2.10.1
The functionality/change behavior of MJAVADOC-398 should definitely be
configurable.
In our project we have to manually put a lot of dependencies into
{{additionalDependencies}} section to restore the previously working
behaviour which is a huge pain and does not scale (as we will be forced to
update the dependencies every time dependencies are added to projects).
Please provide a javadoc configuration for turning on/off the functionality
added in MJAVADOC-398.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-407) cannot parse annotations : when generating javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MJAVADOC-407:
---
Assignee: Michael Osipov (was: Dennis Lundberg)
cannot parse annotations : when generating javadoc
---
Key: MJAVADOC-407
URL: https://jira.codehaus.org/browse/MJAVADOC-407
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux and windows.
Maven 3.0.4 , JDK 1.6.0.43
Reporter: jeff porter
Assignee: Michael Osipov
Fix For: 2.10.1
Attachments: AbstractJavadocMojo.java.patch
See full issue text at :
http://stackoverflow.com/questions/25971832/javadoc-generation-failed-classcastexception-com-sun-tools-javadoc-classdocim
I'm getting the following error when I do
{noformat}mvn clean deploy -DperformRelease=true
[ERROR] Exit code: 1 - .java:3: package javax.inject does not exist
[ERROR] import javax.inject.Named;
[ERROR]
[ERROR] TransactionServiceExternalImpl.java:5: cannot find symbol
[ERROR] symbol: class Named
[ERROR] @Named(transactionServiceExternal)
[ERROR]
[ERROR] java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl
cannot be cast to com.sun.javadoc.AnnotationTypeDoc{noformat}
The POM is this...
{code:xml}groupIdcom.xxx/groupId
artifactIdts-impl/artifactId
version2.4.0-SNAPSHOT/version
dependencies
dependency
groupIdjavax.inject/groupId
artifactIdjavax.inject/artifactId
version1/version
/dependency
/dependencies{code}
There is only one class...
{code:java}import javax.inject.Named;
@Named(transactionServiceExternal)
public class TransactionServiceExternalImpl
{
}{code}
I get the error with
jdk1.5.0_22
jdk1.6.0_29
jdk1.6.0_43
jdk1.6.0_43_32bit
But NOT with...
jdk1.7.0_05
Anyone have any ideas?
Notes: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
I now know that the reason is that the Maven Javadoc Plugin has changed from
2.9.1 to 2.10. and this is the cause of the problem.
I can see this warning...
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing. [WARNING]
'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-deploy-plugin is missing.
By setting the following in my pom
org.apache.maven.plugins maven-javadoc-plugin 2.9.1 attach-javadocs jar
I can fix the version back to the last release.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-406) Regression: MJAVADOC-398 commit changed wrong line
[
https://jira.codehaus.org/browse/MJAVADOC-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353232#comment-353232
]
Michael Osipov edited comment on MJAVADOC-406 at 9/25/14 2:24 PM:
--
David, I just have deployed a new
[SNAPSHOT|https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/maven/plugins/maven-javadoc-plugin/2.11-SNAPSHOT/maven-javadoc-plugin-2.11-20140925.191134-19.jar]
which restores the previous behavior and really fixed MJAVADOC-398. Please
test and report.
If change is verified, I will push 2.10.1 immediately.
was (Author: michael-o):
David, I just have deployed a new
[SNAPSHOT|https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/maven/plugins/maven-javadoc-plugin/2.11-SNAPSHOT/maven-javadoc-plugin-2.11-20140925.191134-19.jar]
which restores the previous behavior and really fixed MJAVADOC-398. Please
test and report.
Regression: MJAVADOC-398 commit changed wrong line
--
Key: MJAVADOC-406
URL: https://jira.codehaus.org/browse/MJAVADOC-406
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: Martin Skurla
Assignee: Michael Osipov
Priority: Critical
Fix For: 2.10.1
The functionality/change behavior of MJAVADOC-398 should definitely be
configurable.
In our project we have to manually put a lot of dependencies into
{{additionalDependencies}} section to restore the previously working
behaviour which is a huge pain and does not scale (as we will be forced to
update the dependencies every time dependencies are added to projects).
Please provide a javadoc configuration for turning on/off the functionality
added in MJAVADOC-398.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-407) cannot parse annotations : when generating javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353233#comment-353233
]
Michael Osipov commented on MJAVADOC-407:
-
This bug has been caused by an incorrect commit which I have done for
MJAVADOC-398. Whoever is affected, I just have deployed a new
[SNAPSHOT|https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/maven/plugins/maven-javadoc-plugin/2.11-SNAPSHOT/maven-javadoc-plugin-2.11-20140925.191134-19.jar]
which restores the previous behavior and really fixed MJAVADOC-398. Please
test and report.
If change is verified, I will push 2.10.1 immediately.
cannot parse annotations : when generating javadoc
---
Key: MJAVADOC-407
URL: https://jira.codehaus.org/browse/MJAVADOC-407
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux and windows.
Maven 3.0.4 , JDK 1.6.0.43
Reporter: jeff porter
Assignee: Michael Osipov
Fix For: 2.10.1
Attachments: AbstractJavadocMojo.java.patch
See full issue text at :
http://stackoverflow.com/questions/25971832/javadoc-generation-failed-classcastexception-com-sun-tools-javadoc-classdocim
I'm getting the following error when I do
{noformat}mvn clean deploy -DperformRelease=true
[ERROR] Exit code: 1 - .java:3: package javax.inject does not exist
[ERROR] import javax.inject.Named;
[ERROR]
[ERROR] TransactionServiceExternalImpl.java:5: cannot find symbol
[ERROR] symbol: class Named
[ERROR] @Named(transactionServiceExternal)
[ERROR]
[ERROR] java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl
cannot be cast to com.sun.javadoc.AnnotationTypeDoc{noformat}
The POM is this...
{code:xml}groupIdcom.xxx/groupId
artifactIdts-impl/artifactId
version2.4.0-SNAPSHOT/version
dependencies
dependency
groupIdjavax.inject/groupId
artifactIdjavax.inject/artifactId
version1/version
/dependency
/dependencies{code}
There is only one class...
{code:java}import javax.inject.Named;
@Named(transactionServiceExternal)
public class TransactionServiceExternalImpl
{
}{code}
I get the error with
jdk1.5.0_22
jdk1.6.0_29
jdk1.6.0_43
jdk1.6.0_43_32bit
But NOT with...
jdk1.7.0_05
Anyone have any ideas?
Notes: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
I now know that the reason is that the Maven Javadoc Plugin has changed from
2.9.1 to 2.10. and this is the cause of the problem.
I can see this warning...
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing. [WARNING]
'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-deploy-plugin is missing.
By setting the following in my pom
org.apache.maven.plugins maven-javadoc-plugin 2.9.1 attach-javadocs jar
I can fix the version back to the last release.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-749) Parallel methods should run in separate classloaders
[ https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-749. --- Resolution: Won't Fix Assignee: Kristian Rosenvold Parallel methods should run in separate classloaders Key: SUREFIRE-749 URL: https://jira.codehaus.org/browse/SUREFIRE-749 Project: Maven Surefire Issue Type: New Feature Components: Junit 4.7+ (parallel) support Affects Versions: 2.8.1 Reporter: Gili Assignee: Kristian Rosenvold When running in parallel-method or parallel-both mode, each @Test should run in its own ClassLoader. I'm running into a lot of problems involving the use of static variables in 3rd-party libraries. Here are two examples: 1. slf4j: http://bugzilla.slf4j.org/show_bug.cgi?id=176 2. guice: http://code.google.com/p/google-guice/issues/detail?id=635 I believe running in isolated ClassLoaders would fix both problems and it makes a lot of sense from a test isolation point of view so we should do it anyway. I believe Surefire's forkMode is defined in terms of isolated JVMs instead of ClassLoaders. Furthermore, it only seems to support per-Class isolation instead of per-@Test isolation. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1024) verify goal ignores dependenciesToScan parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1024:
-
Fix Version/s: (was: 2.18)
3.0
verify goal ignores dependenciesToScan parameter when checking tests
existence
--
Key: SUREFIRE-1024
URL: https://jira.codehaus.org/browse/SUREFIRE-1024
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 2.16
Reporter: Dmitry Kholodilov
Fix For: 3.0
Attachments:
verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
Consider Maven project with packaging=pom that executes tests from some
external jar:
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
versiontest/version
packagingpom/packaging
dependencies
dependency
groupIdtest/groupId
artifactIdtests-jar/artifactId
version1.0/version
classifiertests/classifier
/dependency
dependency
groupIdorg.testng/groupId
artifactIdtestng/artifactId
version6.8/version
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-failsafe-plugin/artifactId
version2.17-SNAPSHOT/version
configuration
dependenciesToScan
dependencytest:tests-jar/dependency
/dependenciesToScan
/configuration
executions
execution
idintegration-test/id
phaseintegration-test/phase
goals
goalintegration-test/goal
/goals
/execution
execution
idverify/id
phaseverify/phase
goals
goalverify/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
{code}
(real use case is execution of prebuilt end-to-end tests of some system after
its deployment)
When we run `mvn clean verify` on such project, failsafe plugin's verify
goal reports the following:
{noformat}
[INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
[INFO] No tests to run.
{noformat}
Consequently, even if there are test failures, build success is reported.
The reason of such behavior is that VerifyMojo ignores dependenciesToScan
parameter. So, the fix is easy - check its existence along with
testClassesDirectory existence, the same way as implemented in
AbstractSurefireMojo.
The patch in attachment includes integration test that checks for build
failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1034) dependencesToScan versus classifiers: what's the scoop?
[ https://jira.codehaus.org/browse/SUREFIRE-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian updated SUREFIRE-1034: - Fix Version/s: (was: 2.18) 3.0 dependencesToScan versus classifiers: what's the scoop? --- Key: SUREFIRE-1034 URL: https://jira.codehaus.org/browse/SUREFIRE-1034 Project: Maven Surefire Issue Type: Bug Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 3.0 # The doc could really use an example of dependenciesToScan # The doc should tell me the syntax for using classifiers # if classifiers don't work, please make them work. -- 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-tabpanelfocusedCommentId=353234#comment-353234
]
Michael Osipov commented on MCHECKSTYLE-70:
---
[~rfscholte], why did you actually introduce another {{@Parameter}} variable
instead of calling {{project.getCompileSourceRoots()}} as other plugins do?
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] (MNG-5691) Reopen MNG-1388
[ https://jira.codehaus.org/browse/MNG-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5691. --- Resolution: Duplicate Reopen MNG-1388 --- Key: MNG-5691 URL: https://jira.codehaus.org/browse/MNG-5691 Project: Maven Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 3.2.3 Reporter: Gili Please reopen MNG-1388. Plenty of valid reasons for doing so were given after the issue was closed. There is no known workaround and this is a major hurdle for projects that mix Java and native code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[
https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened MNG-1388:
-
Reopening by request. If someone still wan't this as {{Won't Fix}}, please
provide an explanation for.
Transitive Dependencies in a profile are not used
-
Key: MNG-1388
URL: https://jira.codehaus.org/browse/MNG-1388
Project: Maven
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0
Environment: Windows XP using Maven 2.0.
Reporter: Damian Bradicich
I have a jar project file that defines a dependency inside a certain profile.
If I then include that project inside of another war project, the
dependencies defined in the jar project's profile isn't getting transferred
over to the war.
Ie we have this:
A depends on SQL or Oracle depending on profile
B depends on A.
If sql profile is active, I would expect that when I build B, it pulls
the transitive dependancy on sql from A.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-318) WAR overlay does not work when building child modules from the parent
[
https://jira.codehaus.org/browse/MWAR-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353236#comment-353236
]
Karl-Heinz Marbaise commented on MWAR-318:
--
Do you have an example project collected for example on github where you can
give a link on it so we can reproduce the behaviour ?
WAR overlay does not work when building child modules from the parent
-
Key: MWAR-318
URL: https://jira.codehaus.org/browse/MWAR-318
Project: Maven WAR Plugin
Issue Type: Bug
Components: overlay
Affects Versions: 2.4
Reporter: Alan Czajkowski
Fix For: backlog
project layout:
root/pom.xml (parent POM, packaging: pom)
root/war1/pom.xml (packaging: war)
root/war2/pom.xml (packaging: war)
war2 artifact will overlay on top of war1 artifact
war2 plugin definition:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.4/version
configuration
attachClassestrue/attachClasses
dependentWarIncludes**/dependentWarIncludes
overlays
overlay
idwar1/id
groupIdcom.example/groupId
artifactIdwar1/artifactId
typewar/type
/overlay
overlay
!-- empty groupId/artifactId represents the current build --
/overlay
/overlays
/configuration
/plugin
{code}
running: {{mvn clean install}}
when building the entire project from the _*parent*_ (root/pom.xml) the
overlay does not work, when building just from the _*child*_
(root/war2/pom.xml) the overlay does work, see debug output below:
building from the _*parent*_, the packaging of war2 fails, running [mvn clean
install] from root/:
{code}
[DEBUG] OverlayPackagingTask performPackaging overlay.getTargetPath() null
[INFO] Processing overlay [ id war1]
[DEBUG] Expanding:
/Users/bingo/dev/example/root/war1/target/war1-1.0-SNAPSHOT.jar into
/Users/bingo/dev/example/root/war2/target/war/work/com.example/war1
[DEBUG] expand complete
{code}
building from the _*child*_, the packaging of war2 is successful, running
[mvn clean install] from root/war2/:
{code}
[DEBUG] OverlayPackagingTask performPackaging overlay.getTargetPath() null
[INFO] Processing overlay [ id war1]
[DEBUG] Expanding:
/Users/bingo/.m2/repository/com/example/war1/1.0-SNAPSHOT/war1-1.0-SNAPSHOT.war
into /Users/bingo/dev/example/root/war2/target/war/work/com.example/war1
[DEBUG] expand complete
{code}
notice how when you build from the _*parent*_, for some reason it thinks the
overlay is a JAR instead of a WAR:
{code}
[DEBUG] Expanding:
/Users/bingo/dev/example/root/war1/target/war1-1.0-SNAPSHOT.jar into
/Users/bingo/dev/example/root/war2/target/war/work/com.example/war1
{code}
but when you build from the _*child*_ it works properly, same command on both
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCLEAN-58) Maven Clean Plugin ignores followSymLinks parameter on Windows
[ https://jira.codehaus.org/browse/MCLEAN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MCLEAN-58: -- Fix Version/s: more-investigation Maven Clean Plugin ignores followSymLinks parameter on Windows -- Key: MCLEAN-58 URL: https://jira.codehaus.org/browse/MCLEAN-58 Project: Maven Clean Plugin Issue Type: Bug Affects Versions: 2.5 Reporter: Sergei Makarov Fix For: more-investigation Attachments: MavenCleanPluginNoFollowSymlinkBug.zip Most of old java software use getCanonicalFile() to determine symlink. But it is lie for windows. Lets look to org.apache.maven.plugin.clean.Cleaner: 147 File canonical = followSymlinks ? file : file.getCanonicalFile(); 148 if ( followSymlinks || file.equals( canonical ) ) getCanonicalFile() returns same path and folow symlink. In attached MavenCleanPluginNoFollowSymlinkBug.zip you found TestCase.bat that shows bug (just read it to understand than run). Unfortunately I know only one way to fix this - move to NIO that has isSymbolicLink() since java 1.7. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-890) Prompt for usernames and passwords when running interactively
Karl M. Davis created MRELEASE-890:
--
Summary: Prompt for usernames and passwords when running
interactively
Key: MRELEASE-890
URL: https://jira.codehaus.org/browse/MRELEASE-890
Project: Maven Release Plugin
Issue Type: Improvement
Affects Versions: 2.5.1
Reporter: Karl M. Davis
Priority: Critical
I've been using the release plugin for years now, and also supporting a lot of
other folks using it.
It occurred to me today, that one of the most common sources of frustration and
problems with the release plugin has been authentication: either users never
added {{server/}} entries to their {{settings.xml}} or their passwords
expired and they forgot to update it. Looking back... this ha probably been the
cause of around half of all the troubleshooting I've helped folks with.
I think it'd really help the first-run experience for folks if the release
plugin prompted users for their authentication credentials when they're needed:
if they're missing in the {{settings.xml}} and if authentication failures are
encountered. (Only when running interactively, of course.)
I imagine a lot of other folks' experience here might mirror mine, especially
in Windows domain environments with obnoxious password expiration policies.
Even if passwords aren't expiring, though, it seems like I'm setting up a
development environment on a new machine for myself or someone else about once
a month. And the {{settings.xml}} authentication credentials are an
oft-overlooked step.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-890) Prompt for usernames and passwords when running interactively
[
https://jira.codehaus.org/browse/MRELEASE-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl M. Davis updated MRELEASE-890:
---
Description:
I've been using the release plugin for years now, and also supporting a lot of
other folks using it.
It occurred to me today, that one of the most common sources of frustration and
problems with the release plugin has been authentication: either users never
added {{server/}} entries to their {{settings.xml}} or their password expired
and they forgot to update it. Looking back... this has probably been the cause
of around half of all the troubleshooting I've helped folks with.
I think it'd really help the first-run experience for folks if the release
plugin prompted users for their authentication credentials when they're needed:
if they're missing in the {{settings.xml}} and if authentication failures are
encountered. (Only when running interactively, of course.)
I imagine a lot of other folks' experience here might mirror mine, especially
in Windows domain environments with obnoxious password expiration policies.
Even if passwords aren't expiring, though, it seems like I'm setting up a
development environment on a new machine for myself or someone else about once
a month. And the {{settings.xml}} authentication credentials are an
oft-overlooked step.
was:
I've been using the release plugin for years now, and also supporting a lot of
other folks using it.
It occurred to me today, that one of the most common sources of frustration and
problems with the release plugin has been authentication: either users never
added {{server/}} entries to their {{settings.xml}} or their passwords
expired and they forgot to update it. Looking back... this ha probably been the
cause of around half of all the troubleshooting I've helped folks with.
I think it'd really help the first-run experience for folks if the release
plugin prompted users for their authentication credentials when they're needed:
if they're missing in the {{settings.xml}} and if authentication failures are
encountered. (Only when running interactively, of course.)
I imagine a lot of other folks' experience here might mirror mine, especially
in Windows domain environments with obnoxious password expiration policies.
Even if passwords aren't expiring, though, it seems like I'm setting up a
development environment on a new machine for myself or someone else about once
a month. And the {{settings.xml}} authentication credentials are an
oft-overlooked step.
Prompt for usernames and passwords when running interactively
-
Key: MRELEASE-890
URL: https://jira.codehaus.org/browse/MRELEASE-890
Project: Maven Release Plugin
Issue Type: Improvement
Affects Versions: 2.5.1
Reporter: Karl M. Davis
Priority: Critical
I've been using the release plugin for years now, and also supporting a lot
of other folks using it.
It occurred to me today, that one of the most common sources of frustration
and problems with the release plugin has been authentication: either users
never added {{server/}} entries to their {{settings.xml}} or their password
expired and they forgot to update it. Looking back... this has probably been
the cause of around half of all the troubleshooting I've helped folks with.
I think it'd really help the first-run experience for folks if the release
plugin prompted users for their authentication credentials when they're
needed: if they're missing in the {{settings.xml}} and if authentication
failures are encountered. (Only when running interactively, of course.)
I imagine a lot of other folks' experience here might mirror mine, especially
in Windows domain environments with obnoxious password expiration policies.
Even if passwords aren't expiring, though, it seems like I'm setting up a
development environment on a new machine for myself or someone else about
once a month. And the {{settings.xml}} authentication credentials are an
oft-overlooked step.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-749) Parallel methods should run in separate classloaders
[ https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353239#comment-353239 ] Gili commented on SUREFIRE-749: --- @Andreas, You didn't explain how one would implement this across the board for *both* JUnit and TestNG, and how one would subsequently integrate with Surefire. To clarify: I am looking for Surefire to provide a consist isolation interface (using forking if you prefer) on a per-method basis. By your admission Surefire does not yet support this, so why close this as WON'T FIX? Please consider renaming the title to Ability to fork JVM per method and reopening the issue. Parallel methods should run in separate classloaders Key: SUREFIRE-749 URL: https://jira.codehaus.org/browse/SUREFIRE-749 Project: Maven Surefire Issue Type: New Feature Components: Junit 4.7+ (parallel) support Affects Versions: 2.8.1 Reporter: Gili Assignee: Kristian Rosenvold When running in parallel-method or parallel-both mode, each @Test should run in its own ClassLoader. I'm running into a lot of problems involving the use of static variables in 3rd-party libraries. Here are two examples: 1. slf4j: http://bugzilla.slf4j.org/show_bug.cgi?id=176 2. guice: http://code.google.com/p/google-guice/issues/detail?id=635 I believe running in isolated ClassLoaders would fix both problems and it makes a lot of sense from a test isolation point of view so we should do it anyway. I believe Surefire's forkMode is defined in terms of isolated JVMs instead of ClassLoaders. Furthermore, it only seems to support per-Class isolation instead of per-@Test isolation. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-411) Package does not exist warnings
[
https://jira.codehaus.org/browse/MJAVADOC-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353240#comment-353240
]
Anthony Whitford commented on MJAVADOC-411:
---
I suspect that MJAVADOC-406 (which is essentially applying the proper fix to
MJAVADOC-398) will solve the issue.
Package does not exist warnings
---
Key: MJAVADOC-411
URL: https://jira.codehaus.org/browse/MJAVADOC-411
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Mac OSX, Java 8 Update 20, Maven 3.2.3
Reporter: Anthony Whitford
Since version 2.10, it appears that Javadoc is warning about missing packages
when generating javadoc.
* For the {{javadoc}} goal, the {{compile}} scope classes should be in scope
* For the {{test-javadoc}} goal, the {{test}} scope classes should be in scope
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
