[jira] [Commented] (MCOMPILER-397) Use relative paths in jpms.args to make the builds reproducible
[
https://issues.apache.org/jira/browse/MCOMPILER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733760#comment-17733760
]
Emmanuel Bourg commented on MCOMPILER-397:
--
I've opened a PR with the patch currently applied to maven-compiler-plugin in
Debian.
> Use relative paths in jpms.args to make the builds reproducible
> ---
>
> Key: MCOMPILER-397
> URL: https://issues.apache.org/jira/browse/MCOMPILER-397
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Emmanuel Bourg
>Priority: Major
> Labels: reproducibility
>
> The {{jpms.args}} file generated since the version 3.7 contains absolute
> paths, for example here is the file generated for jaxb-core:
> {code}
> --add-modules
> java.xml.bind
> --upgrade-module-path
> /home/ebourg/jaxb/jaxb-ri/core/target/endorsed
> {code}
> The absolute path affects the reproducibility of the builds. Someone else
> rebuilding the project is unlikely to have the same base path and will not
> get a byte identical artifact. I suggest using a relative path instead
> (starting at the root of the project or at the root of the module) and
> normalizing the path separators (such that builds on Windows and Unix
> generate the same file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-397) Use relative paths in jpms.args to make the builds reproducible
[
https://issues.apache.org/jira/browse/MCOMPILER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733758#comment-17733758
]
Emmanuel Bourg commented on MCOMPILER-397:
--
> I understand the request, but if we change it, then the solution should be
> usable at runtime as well
I'm not sure to understand, how an absolute path from the developer computer
building the artifact could have any impact at runtime on someone else system?
> Use relative paths in jpms.args to make the builds reproducible
> ---
>
> Key: MCOMPILER-397
> URL: https://issues.apache.org/jira/browse/MCOMPILER-397
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Emmanuel Bourg
>Priority: Major
> Labels: reproducibility
>
> The {{jpms.args}} file generated since the version 3.7 contains absolute
> paths, for example here is the file generated for jaxb-core:
> {code}
> --add-modules
> java.xml.bind
> --upgrade-module-path
> /home/ebourg/jaxb/jaxb-ri/core/target/endorsed
> {code}
> The absolute path affects the reproducibility of the builds. Someone else
> rebuilding the project is unlikely to have the same base path and will not
> get a byte identical artifact. I suggest using a relative path instead
> (starting at the root of the project or at the root of the module) and
> normalizing the path separators (such that builds on Windows and Unix
> generate the same file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-5146) parent.relativePath Warning is very misleading
[ https://issues.apache.org/jira/browse/MNG-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692046#comment-17692046 ] Emmanuel Bourg commented on MNG-5146: - This issue is worth reopening, for some reason this prevents IntelliJ from synchronizing the project. The message is misleading and it took me quite some time to troubleshoot this issue. A better warning message would have help a lot. > parent.relativePath Warning is very misleading > -- > > Key: MNG-5146 > URL: https://issues.apache.org/jira/browse/MNG-5146 > Project: Maven > Issue Type: Bug > Components: Errors > Environment: Maven 3.0.3 >Reporter: Scott MacDonald >Priority: Minor > > When a parent pom.xml is located in a sibling directory as the children, and > is not set in the element of the children, maven > spits out a completely bogus, very misleading, warning message. > For example, suppose com.fubar and com.parent are in sibling directories > (along with a bunch of other modules), and com.fubar specifies com.parent as > its parent, but does snot specify a parent.relativePath in it parent element. > When you run a build, you get the following... > [INFO] Scanning for projects... > [WARNING] > [WARNING] Some problems were encountered while building the effective model > for com.fubar:jar:1234.5 > [WARNING] 'parent.relativePath' points at com.someRandomModule instead of > com.parent, please verify your project structure @ line > 10, column 11 > [WARNING] > [WARNING] It is highly recommended to fix these problems because they > threaten the stability of your build. > [WARNING] > [WARNING] For this reason, future Maven versions might no longer support > building such malformed projects. > [WARNING] > The warning incorrectly states that the child pom has specified > com.someRandomModule (a completely unrelated module) as its parent when that > is completely not the case. The unlreated module, in this case, happens to be > an existing module in a differrnt sibling directory, but otherwise has no > relation whatsoever to the parent or child. > It would be much better to warn about the actual problem > The actual problem is that maven first tries to resolve parent poms locally > based on the value of relativePath in the parent element of the child. IF it > does not find it there, it will then resolve the parent from the repos. The > current default value of relativepath is ../pom.xml (which in my case > doesn;t work because my parent is in a sibling directory) > The warning should be changed to something useful, such as > [WARNING] Could not resolve parent pom locally using parent.relativePath > value of ../pom.xml. Parent pom will be resolved from local or remote > repository. To disable local parent pom resolution, specify > in you element. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649042#comment-17649042
]
Emmanuel Bourg commented on MRESOURCES-237:
---
This issue is marked as fixed in the version 3.3.0, but there is no mention of
MRESOURCES-237 in the commit history. Is the resolution actually Won't Fix ?
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-619) Maven Javadoc bottom claims copyright for future years
[
https://issues.apache.org/jira/browse/MJAVADOC-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353008#comment-17353008
]
Emmanuel Bourg commented on MJAVADOC-619:
-
I think you should also enforce a specific timezone (UTC for example) when
building the Calendar, otherwise the year will be non reproducible.
There are two unused java.time imports in JavadocUtilTest.java.
Also, it's a bit odd to mix the old java.util.Calendar with the new java.time
API.
> Maven Javadoc bottom claims copyright for future years
> --
>
> Key: MJAVADOC-619
> URL: https://issues.apache.org/jira/browse/MJAVADOC-619
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Bernhard M. Wiedemann
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.3.0
>
>
> Originally filed at https://issues.apache.org/jira/browse/MCOMPILER-380
> [https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#bottom]
> includes {{{currentYear}}}
> [https://github.com/bmwiedemann/theunreproduciblepackage/tree/master/timestamp/copyright]
> explains why this is bad (not only for reproducible builds)
>
> Debian worked already around this with
> [https://sources.debian.org/src/maven-javadoc-plugin/2.10.4-1/debian/patches/reproducible-footer.patch/]
> but I think, this warrants a more general patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MCOMPILER-397) Use relative paths in jpms.args to make the builds reproducible
Emmanuel Bourg created MCOMPILER-397:
Summary: Use relative paths in jpms.args to make the builds
reproducible
Key: MCOMPILER-397
URL: https://issues.apache.org/jira/browse/MCOMPILER-397
Project: Maven Compiler Plugin
Issue Type: Improvement
Affects Versions: 3.8.1
Reporter: Emmanuel Bourg
The {{jpms.args}} file generated since the version 3.7 contains absolute paths,
for example here is the file generated for jaxb-core:
{code}
--add-modules
java.xml.bind
--upgrade-module-path
/home/ebourg/jaxb/jaxb-ri/core/target/endorsed
{code}
The absolute path affects the reproducibility of the builds. Someone else
rebuilding the project is unlikely to have the same base path and will not get
a byte identical artifact. I suggest using a relative path instead (starting at
the root of the project or at the root of the module) and normalizing the path
separators (such that builds on Windows and Unix generate the same file).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MJAVADOC-619) Maven Javadoc bottom claims copyright for future years
[
https://issues.apache.org/jira/browse/MJAVADOC-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900409#comment-16900409
]
Emmanuel Bourg commented on MJAVADOC-619:
-
The patch I implemented in Debian is about supporting [SOURCE_DATE_EPOCH
|https://reproducible-builds.org/docs/source-date-epoch/] in the Javadoc
plugin. The adoption of SOURCE_DATE_EPOCH is slowly growing across a wide
variety of tools, but as I understand there is still some resistance to support
it in the Maven ecosystem (mostly because the environment variable approach
looks a bit hackish, but that's really the lowest and only common denominator
of very different tool ecosystems).
Maybe a less controversial change would be to use the build date in the javadoc
plugin (from {{MavenSession.getStartTime()}}) instead of the current date. So
if at some point there is an agreed upon mechanism to override the build date
centrally (either by supporting SOURCE_DATE_EPOCH, using the date of pom.xml,
or a mix of both) then the javadoc plugin will benefit from it. And this would
allow Debian to drop its patch since the build date is already
[overridden|https://salsa.debian.org/java-team/maven/blob/master/debian/patches/reproducible-build-timestamp.patch].
There would be just one issue left to override the timezone to property format
the date.
> Maven Javadoc bottom claims copyright for future years
> --
>
> Key: MJAVADOC-619
> URL: https://issues.apache.org/jira/browse/MJAVADOC-619
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Bernhard M. Wiedemann
>Priority: Major
>
> Originally filed at https://issues.apache.org/jira/browse/MCOMPILER-380
> [https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#bottom]
> includes {{{currentYear}}}
> [https://github.com/bmwiedemann/theunreproduciblepackage/tree/master/timestamp/copyright]
> explains why this is bad (not only for reproducible builds)
>
> Debian worked already around this with
> [https://sources.debian.org/src/maven-javadoc-plugin/2.10.4-1/debian/patches/reproducible-footer.patch/]
> but I think, this warrants a more general patch.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSHARED-661) Make "Built-By", "Built-Jdk" and "Created-By" Manifest entries optional for reproducible builds
[ https://issues.apache.org/jira/browse/MSHARED-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572884#comment-16572884 ] Emmanuel Bourg commented on MSHARED-661: Capturing information about the tools used to build the artifacts is important, because for achieving reproducibility one is supposed to reuse the same tools and dependencies that were originally used. However this information probably doesn't belong to the jar manifest. For example in Debian the build environment of a package is captured in a [.buildinfo file|https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles] deployed along the package. This file is then used to recreate an identical build environment. In the Maven world this could translate into an additional artifact detailing the relevant info about the build environment and deployed along the pom, or extra information added inside the pom at build time. I think it's fine to keep the Created-By and Built-Jdk attributes for now until another way of capturing the build environment is agreed upon. The Built-By attribute on the other hand should be removed right off, the identity of the person creating the artifact is already known with the GPG signature anyway. > Make "Built-By", "Built-Jdk" and "Created-By" Manifest entries optional for > reproducible builds > --- > > Key: MSHARED-661 > URL: https://issues.apache.org/jira/browse/MSHARED-661 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-archiver >Reporter: Zlika >Priority: Minor > > Maven-archiver automatically creates "Built-By", "Build-Jdk" and "Created-By" > Manifest entries. In the frame of a reproducible build (cf. MNG-6276) these > entries make the build not reproducible. > Maven-archiver should propose an option to disable the creation of these > non-reproducible manifest entries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPLUGIN-339) maven-plugin-tools-javadoc broken by com.sun.tools.doclets removal in Java 10
[ https://issues.apache.org/jira/browse/MPLUGIN-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482440#comment-16482440 ] Emmanuel Bourg commented on MPLUGIN-339: What about packaging the com.sun.tools.doclets API as a separate artifact uploaded to Maven Central? > maven-plugin-tools-javadoc broken by com.sun.tools.doclets removal in Java 10 > - > > Key: MPLUGIN-339 > URL: https://issues.apache.org/jira/browse/MPLUGIN-339 > Project: Maven Plugin Tools > Issue Type: Bug > Components: maven-plugin-tools-javadoc >Affects Versions: 3.5.1 >Reporter: Emmanuel Bourg >Priority: Major > Fix For: 3.6 > > > The com.sun.tools.doclets API is no longer available in Java 10, this breaks > the maven-plugin-tools-javadoc module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MPLUGIN-339) maven-plugin-tools-javadoc broken by com.sun.tools.doclets removal in Java 10
Emmanuel Bourg created MPLUGIN-339: -- Summary: maven-plugin-tools-javadoc broken by com.sun.tools.doclets removal in Java 10 Key: MPLUGIN-339 URL: https://issues.apache.org/jira/browse/MPLUGIN-339 Project: Maven Plugin Tools Issue Type: Bug Components: maven-plugin-tools-javadoc Affects Versions: 3.5.1 Reporter: Emmanuel Bourg The com.sun.tools.doclets API is no longer available in Java 10, this breaks the maven-plugin-tools-javadoc module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-504) NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
[
https://issues.apache.org/jira/browse/MJAVADOC-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16313347#comment-16313347
]
Emmanuel Bourg commented on MJAVADOC-504:
-
It looks good, byte-buddy and xbean build fine now. Thank you for the fix!
> NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
> --
>
> Key: MJAVADOC-504
> URL: https://issues.apache.org/jira/browse/MJAVADOC-504
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Debian, OpenJDK 8
>Reporter: Emmanuel Bourg
>
> Hi,
> After upgrading to maven-javadoc-plugin I noticed a NullPointerException in
> {{JavadocUtil.getJavaHome()}} when the JAVA_HOME environment variable isn't
> set:
> {noformat}
> java.lang.NullPointerException
> at java.io.File. (File.java:277)
> at org.apache.maven.plugins.javadoc.JavadocUtil.getJavaHome
> (JavadocUtil.java:1302)
> at org.apache.maven.plugins.javadoc.JavadocUtil.invokeMaven
> (JavadocUtil.java:941)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getModulesLinks
> (AbstractJavadocMojo.java:5640)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addLinkofflineArguments
> (AbstractJavadocMojo.java:4046)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addStandardDocletOptions
> (AbstractJavadocMojo.java:4936)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2074)
> at org.apache.maven.plugins.javadoc.JavadocReport.generate
> (JavadocReport.java:134)
> at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
> (JavadocReport.java:329)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:1909)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:191)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:180)
> {noformat}
> This error doesn't occur with the version 3.0.0-M1 or when JAVA_HOME is set.
> It can be reproduced on the byte-buddy project:
> {code}
> git clone https://github.com/raphw/byte-buddy
> cd byte-buddy
> git checkout byte-buddy-1.7.9
> mvn org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:javadoc
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-504) NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
[
https://issues.apache.org/jira/browse/MJAVADOC-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16308853#comment-16308853
]
Emmanuel Bourg commented on MJAVADOC-504:
-
I tried with the fix in commit 7505bb5 but it still triggers the same
NullPointerException (javaHomeValue is null at line 1308). Maybe because the
value of java.home is read from the environment variables instead of the system
properties of the JVM?
> NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
> --
>
> Key: MJAVADOC-504
> URL: https://issues.apache.org/jira/browse/MJAVADOC-504
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Debian, OpenJDK 8
>Reporter: Emmanuel Bourg
>
> Hi,
> After upgrading to maven-javadoc-plugin I noticed a NullPointerException in
> {{JavadocUtil.getJavaHome()}} when the JAVA_HOME environment variable isn't
> set:
> {noformat}
> java.lang.NullPointerException
> at java.io.File. (File.java:277)
> at org.apache.maven.plugins.javadoc.JavadocUtil.getJavaHome
> (JavadocUtil.java:1302)
> at org.apache.maven.plugins.javadoc.JavadocUtil.invokeMaven
> (JavadocUtil.java:941)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getModulesLinks
> (AbstractJavadocMojo.java:5640)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addLinkofflineArguments
> (AbstractJavadocMojo.java:4046)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addStandardDocletOptions
> (AbstractJavadocMojo.java:4936)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2074)
> at org.apache.maven.plugins.javadoc.JavadocReport.generate
> (JavadocReport.java:134)
> at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
> (JavadocReport.java:329)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:1909)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:191)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:180)
> {noformat}
> This error doesn't occur with the version 3.0.0-M1 or when JAVA_HOME is set.
> It can be reproduced on the byte-buddy project:
> {code}
> git clone https://github.com/raphw/byte-buddy
> cd byte-buddy
> git checkout byte-buddy-1.7.9
> mvn org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:javadoc
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-504) NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
[
https://issues.apache.org/jira/browse/MJAVADOC-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16308350#comment-16308350
]
Emmanuel Bourg commented on MJAVADOC-504:
-
Geronimo XBean is also affected by this issue. Curiously not all modules in the
reactor are affected, the javadoc does build for the first modules but fails on
the xbean-reflect module.
> NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
> --
>
> Key: MJAVADOC-504
> URL: https://issues.apache.org/jira/browse/MJAVADOC-504
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Debian, OpenJDK 8
>Reporter: Emmanuel Bourg
>
> Hi,
> After upgrading to maven-javadoc-plugin I noticed a NullPointerException in
> {{JavadocUtil.getJavaHome()}} when the JAVA_HOME environment variable isn't
> set:
> {noformat}
> java.lang.NullPointerException
> at java.io.File. (File.java:277)
> at org.apache.maven.plugins.javadoc.JavadocUtil.getJavaHome
> (JavadocUtil.java:1302)
> at org.apache.maven.plugins.javadoc.JavadocUtil.invokeMaven
> (JavadocUtil.java:941)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getModulesLinks
> (AbstractJavadocMojo.java:5640)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addLinkofflineArguments
> (AbstractJavadocMojo.java:4046)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addStandardDocletOptions
> (AbstractJavadocMojo.java:4936)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2074)
> at org.apache.maven.plugins.javadoc.JavadocReport.generate
> (JavadocReport.java:134)
> at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
> (JavadocReport.java:329)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:1909)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:191)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:180)
> {noformat}
> This error doesn't occur with the version 3.0.0-M1 or when JAVA_HOME is set.
> It can be reproduced on the byte-buddy project:
> {code}
> git clone https://github.com/raphw/byte-buddy
> cd byte-buddy
> git checkout byte-buddy-1.7.9
> mvn org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:javadoc
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-504) NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
[
https://issues.apache.org/jira/browse/MJAVADOC-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16304543#comment-16304543
]
Emmanuel Bourg commented on MJAVADOC-504:
-
A BuildException wouldn't really help, that would still be a regression
compared to the previous versions.
> NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
> --
>
> Key: MJAVADOC-504
> URL: https://issues.apache.org/jira/browse/MJAVADOC-504
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Debian, OpenJDK 8
>Reporter: Emmanuel Bourg
>
> Hi,
> After upgrading to maven-javadoc-plugin I noticed a NullPointerException in
> {{JavadocUtil.getJavaHome()}} when the JAVA_HOME environment variable isn't
> set:
> {noformat}
> java.lang.NullPointerException
> at java.io.File. (File.java:277)
> at org.apache.maven.plugins.javadoc.JavadocUtil.getJavaHome
> (JavadocUtil.java:1302)
> at org.apache.maven.plugins.javadoc.JavadocUtil.invokeMaven
> (JavadocUtil.java:941)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getModulesLinks
> (AbstractJavadocMojo.java:5640)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addLinkofflineArguments
> (AbstractJavadocMojo.java:4046)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addStandardDocletOptions
> (AbstractJavadocMojo.java:4936)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2074)
> at org.apache.maven.plugins.javadoc.JavadocReport.generate
> (JavadocReport.java:134)
> at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
> (JavadocReport.java:329)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:1909)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:191)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:180)
> {noformat}
> This error doesn't occur with the version 3.0.0-M1 or when JAVA_HOME is set.
> It can be reproduced on the byte-buddy project:
> {code}
> git clone https://github.com/raphw/byte-buddy
> cd byte-buddy
> git checkout byte-buddy-1.7.9
> mvn org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:javadoc
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-504) NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
[
https://issues.apache.org/jira/browse/MJAVADOC-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16293934#comment-16293934
]
Emmanuel Bourg commented on MJAVADOC-504:
-
Maven can run without {{JAVA_HOME}} using {{which java}} to locate the JRE:
https://github.com/apache/maven/blob/maven-3.5.2/apache-maven/src/bin/mvn#L92
> NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
> --
>
> Key: MJAVADOC-504
> URL: https://issues.apache.org/jira/browse/MJAVADOC-504
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Debian, OpenJDK 8
>Reporter: Emmanuel Bourg
>
> Hi,
> After upgrading to maven-javadoc-plugin I noticed a NullPointerException in
> {{JavadocUtil.getJavaHome()}} when the JAVA_HOME environment variable isn't
> set:
> {noformat}
> java.lang.NullPointerException
> at java.io.File. (File.java:277)
> at org.apache.maven.plugins.javadoc.JavadocUtil.getJavaHome
> (JavadocUtil.java:1302)
> at org.apache.maven.plugins.javadoc.JavadocUtil.invokeMaven
> (JavadocUtil.java:941)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getModulesLinks
> (AbstractJavadocMojo.java:5640)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addLinkofflineArguments
> (AbstractJavadocMojo.java:4046)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addStandardDocletOptions
> (AbstractJavadocMojo.java:4936)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2074)
> at org.apache.maven.plugins.javadoc.JavadocReport.generate
> (JavadocReport.java:134)
> at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
> (JavadocReport.java:329)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:1909)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:191)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:180)
> {noformat}
> This error doesn't occur with the version 3.0.0-M1 or when JAVA_HOME is set.
> It can be reproduced on the byte-buddy project:
> {code}
> git clone https://github.com/raphw/byte-buddy
> cd byte-buddy
> git checkout byte-buddy-1.7.9
> mvn org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:javadoc
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MJAVADOC-504) NullPointerException in JavadocUtil.getJavaHome() when JAVA_HOME isn't set
Emmanuel Bourg created MJAVADOC-504:
---
Summary: NullPointerException in JavadocUtil.getJavaHome() when
JAVA_HOME isn't set
Key: MJAVADOC-504
URL: https://issues.apache.org/jira/browse/MJAVADOC-504
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 3.0.0
Environment: Debian, OpenJDK 8
Reporter: Emmanuel Bourg
Hi,
After upgrading to maven-javadoc-plugin I noticed a NullPointerException in
{{JavadocUtil.getJavaHome()}} when the JAVA_HOME environment variable isn't set:
{noformat}
java.lang.NullPointerException
at java.io.File. (File.java:277)
at org.apache.maven.plugins.javadoc.JavadocUtil.getJavaHome
(JavadocUtil.java:1302)
at org.apache.maven.plugins.javadoc.JavadocUtil.invokeMaven
(JavadocUtil.java:941)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getModulesLinks
(AbstractJavadocMojo.java:5640)
at
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addLinkofflineArguments
(AbstractJavadocMojo.java:4046)
at
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addStandardDocletOptions
(AbstractJavadocMojo.java:4936)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
(AbstractJavadocMojo.java:2074)
at org.apache.maven.plugins.javadoc.JavadocReport.generate
(JavadocReport.java:134)
at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
(JavadocReport.java:329)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
(AbstractJavadocMojo.java:1909)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:191)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:180)
{noformat}
This error doesn't occur with the version 3.0.0-M1 or when JAVA_HOME is set. It
can be reproduced on the byte-buddy project:
{code}
git clone https://github.com/raphw/byte-buddy
cd byte-buddy
git checkout byte-buddy-1.7.9
mvn org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:javadoc
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available
[
https://issues.apache.org/jira/browse/SUREFIRE-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189019#comment-16189019
]
Emmanuel Bourg commented on SUREFIRE-1422:
--
Thank you Tibor, I haven't tried yet but the commit looks good.
> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
> Fix For: 2.21.0.Jigsaw
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at
> least check its existence and display an explicit message stating that it
> must be installed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available
[
https://issues.apache.org/jira/browse/SUREFIRE-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185465#comment-16185465
]
Emmanuel Bourg commented on SUREFIRE-1422:
--
[~tibor17] Sorry I won't have the time to provide a properly tested patch. I
already spent half a day debugging this and figuring out the cause.
> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
> Fix For: 2.21.0.Jigsaw
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at
> least check its existence and display an explicit message stating that it
> must be installed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available
[
https://issues.apache.org/jira/browse/SUREFIRE-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177812#comment-16177812
]
Emmanuel Bourg commented on SUREFIRE-1422:
--
This issue can be reproduced by removing the procps package on Debian/Ubuntu.
> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at
> least check its existence and display an explicit message stating that it
> must be installed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available
Emmanuel Bourg created SUREFIRE-1422:
Summary: Forking fails on Linux if /bin/ps isn't available
Key: SUREFIRE-1422
URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.20.1
Environment: Linux (Debian 9 with OpenJDK 8)
Reporter: Emmanuel Bourg
Hi,
With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure on
Linux when the fork mode is enabled:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on
project foo: There are test failures.
[ERROR]
[ERROR] Please refer to /foo/target/surefire-reports for the individual test
results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
{code}
I traced the issue back to the PpidChecker class, the code assumes that
{{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on
trimmed down containers commonly used for continuous integration).
It would be nice to have a fallback mechanism when ps isn't available, or at
least check its existence and display an explicit message stating that it must
be installed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DOXIA-409) Upgrade to Apache FOP 1.0
[ https://issues.apache.org/jira/browse/DOXIA-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104702#comment-16104702 ] Emmanuel Bourg commented on DOXIA-409: -- Fedora has a patch to use FOP 2.0: http://pkgs.fedoraproject.org/cgit/rpms/maven-doxia.git/tree/0004-Port-to-fop-2.0.patch > Upgrade to Apache FOP 1.0 > - > > Key: DOXIA-409 > URL: https://issues.apache.org/jira/browse/DOXIA-409 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - FO >Affects Versions: 1.1 >Reporter: Lukas Theussl > > Unfortunately this leads to a test failure in the pdf plugin because of a > regression in FOP: https://issues.apache.org/bugzilla/show_bug.cgi?id=49837 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1394) Missing final tag for Surefire 2.20
[ https://issues.apache.org/jira/browse/SUREFIRE-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16098120#comment-16098120 ] Emmanuel Bourg commented on SUREFIRE-1394: -- Thank you! > Missing final tag for Surefire 2.20 > --- > > Key: SUREFIRE-1394 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1394 > Project: Maven Surefire > Issue Type: Task > Components: documentation >Affects Versions: 2.20 >Reporter: Emmanuel Bourg >Assignee: Tibor Digana >Priority: Trivial > Fix For: Backlog > > > Hi, > The Git repository is missing the final tag for the release 2.20, there are > only the 3 vote tags. Could you add it please? > Thank you -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SUREFIRE-1394) Missing final tag for Surefire 2.20
Emmanuel Bourg created SUREFIRE-1394: Summary: Missing final tag for Surefire 2.20 Key: SUREFIRE-1394 URL: https://issues.apache.org/jira/browse/SUREFIRE-1394 Project: Maven Surefire Issue Type: Task Components: documentation Affects Versions: 2.20 Reporter: Emmanuel Bourg Priority: Trivial Hi, The Git repository is missing the final tag for the release 2.20, there are only the 3 vote tags. Could you add it please? Thank you -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] (WAGON-400) Wagon 1.0 Fail to build from source with Java7
[ https://jira.codehaus.org/browse/WAGON-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=329795#comment-329795 ] Emmanuel Bourg commented on WAGON-400: -- This is probably a duplicate of WAGON-335. Not sure it makes sense to backport the fix to wagon 1.x though. > Wagon 1.0 Fail to build from source with Java7 > -- > > Key: WAGON-400 > URL: https://jira.codehaus.org/browse/WAGON-400 > Project: Maven Wagon > Issue Type: Bug >Affects Versions: 1.0 > Environment: debian 7.0 >Reporter: Shuxiong Ye > Attachments: wagon-openjdk-7-log > > > I am build debian package of wagon 1.0, using Java7, but fail, for it can not > pass some tests. > Build log: > --- > T E S T S > --- > Running org.apache.maven.wagon.providers.http.HttpWagonTest > Tests run: 42, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.926 sec > Running org.apache.maven.wagon.providers.http.HttpsWagonTest > Tests run: 42, Failures: 0, Errors: 19, Skipped: 0, Time elapsed: 4.984 sec > <<< FAILURE! > Running org.apache.maven.wagon.providers.http.HttpWagonTimeoutTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.867 sec > Results : > Tests in error: > testStreamingWagon(org.apache.maven.wagon.providers.http.HttpsWagonTest): > > testWagonGetIfNewerToStreamIsNewer(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonGetIfNewerToStreamIsOlder(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonGetIfNewerToStreamIsSame(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testFailedGetIfNewerToStream(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testFailedGetToStream(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > testWagon(org.apache.maven.wagon.providers.http.HttpsWagonTest): Address > already in use > > testWagonGetIfNewerIsNewer(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonGetIfNewerIsOlder(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonGetIfNewerIsSame(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonPutDirectory(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonPutDirectoryDeepDestination(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonPutDirectoryWhenDirectoryAlreadyExists(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonPutDirectoryForDot(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > testFailedGet(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > testFailedGetIfNewer(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonGetFileListWhenDirectoryDoesNotExist(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonResourceExists(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > > testWagonResourceNotExists(org.apache.maven.wagon.providers.http.HttpsWagonTest): > Address already in use > Tests run: 88, Failures: 0, Errors: 19, Skipped: 0 > Full version of build log is in the attachment. > More information is here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717280 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANTTASKS-241) Source compatibility with Ant 1.9
Emmanuel Bourg created MANTTASKS-241:
Summary: Source compatibility with Ant 1.9
Key: MANTTASKS-241
URL: https://jira.codehaus.org/browse/MANTTASKS-241
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Affects Versions: 2.1.3
Reporter: Emmanuel Bourg
Priority: Minor
Attachments: ant-1.9-compatibility.patch
Maven Ant Tasks 2.1.3 fails to compile against Ant 1.9.x. This is a caused by
generics added to {{org.apache.tools.ant.Project}} in the new version.
Here is a patch fixing this issue while preserving the compatibility with the
previous versions of Ant.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANTTASKS-220) SFTP support
[
https://jira.codehaus.org/browse/MANTTASKS-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg closed MANTTASKS-220.
Resolution: Not A Bug
Just figured the install-provider task was meant for that :)
> SFTP support
>
>
> Key: MANTTASKS-220
> URL: https://jira.codehaus.org/browse/MANTTASKS-220
> Project: Maven 2.x Ant Tasks
> Issue Type: Improvement
> Components: dependencies task
>Affects Versions: 2.1.3
>Reporter: Emmanuel Bourg
>
> Repositories using sftp as the transport protocol cannot be accessed by the
> Maven Ant Tasks. That would be nice to consider its inclusion in a future
> release.
> {code}
> [artifact:dependencies] [INFO] snapshot foo:bar:1.0-SNAPSHOT: checking for
> updates from myrepo
> [artifact:dependencies] [WARNING] repository metadata for: 'snapshot
> foo:bar:1.0-SNAPSHOT' could not be retrieved from repository: myrepo due to
> an error: Unsupported Protocol: 'sftp': Cannot find wagon which supports the
> requested protocol: sftp
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTTASKS-220) SFTP support
SFTP support
Key: MANTTASKS-220
URL: https://jira.codehaus.org/browse/MANTTASKS-220
Project: Maven 2.x Ant Tasks
Issue Type: Improvement
Components: dependencies task
Affects Versions: 2.1.3
Reporter: Emmanuel Bourg
Repositories using sftp as the transport protocol cannot be accessed by the
Maven Ant Tasks. That would be nice to consider its inclusion in a future
release.
{code}
[artifact:dependencies] [INFO] snapshot foo:bar:1.0-SNAPSHOT: checking for
updates from myrepo
[artifact:dependencies] [WARNING] repository metadata for: 'snapshot
foo:bar:1.0-SNAPSHOT' could not be retrieved from repository: myrepo due to an
error: Unsupported Protocol: 'sftp': Cannot find wagon which supports the
requested protocol: sftp
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-237) keyboard-interactive method is used even when password is supplied
[ http://jira.codehaus.org/browse/WAGON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226225#action_226225 ] Emmanuel Bourg commented on WAGON-237: -- I'm under the impression this issue still exists. I'm trying to mvn deploy to people.apache.org with the username and password specified in settings.xml. I'm still getting the "Keyboard interactive required, supplied password is ignored" prompt. I tested with wagon-ssh 1.0-beta-5 and 1.0-beta-6. > keyboard-interactive method is used even when password is supplied > -- > > Key: WAGON-237 > URL: http://jira.codehaus.org/browse/WAGON-237 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 1.0-beta-4 > Environment: Maven version: 2.0.10-RC8 > Java version: 1.5.0_13 > Default locale: en_US, platform encoding: ISO8859-1 > OS name: "sunos" version: "5.10" arch: "sparc" family: "unix" >Reporter: David J. M. Karlsen >Assignee: Brett Porter > Fix For: 1.0-beta-5 > > > Starting from 2.0.10-RC8 deploy (with ssh and password) started to fail - I'm > getting: > [DEBUG] Connecting to repository: 'repo.sandsli.dnb.no' with url: > 'scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage'. > Keyboard interactive required, supplied password is ignored > event though the pw is in settings.xml: > With help from Brett this was added: > > > > org.apache.maven.wagon > wagon-ssh > 1.0-beta-2 > > > which resolved the case. > Fragment from settings.xml: > > > MyUser > MySecret > 777 > 777 > repo.sandsli.dnb.no > > Fragment from pom.xml: > > > repo.sandsli.dnb.no > DnBNOR Felles Repository > scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse/storage > > > repo.sandsli.dnb.no > DnBNOR Felles Snapshot Repository > > scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage > > > repo.sandsli.dnb.no > > scp://repo.sandsli.dnb.no/dnb/prosess/prosjektdok/no.dnbnor.websphere-1.3-SNAPSHOT/websphere-testenvironment > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-518) Do not generate empty ouput files when redirectTestOutputToFile is enabled
[ http://jira.codehaus.org/browse/SUREFIRE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197171#action_197171 ] Emmanuel Bourg commented on SUREFIRE-518: - I don't remember exactly why I suggested this, I think that was due to a different behavior from the tests run with Ant. I may have no output because only one test case is outputting information for debugging purpose and not the others. Currently it's difficult to pick quickly the file in the directory containing the relevant information since it's surrounded by empty files. Today I would probably work around this issue by running one test at a time. > Do not generate empty ouput files when redirectTestOutputToFile is enabled > -- > > Key: SUREFIRE-518 > URL: http://jira.codehaus.org/browse/SUREFIRE-518 > Project: Maven Surefire > Issue Type: Improvement > Components: process forking >Affects Versions: 2.4.3 >Reporter: Emmanuel Bourg > > The redirectTestOutputToFile option could be improved by removing, or not > generating, the empty output files. Either by default, or with an additional > option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANT-46) mvn ant:ant throws a StringIndexOutOfBoundsException
[
http://jira.codehaus.org/browse/MANT-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143478#action_143478
]
Emmanuel Bourg commented on MANT-46:
It worked, thank you.
I had some troubles getting the jar from the snapshot repository though, the
pom has been downloaded correctly, but not the jar. I copied it manually to my
local repository.
> mvn ant:ant throws a StringIndexOutOfBoundsException
>
>
> Key: MANT-46
> URL: http://jira.codehaus.org/browse/MANT-46
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Emmanuel Bourg
>Assignee: Benjamin Bentmann
> Fix For: 2.1.1
>
>
> I'm trying to generate a Ant build from the Maven 2 POM of Commons CLI but I
> get a StringIndexOutOfBoundsException. I don't know what this is supposed to
> mean.
> Here is the trace:
> {noformat}
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-ant-plugin:2.1:ant'
> -->
> [DEBUG] (f) localRepository = [local] -> file://C:\Documents and
> Settings\Smanux\.m2\repository
> [DEBUG] (f) overwrite = true
> [DEBUG] (f) project = MavenProject: commons-cli:commons-cli:1.2-SNAPSHOT @
> C:\dev\jakarta\cli\pom.xml
> [DEBUG] (f) remoteRepositories = [[apache.snapshots] ->
> http://people.apache.org/repo/m2-snapshot-repository, [central] ->
> http://repo1.maven.org/maven2]
> [DEBUG] (f) settings = [EMAIL PROTECTED]
> [DEBUG] -- end configuration --
> [INFO] [ant:ant]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] String index out of range: -1
> [INFO]
>
> [DEBUG] Trace
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1768)
> at java.lang.String.substring(String.java:1735)
> at org.apache.maven.wagon.PathUtils.toRelative(PathUtils.java:434)
> at
> org.apache.maven.plugin.ant.AntBuildWriter.writeProperties(AntBuildWriter.java:464)
> at
> org.apache.maven.plugin.ant.AntBuildWriter.writeGeneratedBuildXml(AntBuildWriter.java:266)
> at
> org.apache.maven.plugin.ant.AntBuildWriter.writeBuildXmls(AntBuildWriter.java:113)
> at org.apache.maven.plugin.ant.AntMojo.execute(AntMojo.java:112)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANT-46) mvn ant:ant throws a StringIndexOutOfBoundsException
[
http://jira.codehaus.org/browse/MANT-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143373#action_143373
]
Emmanuel Bourg commented on MANT-46:
I'm not sure to know how to add a test case for a Maven plugin. The easiest way
to reproduce this I guess is to check out the Commons CLI project and issue the
mvn ant:ant command. The SVN repository is located there:
http://svn.apache.org/repos/asf/commons/proper/cli/branches/cli-1.x
> mvn ant:ant throws a StringIndexOutOfBoundsException
>
>
> Key: MANT-46
> URL: http://jira.codehaus.org/browse/MANT-46
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Emmanuel Bourg
>
> I'm trying to generate a Ant build from the Maven 2 POM of Commons CLI but I
> get a StringIndexOutOfBoundsException. I don't know what this is supposed to
> mean.
> Here is the trace:
> {noformat}
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-ant-plugin:2.1:ant'
> -->
> [DEBUG] (f) localRepository = [local] -> file://C:\Documents and
> Settings\Smanux\.m2\repository
> [DEBUG] (f) overwrite = true
> [DEBUG] (f) project = MavenProject: commons-cli:commons-cli:1.2-SNAPSHOT @
> C:\dev\jakarta\cli\pom.xml
> [DEBUG] (f) remoteRepositories = [[apache.snapshots] ->
> http://people.apache.org/repo/m2-snapshot-repository, [central] ->
> http://repo1.maven.org/maven2]
> [DEBUG] (f) settings = [EMAIL PROTECTED]
> [DEBUG] -- end configuration --
> [INFO] [ant:ant]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] String index out of range: -1
> [INFO]
>
> [DEBUG] Trace
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1768)
> at java.lang.String.substring(String.java:1735)
> at org.apache.maven.wagon.PathUtils.toRelative(PathUtils.java:434)
> at
> org.apache.maven.plugin.ant.AntBuildWriter.writeProperties(AntBuildWriter.java:464)
> at
> org.apache.maven.plugin.ant.AntBuildWriter.writeGeneratedBuildXml(AntBuildWriter.java:266)
> at
> org.apache.maven.plugin.ant.AntBuildWriter.writeBuildXmls(AntBuildWriter.java:113)
> at org.apache.maven.plugin.ant.AntMojo.execute(AntMojo.java:112)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANT-46) mvn ant:ant throws a StringIndexOutOfBoundsException
mvn ant:ant throws a StringIndexOutOfBoundsException
Key: MANT-46
URL: http://jira.codehaus.org/browse/MANT-46
Project: Maven 2.x Ant Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Emmanuel Bourg
I'm trying to generate a Ant build from the Maven 2 POM of Commons CLI but I
get a StringIndexOutOfBoundsException. I don't know what this is supposed to
mean.
Here is the trace:
{noformat}
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-ant-plugin:2.1:ant' -->
[DEBUG] (f) localRepository = [local] -> file://C:\Documents and
Settings\Smanux\.m2\repository
[DEBUG] (f) overwrite = true
[DEBUG] (f) project = MavenProject: commons-cli:commons-cli:1.2-SNAPSHOT @
C:\dev\jakarta\cli\pom.xml
[DEBUG] (f) remoteRepositories = [[apache.snapshots] ->
http://people.apache.org/repo/m2-snapshot-repository, [central] ->
http://repo1.maven.org/maven2]
[DEBUG] (f) settings = [EMAIL PROTECTED]
[DEBUG] -- end configuration --
[INFO] [ant:ant]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] String index out of range: -1
[INFO]
[DEBUG] Trace
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1768)
at java.lang.String.substring(String.java:1735)
at org.apache.maven.wagon.PathUtils.toRelative(PathUtils.java:434)
at
org.apache.maven.plugin.ant.AntBuildWriter.writeProperties(AntBuildWriter.java:464)
at
org.apache.maven.plugin.ant.AntBuildWriter.writeGeneratedBuildXml(AntBuildWriter.java:266)
at
org.apache.maven.plugin.ant.AntBuildWriter.writeBuildXmls(AntBuildWriter.java:113)
at org.apache.maven.plugin.ant.AntMojo.execute(AntMojo.java:112)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-509) NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter with Java 1.3
NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter with Java
1.3
---
Key: SUREFIRE-509
URL: http://jira.codehaus.org/browse/SUREFIRE-509
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.4.3
Environment: Windows XP, Sun JDK 1.3.1_20
Reporter: Emmanuel Bourg
Surefire fails to launch the tests with a 1.3 JVM, it returns a
NoClassDefFoundError on SurefireBooter.
I tried to run manually the surefirebooter.jar file created in the temp
directory, it worked with Java 5 but failed with Java 1.3 with the same error.
Here is the manifest of the jar:
{noformat}
Manifest-Version: 1.0
Class-Path: file:/C:/Documents%20and%20Settings/Smanux/.m2/repository/
org/apache/maven/surefire/surefire-booter/2.4.3/surefire-booter-2.4.3
.jar file:/C:/Documents%20and%20Settings/Smanux/.m2/repository/org/ap
ache/maven/surefire/surefire-api/2.4.3/surefire-api-2.4.3.jar file:/C
:/dev/jakarta/cli/target/test-classes/ file:/C:/dev/jakarta/cli/targe
t/classes/ file:/C:/Documents%20and%20Settings/Smanux/.m2/repository/
junit/junit/3.8.1/junit-3.8.1.jar
Main-Class: org.apache.maven.surefire.booter.SurefireBooter
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
