[jira] [Comment Edited] (MCOMPILER-355) NPE in CompilerMojo.preparePaths on exception
[
https://issues.apache.org/jira/browse/MCOMPILER-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818800#comment-16818800
]
Gregor B. Rosenauer edited comment on MCOMPILER-355 at 4/16/19 9:27 AM:
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
com.complexible.stardog
stardog-api
5.3.1
{{}}
Can confirm 3.8.1 fixed the issue for me, too.
was (Author: grexe):
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
com.complexible.stardog
stardog-api
5.3.1
{{}}
> NPE in CompilerMojo.preparePaths on exception
> -
>
> Key: MCOMPILER-355
> URL: https://issues.apache.org/jira/browse/MCOMPILER-355
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Environment: ubunutu 18.04.
>Reporter: Brett Sutton
>Assignee: Robert Scholte
>Priority: Major
> Attachments: testpom.zip
>
>
> I'm getting:
>
> {code:java}
>
> Caused by: java.lang.NullPointerException
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths
> (CompilerMojo.java:244)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:787)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:188)
> 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)
> {code}
>
> Appears to be caused by the exception handling assuming the 'cause' will be
> non-null:
> line 244 is:
> {code:java}
> 243 Throwable cause = pathException.getValue().getCause();
> 244 while ( cause.getCause() != null )
> 245 {
> 246 cause = cause.getCause();
> 247 }{code}
>
> Clearly in some cases pathException.getValue().getCause() is returning null.
> This occurs when I try to build a java 10 project using:
> {code:java}
> mvn deploy{code}
>
> I've narrowed the problem down to this dependancy:
> {code:java}
>
> org.javamoney
> moneta
> 1.3
> pom
> {code}
> If you remove the above dependency then the problem goes away.
> So there is likely to be two problems here. The initial NPE which should be
> easy to fix and then possibly the root cause of the exception.
> Full pom is:
> {code:java}
> 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;>
> 4.0.0
> au.com.noojee
> noojeebilling.api
> 1.4-SNAPSHOT
>
>
>
> src/main/java
>
>
> maven-compiler-plugin
> 3.8.0
>
> 10
>
>
>
>
>
> io.packagecloud.maven.wagon
> maven-packagecloud-wagon
> 0.0.6
>
>
>
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
>
>
>
>
> com.google.code.gson
> gson
> 2.8.5
>
>
>
> org.apache.logging.log4j
> log4j-core
> 2.9.1
>
>
>
> org.javamoney
> moneta
> 1.3
> pom
>
>
>
> org.bouncycastle
> bcprov-jdk15on
> 1.59
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
> {code}
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MCOMPILER-355) NPE in CompilerMojo.preparePaths on exception
[
https://issues.apache.org/jira/browse/MCOMPILER-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818800#comment-16818800
]
Gregor B. Rosenauer edited comment on MCOMPILER-355 at 4/16/19 9:07 AM:
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
com.complexible.stardog
stardog-api
5.3.1
{{}}
was (Author: grexe):
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
{{ com.complexible.stardog}}
{{ stardog-api}}
{{ 5.3.1}}
{{}}
> NPE in CompilerMojo.preparePaths on exception
> -
>
> Key: MCOMPILER-355
> URL: https://issues.apache.org/jira/browse/MCOMPILER-355
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Environment: ubunutu 18.04.
>Reporter: Brett Sutton
>Assignee: Robert Scholte
>Priority: Major
> Attachments: testpom.zip
>
>
> I'm getting:
>
> {code:java}
>
> Caused by: java.lang.NullPointerException
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths
> (CompilerMojo.java:244)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:787)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:188)
> 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)
> {code}
>
> Appears to be caused by the exception handling assuming the 'cause' will be
> non-null:
> line 244 is:
> {code:java}
> 243 Throwable cause = pathException.getValue().getCause();
> 244 while ( cause.getCause() != null )
> 245 {
> 246 cause = cause.getCause();
> 247 }{code}
>
> Clearly in some cases pathException.getValue().getCause() is returning null.
> This occurs when I try to build a java 10 project using:
> {code:java}
> mvn deploy{code}
>
> I've narrowed the problem down to this dependancy:
> {code:java}
>
> org.javamoney
> moneta
> 1.3
> pom
> {code}
> If you remove the above dependency then the problem goes away.
> So there is likely to be two problems here. The initial NPE which should be
> easy to fix and then possibly the root cause of the exception.
> Full pom is:
> {code:java}
> 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;>
> 4.0.0
> au.com.noojee
> noojeebilling.api
> 1.4-SNAPSHOT
>
>
>
> src/main/java
>
>
> maven-compiler-plugin
> 3.8.0
>
> 10
>
>
>
>
>
> io.packagecloud.maven.wagon
> maven-packagecloud-wagon
> 0.0.6
>
>
>
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
>
>
>
>
> com.google.code.gson
> gson
> 2.8.5
>
>
>
> org.apache.logging.log4j
> log4j-core
> 2.9.1
>
>
>
> org.javamoney
> moneta
> 1.3
> pom
>
>
>
> org.bouncycastle
> bcprov-jdk15on
> 1.59
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
> {code}
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-355) NPE in CompilerMojo.preparePaths on exception
[
https://issues.apache.org/jira/browse/MCOMPILER-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818800#comment-16818800
]
Gregor B. Rosenauer commented on MCOMPILER-355:
---
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
{{ com.complexible.stardog}}
{{ stardog-api}}
{{ 5.3.1}}
{{}}
> NPE in CompilerMojo.preparePaths on exception
> -
>
> Key: MCOMPILER-355
> URL: https://issues.apache.org/jira/browse/MCOMPILER-355
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Environment: ubunutu 18.04.
>Reporter: Brett Sutton
>Assignee: Robert Scholte
>Priority: Major
> Attachments: testpom.zip
>
>
> I'm getting:
>
> {code:java}
>
> Caused by: java.lang.NullPointerException
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths
> (CompilerMojo.java:244)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:787)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:188)
> 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)
> {code}
>
> Appears to be caused by the exception handling assuming the 'cause' will be
> non-null:
> line 244 is:
> {code:java}
> 243 Throwable cause = pathException.getValue().getCause();
> 244 while ( cause.getCause() != null )
> 245 {
> 246 cause = cause.getCause();
> 247 }{code}
>
> Clearly in some cases pathException.getValue().getCause() is returning null.
> This occurs when I try to build a java 10 project using:
> {code:java}
> mvn deploy{code}
>
> I've narrowed the problem down to this dependancy:
> {code:java}
>
> org.javamoney
> moneta
> 1.3
> pom
> {code}
> If you remove the above dependency then the problem goes away.
> So there is likely to be two problems here. The initial NPE which should be
> easy to fix and then possibly the root cause of the exception.
> Full pom is:
> {code:java}
> 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;>
> 4.0.0
> au.com.noojee
> noojeebilling.api
> 1.4-SNAPSHOT
>
>
>
> src/main/java
>
>
> maven-compiler-plugin
> 3.8.0
>
> 10
>
>
>
>
>
> io.packagecloud.maven.wagon
> maven-packagecloud-wagon
> 0.0.6
>
>
>
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
>
>
>
>
> com.google.code.gson
> gson
> 2.8.5
>
>
>
> org.apache.logging.log4j
> log4j-core
> 2.9.1
>
>
>
> org.javamoney
> moneta
> 1.3
> pom
>
>
>
> org.bouncycastle
> bcprov-jdk15on
> 1.59
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
> {code}
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6123) detect self references in POM and fail fast
[
https://issues.apache.org/jira/browse/MNG-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregor B. Rosenauer updated MNG-6123:
-
Description:
Maven does not detect self references in a POM and tries to download the
artifact it is about to build, which makes no sense and should result in an
early error and abort of the build.
E.g. sample POM:
{code}
org.my.acme
my-module
1.2.3
...
${project.groupId}
my-module
${project.version}
{code}
Maven tries to download my-module.jar but obviously fails...
was:
Maven does not detect self references in a POM and tries to download the
artifact it is about to build, which makes no sense and should result in an
early error and abort of the build.
E.g. pseudo POM:
{code}
org.my.acme
my-module
1.2.3
...
${project.groupId}
my-module
${project.version}
{code}
Maven tries to download my-module.jar but obviously fails...
> detect self references in POM and fail fast
> ---
>
> Key: MNG-6123
> URL: https://issues.apache.org/jira/browse/MNG-6123
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build, Dependencies
>Affects Versions: 3.3.9
> Environment: Oracle JDK 1.8.0_111 on Linux 4.8 x64
>Reporter: Gregor B. Rosenauer
>Priority: Minor
> Labels: build, easyfix
>
> Maven does not detect self references in a POM and tries to download the
> artifact it is about to build, which makes no sense and should result in an
> early error and abort of the build.
> E.g. sample POM:
> {code}
> org.my.acme
> my-module
> 1.2.3
>
> ...
>
> ${project.groupId}
> my-module
> ${project.version}
>
>
> {code}
> Maven tries to download my-module.jar but obviously fails...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-6123) detect self references in POM and fail fast
Gregor B. Rosenauer created MNG-6123:
Summary: detect self references in POM and fail fast
Key: MNG-6123
URL: https://issues.apache.org/jira/browse/MNG-6123
Project: Maven
Issue Type: Improvement
Components: Bootstrap & Build, Dependencies
Affects Versions: 3.3.9
Environment: Oracle JDK 1.8.0_111 on Linux 4.8 x64
Reporter: Gregor B. Rosenauer
Priority: Minor
Maven does not detect self references in a POM and tries to download the
artifact it is about to build, which makes no sense and should result in an
early error and abort of the build.
E.g. pseudo POM:
{code}
org.my.acme
my-module
1.2.3
...
${project.groupId}
my-module
${project.version}
{code}
Maven tries to download my-module.jar but obviously fails...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-6122) detect self references in POM and fail fast
Gregor B. Rosenauer created MNG-6122:
Summary: detect self references in POM and fail fast
Key: MNG-6122
URL: https://issues.apache.org/jira/browse/MNG-6122
Project: Maven
Issue Type: Improvement
Components: Bootstrap & Build, Dependencies
Affects Versions: 3.3.9
Environment: Oracle JDK 1.8.0_111 on Linux 4.8 x64
Reporter: Gregor B. Rosenauer
Maven does not detect self references in a POM and tries to download the
artifact it is about to build, which makes no sense and should result in an
early error and abort of the build.
E.g. pseudo POM:
{code}
org.my.acme
my-module
1.2.3
...
${project.groupId}
my-module
${project.version}
{code}
Maven tries to download my-module.jar but obviously fails...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-6060) better and precise error reporting when project is not found e.g. with -rf option
Gregor B. Rosenauer created MNG-6060:
Summary: better and precise error reporting when project is not
found e.g. with -rf option
Key: MNG-6060
URL: https://issues.apache.org/jira/browse/MNG-6060
Project: Maven
Issue Type: Improvement
Components: Command Line, Errors, POM, Reactor and workspace
Affects Versions: 3.3.9
Environment: Linux 4.6.2 with Oracle JDK 8
Reporter: Gregor B. Rosenauer
Priority: Trivial
when building a multi-module project with -rf and the project is not found,
Maven explodes all over your face and prints the *entire* POM instead of just
pointing out the missing project - it does, but hides it before the POM dump so
the info is easily lost:
{{[ERROR] [ERROR] Could not find project to resume reactor build from:
:missing-in-action vs [MavenProject: (entire POM dumped here)}}
Good old make would just tell you this precise and helpful message, instead of
dumping the entire makefile:
{{make: *** No rule to make target 'some-nonexisting-target'. Stop.}}
Please make maven a bit more user friendly when reporting errors...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MNG-5323) Add ability to interrupt a build with SUCCESS status from maven plugins.
[ https://jira.codehaus.org/browse/MNG-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308079#comment-308079 ] Gregor B. Rosenauer commented on MNG-5323: -- I thought maven would already do that if you don't supply the clean option..? Shouldn't this be handled by the Plexus container itself, instead of controlling the build process from the plugin? Seems like the tail wagging the dog to me... Add ability to interrupt a build with SUCCESS status from maven plugins. Key: MNG-5323 URL: https://jira.codehaus.org/browse/MNG-5323 Project: Maven 2 3 Issue Type: Improvement Components: General, Plugin API Affects Versions: 3.0.5 Environment: any Reporter: Stanislav Tyurikov Priority: Critical Attachments: build_succeed_exception.patch Add ability to successfully finish a build from maven plugin. It can help to create maven plugins for build optimization. Currently we can interrupt a build only to fail it (by throwing an exception from the execute method of a mojo). This functionality can be easily implemented by adding BuildSuccessException to the maven core and modifying LifecycleModuleBuilder and DefaultBuildPluginManager to process this exception and finish the build as succeed. Any custom maven plugin can throw BuildSuccessException to indicate the build is OK and no further steps are needed to be executed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5345) command line option to get status of last build
Gregor B. Rosenauer created MNG-5345: Summary: command line option to get status of last build Key: MNG-5345 URL: https://jira.codehaus.org/browse/MNG-5345 Project: Maven 2 3 Issue Type: Improvement Components: Command Line, Reactor and workspace Affects Versions: 3.0.4 Environment: Linux 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Reporter: Gregor B. Rosenauer Priority: Minor I would find it very useful to be able to quickly get the status of my last build (without having to dig out the log or look at the date of generated artifacts). Something like mvn status that immediately gives me a quick glance at the project's health in my local workspace, as I don't want to and cannot rely on a CI server for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MPXDOC-206) Including DTD breaks xdoc
[ http://jira.codehaus.org/browse/MPXDOC-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregor B. Rosenauer reopened MPXDOC-206: sorry, have to reopen because the issue has resurfaced. The build fails exactly on the first XDOC that includes the DOCTYPE, as soon as I remove it, it runs through. Log: xdoc:jelly-transform: About to use JSL stylesheet file:/C:/Dokumente und Einstellungen/Orth/.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources/site.jsl [echo] de_AT.UTF-8 [echo] The current Locale is the default one [echo] Scanning 'C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs'... [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/changelog-report.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\changelog-report.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/changes-report.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\changes-report.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/dependencies.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\dependencies.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/development-process.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\development-process.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/downloads.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\downloads.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/faq.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\faq.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/file-activity-report.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\file-activity-report.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/index.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\index.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/issue-tracking.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\issue-tracking.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/mail-lists.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\mail-lists.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/maven-reports.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\maven-reports.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/project-info.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\project-info.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/scm-usage.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\scm-usage.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/team-list.html from C:\ta30\workspaces\dda_25\ddaMain\target\generated-xdocs\team-list.xml Transforming user supplied documentation. [echo] The current Locale is the default one [echo] Scanning 'C:\ta30\workspaces\dda_25\ddaMain\xdocs'... [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/adobeCentralTemplates.html from C:\ta30\workspaces\dda_25\ddaMain\xdocs\adobeCentralTemplates.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/aktualisierung.html from C:\ta30\workspaces\dda_25\ddaMain\xdocs\aktualisierung.xml [echo] Generating C:/ta30/workspaces/dda_25/ddaMain/target/docs/batch.html from C:\ta30\workspaces\dda_25\ddaMain\xdocs\batch.xml --- Unable to obtain goal [xdoc:transform] Connection timed out: connect Nested exception: Connection timed out: connect Connection timed out: connect --- BUILD FAILED Including DTD breaks xdoc -- Key: MPXDOC-206 URL: http://jira.codehaus.org/browse/MPXDOC-206 Project: Maven 1.x XDoc Plugin Issue Type: Bug Affects Versions: 1.10.1 Environment: WindowsXP SP2 x86, JDK6 build 1.6.0_05-b13 Reporter: Gregor B. Rosenauer Priority: Minor Attachments: error-report.txt When including the XDoc-DTD as mentioned in issue MPXDOC-192 site generation fails with a Jelly-Exception. I cannot say if this is an issue with the xdoc-plugin or with jelly. My document starts with ?xml version=1.0 encoding=UTF-8? !DOCTYPE document PUBLIC -//Apache Software Foundation//DTD XDOC 1.0//EN http://maven.apache.org/dtd/xdoc_1_0.dtd; When invoking the goal xdoc:generate-from-pom (called through a custom goal ta30:doku) I get a Jelly-Exception (full report attached): Caused by: org.apache.commons.jelly.JellyTagException: file:C:/Dokumente und
[jira] Commented: (MPXDOC-206) Including DTD breaks xdoc
[
http://jira.codehaus.org/browse/MPXDOC-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130752#action_130752
]
Gregor B. Rosenauer commented on MPXDOC-206:
When launching the xdoc:default-goal directly, it stops at the same position,
so no custom build issues here:
{quote}
xdoc:generate-from-pom:
[echo] Generating xdocs from POM ...
xdoc:sitemap-noinit:
---
Unable to obtain goal [xdoc:generate-from-pom]
Connection timed out: connect Nested exception: Connection timed out: connect
Connection timed out: connect
---
BUILD FAILED
{quote}
However launching the goal xdoc:transform directly generates the documentation
correctly.
Including DTD breaks xdoc
--
Key: MPXDOC-206
URL: http://jira.codehaus.org/browse/MPXDOC-206
Project: Maven 1.x XDoc Plugin
Issue Type: Bug
Affects Versions: 1.10.1
Environment: WindowsXP SP2 x86, JDK6 build 1.6.0_05-b13
Reporter: Gregor B. Rosenauer
Priority: Minor
Attachments: error-report.txt
When including the XDoc-DTD as mentioned in issue MPXDOC-192 site generation
fails with a Jelly-Exception.
I cannot say if this is an issue with the xdoc-plugin or with jelly.
My document starts with
?xml version=1.0 encoding=UTF-8?
!DOCTYPE document PUBLIC -//Apache Software Foundation//DTD XDOC 1.0//EN
http://maven.apache.org/dtd/xdoc_1_0.dtd;
When invoking the goal xdoc:generate-from-pom (called through a custom goal
ta30:doku) I get a Jelly-Exception (full report attached):
Caused by: org.apache.commons.jelly.JellyTagException: file:C:/Dokumente und
Einstellungen/Orth/.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources/sitemap.jsl:84:51:
x:parse Connection timed out: connect Nested exception: Connection t
imed out: connect
at
org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo
rt.java:186)
at
org.apache.commons.jelly.tags.xml.ParseTag.getXmlDocument(ParseTag.ja
va:106)
at org.apache.commons.jelly.tags.xml.ParseTag.doTag(ParseTag.java:55)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.ja
va:68)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:
160)
at org.dom4j.rule.Mode.fireRule(Mode.java:59)
at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:185)
at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:159)
at
org.apache.commons.jelly.tags.jsl.ApplyTemplatesTag.doTag(ApplyTempla
tesTag.java:67)
... 112 more
Caused by: org.dom4j.DocumentException: Connection timed out: connect Nested
exc
eption: Connection timed out: connect
at org.dom4j.io.SAXReader.read(SAXReader.java:484)
at org.dom4j.io.SAXReader.read(SAXReader.java:264)
at
org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo
rt.java:168)
... 126 more
Leaving out the DTD fixes the issue, but then I cannot edit the xdoc-file
in an XML-editor like the excellent visual XMLmind-editor (with
xdoc-type-plugin).
--
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] Issue Comment Edited: (MPXDOC-206) Including DTD breaks xdoc
[
http://jira.codehaus.org/browse/MPXDOC-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130752#action_130752
]
grexe edited comment on MPXDOC-206 at 4/14/08 11:07 AM:
--
When launching the xdoc:default-goal directly, it stops at the same position,
so no custom build issues here:
{quote}
xdoc:generate-from-pom:
[echo] Generating xdocs from POM ...
xdoc:sitemap-noinit:
---
Unable to obtain goal [xdoc:generate-from-pom]
Connection timed out: connect Nested exception: Connection timed out: connect
Connection timed out: connect
---
BUILD FAILED
{quote}
However launching the goal xdoc:transform directly generates the documentation
correctly.
*Update:*
The culprit was a DOCTYPE declaration in the changes.xml - the changelog-plugin
does not accept this doctype and has trouble looking up the DTD it seems. Also,
changes.xml-files do not conform to the general XDOC-doctype (does not know the
release-tag etc.), so the declaration was in the wrong place anyway.
Now I only need to figure out why my sitemap is generated wrong even though I
did not include any sitemap in my menu.xml - but that's another story...
was (Author: grexe):
When launching the xdoc:default-goal directly, it stops at the same
position, so no custom build issues here:
{quote}
xdoc:generate-from-pom:
[echo] Generating xdocs from POM ...
xdoc:sitemap-noinit:
---
Unable to obtain goal [xdoc:generate-from-pom]
Connection timed out: connect Nested exception: Connection timed out: connect
Connection timed out: connect
---
BUILD FAILED
{quote}
However launching the goal xdoc:transform directly generates the documentation
correctly.
Including DTD breaks xdoc
--
Key: MPXDOC-206
URL: http://jira.codehaus.org/browse/MPXDOC-206
Project: Maven 1.x XDoc Plugin
Issue Type: Bug
Affects Versions: 1.10.1
Environment: WindowsXP SP2 x86, JDK6 build 1.6.0_05-b13
Reporter: Gregor B. Rosenauer
Priority: Minor
Attachments: error-report.txt
When including the XDoc-DTD as mentioned in issue MPXDOC-192 site generation
fails with a Jelly-Exception.
I cannot say if this is an issue with the xdoc-plugin or with jelly.
My document starts with
?xml version=1.0 encoding=UTF-8?
!DOCTYPE document PUBLIC -//Apache Software Foundation//DTD XDOC 1.0//EN
http://maven.apache.org/dtd/xdoc_1_0.dtd;
When invoking the goal xdoc:generate-from-pom (called through a custom goal
ta30:doku) I get a Jelly-Exception (full report attached):
Caused by: org.apache.commons.jelly.JellyTagException: file:C:/Dokumente und
Einstellungen/Orth/.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources/sitemap.jsl:84:51:
x:parse Connection timed out: connect Nested exception: Connection t
imed out: connect
at
org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo
rt.java:186)
at
org.apache.commons.jelly.tags.xml.ParseTag.getXmlDocument(ParseTag.ja
va:106)
at org.apache.commons.jelly.tags.xml.ParseTag.doTag(ParseTag.java:55)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.ja
va:68)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:
160)
at org.dom4j.rule.Mode.fireRule(Mode.java:59)
at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:185)
at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:159)
at
org.apache.commons.jelly.tags.jsl.ApplyTemplatesTag.doTag(ApplyTempla
tesTag.java:67)
... 112 more
Caused by: org.dom4j.DocumentException: Connection timed out: connect Nested
exc
eption: Connection timed out: connect
at org.dom4j.io.SAXReader.read(SAXReader.java:484)
at org.dom4j.io.SAXReader.read(SAXReader.java:264)
at
org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo
rt.java:168)
... 126 more
Leaving out the DTD fixes the issue, but then I cannot edit the xdoc-file
[jira] Resolved: (MPXDOC-206) Including DTD breaks xdoc
[ http://jira.codehaus.org/browse/MPXDOC-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregor B. Rosenauer resolved MPXDOC-206. Resolution: Fixed Including DTD breaks xdoc -- Key: MPXDOC-206 URL: http://jira.codehaus.org/browse/MPXDOC-206 Project: Maven 1.x XDoc Plugin Issue Type: Bug Affects Versions: 1.10.1 Environment: WindowsXP SP2 x86, JDK6 build 1.6.0_05-b13 Reporter: Gregor B. Rosenauer Priority: Minor Attachments: error-report.txt When including the XDoc-DTD as mentioned in issue MPXDOC-192 site generation fails with a Jelly-Exception. I cannot say if this is an issue with the xdoc-plugin or with jelly. My document starts with ?xml version=1.0 encoding=UTF-8? !DOCTYPE document PUBLIC -//Apache Software Foundation//DTD XDOC 1.0//EN http://maven.apache.org/dtd/xdoc_1_0.dtd; When invoking the goal xdoc:generate-from-pom (called through a custom goal ta30:doku) I get a Jelly-Exception (full report attached): Caused by: org.apache.commons.jelly.JellyTagException: file:C:/Dokumente und Einstellungen/Orth/.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources/sitemap.jsl:84:51: x:parse Connection timed out: connect Nested exception: Connection t imed out: connect at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo rt.java:186) at org.apache.commons.jelly.tags.xml.ParseTag.getXmlDocument(ParseTag.ja va:106) at org.apache.commons.jelly.tags.xml.ParseTag.doTag(ParseTag.java:55) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.ja va:68) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java: 160) at org.dom4j.rule.Mode.fireRule(Mode.java:59) at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:185) at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:159) at org.apache.commons.jelly.tags.jsl.ApplyTemplatesTag.doTag(ApplyTempla tesTag.java:67) ... 112 more Caused by: org.dom4j.DocumentException: Connection timed out: connect Nested exc eption: Connection timed out: connect at org.dom4j.io.SAXReader.read(SAXReader.java:484) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo rt.java:168) ... 126 more Leaving out the DTD fixes the issue, but then I cannot edit the xdoc-file in an XML-editor like the excellent visual XMLmind-editor (with xdoc-type-plugin). -- 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: (MPXDOC-206) Including DTD breaks xdoc
[ http://jira.codehaus.org/browse/MPXDOC-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130517#action_130517 ] Gregor B. Rosenauer commented on MPXDOC-206: (I am currently at home but will try on Monday at work) I have configured the proxy for my Maven1-environment properly and it works normally, do I have to specify a separate proxy in this case? Is there another configuration I am not aware of? It is true that it looks like a timeout, but I have maven.proxy.host and maven.proxy.port configured properly. Including DTD breaks xdoc -- Key: MPXDOC-206 URL: http://jira.codehaus.org/browse/MPXDOC-206 Project: Maven 1.x XDoc Plugin Issue Type: Bug Affects Versions: 1.10.1 Environment: WindowsXP SP2 x86, JDK6 build 1.6.0_05-b13 Reporter: Gregor B. Rosenauer Priority: Minor Attachments: error-report.txt When including the XDoc-DTD as mentioned in issue MPXDOC-192 site generation fails with a Jelly-Exception. I cannot say if this is an issue with the xdoc-plugin or with jelly. My document starts with ?xml version=1.0 encoding=UTF-8? !DOCTYPE document PUBLIC -//Apache Software Foundation//DTD XDOC 1.0//EN http://maven.apache.org/dtd/xdoc_1_0.dtd; When invoking the goal xdoc:generate-from-pom (called through a custom goal ta30:doku) I get a Jelly-Exception (full report attached): Caused by: org.apache.commons.jelly.JellyTagException: file:C:/Dokumente und Einstellungen/Orth/.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources/sitemap.jsl:84:51: x:parse Connection timed out: connect Nested exception: Connection t imed out: connect at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo rt.java:186) at org.apache.commons.jelly.tags.xml.ParseTag.getXmlDocument(ParseTag.ja va:106) at org.apache.commons.jelly.tags.xml.ParseTag.doTag(ParseTag.java:55) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.ja va:68) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java: 160) at org.dom4j.rule.Mode.fireRule(Mode.java:59) at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:185) at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:159) at org.apache.commons.jelly.tags.jsl.ApplyTemplatesTag.doTag(ApplyTempla tesTag.java:67) ... 112 more Caused by: org.dom4j.DocumentException: Connection timed out: connect Nested exc eption: Connection timed out: connect at org.dom4j.io.SAXReader.read(SAXReader.java:484) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo rt.java:168) ... 126 more Leaving out the DTD fixes the issue, but then I cannot edit the xdoc-file in an XML-editor like the excellent visual XMLmind-editor (with xdoc-type-plugin). -- 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: (MPXDOC-206) Including DTD breaks xdoc
Including DTD breaks xdoc -- Key: MPXDOC-206 URL: http://jira.codehaus.org/browse/MPXDOC-206 Project: Maven 1.x XDoc Plugin Issue Type: Bug Affects Versions: 1.10.1 Environment: WindowsXP SP2 x86, JDK6 build 1.6.0_05-b13 Reporter: Gregor B. Rosenauer Priority: Minor Attachments: error-report.txt When including the XDoc-DTD as mentioned in issue MPXDOC-192 site generation fails with a Jelly-Exception. I cannot say if this is an issue with the xdoc-plugin or with jelly. My document starts with ?xml version=1.0 encoding=UTF-8? !DOCTYPE document PUBLIC -//Apache Software Foundation//DTD XDOC 1.0//EN http://maven.apache.org/dtd/xdoc_1_0.dtd; When invoking the goal xdoc:generate-from-pom (called through a custom goal ta30:doku) I get a Jelly-Exception (full report attached): Caused by: org.apache.commons.jelly.JellyTagException: file:C:/Dokumente und Einstellungen/Orth/.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources/sitemap.jsl:84:51: x:parse Connection timed out: connect Nested exception: Connection t imed out: connect at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo rt.java:186) at org.apache.commons.jelly.tags.xml.ParseTag.getXmlDocument(ParseTag.ja va:106) at org.apache.commons.jelly.tags.xml.ParseTag.doTag(ParseTag.java:55) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.ja va:68) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java: 160) at org.dom4j.rule.Mode.fireRule(Mode.java:59) at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:185) at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:159) at org.apache.commons.jelly.tags.jsl.ApplyTemplatesTag.doTag(ApplyTempla tesTag.java:67) ... 112 more Caused by: org.dom4j.DocumentException: Connection timed out: connect Nested exc eption: Connection timed out: connect at org.dom4j.io.SAXReader.read(SAXReader.java:484) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo rt.java:168) ... 126 more Leaving out the DTD fixes the issue, but then I cannot edit the xdoc-file in an XML-editor like the excellent visual XMLmind-editor (with xdoc-type-plugin). -- 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
