[jira] [Commented] (MPIR-401) Mailing list subscribe and unsubscribe links
[ https://issues.apache.org/jira/browse/MPIR-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331580#comment-17331580 ] Lukas Theussl commented on MPIR-401: For my use case it's fixed, thanks! Any chance this gets released soon? > Mailing list subscribe and unsubscribe links > > > Key: MPIR-401 > URL: https://issues.apache.org/jira/browse/MPIR-401 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: mailing-lists >Affects Versions: 3.1.2 >Reporter: Joshua >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.2 > > > This is related to the fix done in > https://issues.apache.org/jira/browse/MPIR-398 > We were using the mailing list a little different that what was expected. > So for us we don't have a mailing list, but we do have yammer and we were > using the subscribe and unsubscribe links to subscribe and unsubscribe to our > yammer group. We use the yammer group as a mailing list. > When we took 3.1.2 it broke our links because now they have a mailto: before > the link. > Curious if it would be possible to enhance this code to detect if the value > in the unsubscribe and subscribe is an email address or a URL. If it is an > email address then add the mailto: other wise don't. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPIR-401) Mailing list subscribe and unsubscribe links
[ https://issues.apache.org/jira/browse/MPIR-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MPIR-401: --- Affects Version/s: (was: 3.1.2) 3.1.1 > Mailing list subscribe and unsubscribe links > > > Key: MPIR-401 > URL: https://issues.apache.org/jira/browse/MPIR-401 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: mailing-lists >Affects Versions: 3.1.1 >Reporter: Joshua >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.2 > > > This is related to the fix done in > https://issues.apache.org/jira/browse/MPIR-398 > We were using the mailing list a little different that what was expected. > So for us we don't have a mailing list, but we do have yammer and we were > using the subscribe and unsubscribe links to subscribe and unsubscribe to our > yammer group. We use the yammer group as a mailing list. > When we took 3.1.2 it broke our links because now they have a mailto: before > the link. > Curious if it would be possible to enhance this code to detect if the value > in the unsubscribe and subscribe is an email address or a URL. If it is an > email address then add the mailto: other wise don't. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPIR-401) Mailing list subscribe and unsubscribe links
[
https://issues.apache.org/jira/browse/MPIR-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324524#comment-17324524
]
Lukas Theussl commented on MPIR-401:
I'm not quite sure where the problem stems from but I agree of course that the
specification and documentation has to be unambiguous in the first place.
However, and in any case, this is still a regression.
{{[https://sf.net/subscribe]}} *is* a valid URI with a proper scheme, appending
{{mailto}}: here is simply a bug.
> Mailing list subscribe and unsubscribe links
>
>
> Key: MPIR-401
> URL: https://issues.apache.org/jira/browse/MPIR-401
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
> Components: mailing-lists
>Affects Versions: 3.1.2
>Reporter: Joshua
>Priority: Major
>
> This is related to the fix done in
> https://issues.apache.org/jira/browse/MPIR-398
> We were using the mailing list a little different that what was expected.
> So for us we don't have a mailing list, but we do have yammer and we were
> using the subscribe and unsubscribe links to subscribe and unsubscribe to our
> yammer group. We use the yammer group as a mailing list.
> When we took 3.1.2 it broke our links because now they have a mailto: before
> the link.
> Curious if it would be possible to enhance this code to detect if the value
> in the unsubscribe and subscribe is an email address or a URL. If it is an
> email address then add the mailto: other wise don't.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MPIR-401) Mailing list subscribe and unsubscribe links
[
https://issues.apache.org/jira/browse/MPIR-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324440#comment-17324440
]
Lukas Theussl edited comment on MPIR-401 at 4/18/21, 7:20 AM:
--
To be specific: I just checked that with the following input
{quote}https://sf.net/subscribe
unsubscr...@sf.net
{quote}
Using pir plugin 2.9 I get correct links. ie *only* the unsubscribe address
gets a {{mailto:}}. With 3.1.1 *both* links get a {{mailto:}}.
was (Author: ltheussl):
To be specific: I just checked that with the following input
{{https://sf.net/subscribe}}
{{ unsubscr...@sf.net}}
Using pir plugin 2.9 I get correct links. ie *only* the unsubscribe address
gets a {{mailto:}}. With 3.1.1 *both* links get a {{mailto:}}.
> Mailing list subscribe and unsubscribe links
>
>
> Key: MPIR-401
> URL: https://issues.apache.org/jira/browse/MPIR-401
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
> Components: mailing-lists
>Affects Versions: 3.1.2
>Reporter: Joshua
>Priority: Major
>
> This is related to the fix done in
> https://issues.apache.org/jira/browse/MPIR-398
> We were using the mailing list a little different that what was expected.
> So for us we don't have a mailing list, but we do have yammer and we were
> using the subscribe and unsubscribe links to subscribe and unsubscribe to our
> yammer group. We use the yammer group as a mailing list.
> When we took 3.1.2 it broke our links because now they have a mailto: before
> the link.
> Curious if it would be possible to enhance this code to detect if the value
> in the unsubscribe and subscribe is an email address or a URL. If it is an
> email address then add the mailto: other wise don't.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPIR-401) Mailing list subscribe and unsubscribe links
[
https://issues.apache.org/jira/browse/MPIR-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324440#comment-17324440
]
Lukas Theussl commented on MPIR-401:
To be specific: I just checked that with the following input
{{https://sf.net/subscribe}}
{{ unsubscr...@sf.net}}
Using pir plugin 2.9 I get correct links. ie *only* the unsubscribe address
gets a {{mailto:}}. With 3.1.1 *both* links get a {{mailto:}}.
> Mailing list subscribe and unsubscribe links
>
>
> Key: MPIR-401
> URL: https://issues.apache.org/jira/browse/MPIR-401
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
> Components: mailing-lists
>Affects Versions: 3.1.2
>Reporter: Joshua
>Priority: Major
>
> This is related to the fix done in
> https://issues.apache.org/jira/browse/MPIR-398
> We were using the mailing list a little different that what was expected.
> So for us we don't have a mailing list, but we do have yammer and we were
> using the subscribe and unsubscribe links to subscribe and unsubscribe to our
> yammer group. We use the yammer group as a mailing list.
> When we took 3.1.2 it broke our links because now they have a mailto: before
> the link.
> Curious if it would be possible to enhance this code to detect if the value
> in the unsubscribe and subscribe is an email address or a URL. If it is an
> email address then add the mailto: other wise don't.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPIR-401) Mailing list subscribe and unsubscribe links
[
https://issues.apache.org/jira/browse/MPIR-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324430#comment-17324430
]
Lukas Theussl commented on MPIR-401:
This is still broken IMO. The 'specification' you link above is just a
reference, the documentation for [Maven
Model|https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_mailingList]
explicitly states that all three: subscribe, unsubscribe and post, can be an
email address *or* link, and that {{mailto:}} is *only* added if the url is an
email address. This used to work in the past.
My use case: SourceForge does not provide a direct email address for
subscribe/unsubscribe, only a web interface.
> Mailing list subscribe and unsubscribe links
>
>
> Key: MPIR-401
> URL: https://issues.apache.org/jira/browse/MPIR-401
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
> Components: mailing-lists
>Affects Versions: 3.1.2
>Reporter: Joshua
>Priority: Major
>
> This is related to the fix done in
> https://issues.apache.org/jira/browse/MPIR-398
> We were using the mailing list a little different that what was expected.
> So for us we don't have a mailing list, but we do have yammer and we were
> using the subscribe and unsubscribe links to subscribe and unsubscribe to our
> yammer group. We use the yammer group as a mailing list.
> When we took 3.1.2 it broke our links because now they have a mailto: before
> the link.
> Curious if it would be possible to enhance this code to detect if the value
> in the unsubscribe and subscribe is an email address or a URL. If it is an
> email address then add the mailto: other wise don't.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] (MPDF-60) Locale properties for Spanish and Galician
[ https://jira.codehaus.org/browse/MPDF-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPDF-60. - Resolution: Fixed Fix Version/s: 1.3 Assignee: Lukas Theussl Applied in [r1470835|http://svn.apache.org/r1470835]. Thanks! Locale properties for Spanish and Galician -- Key: MPDF-60 URL: https://jira.codehaus.org/browse/MPDF-60 Project: Maven 2.x PDF Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: Ramon Rial Quintela Assignee: Lukas Theussl Priority: Trivial Fix For: 1.3 Attachments: pdf-plugin_es_ES.properties, pdf-plugin_gl_ES.properties I would like to contribute with the properties files corresponding to the translation to Spanish and Galician languages. Galician language is part of ISO 639-1 (http://www.loc.gov/standards/iso639-2/php/langcodes_name.php?iso_639_1=gl) properties_es_ES.properties = Spanish locale. properties_gl_ES.properties = Galician locale (Spanish). -- 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] (DOXIA-361) Confluence: figure captions not rendered
[ https://jira.codehaus.org/browse/DOXIA-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=323649#comment-323649 ] Lukas Theussl commented on DOXIA-361: - Hmm, I hadn't realized that... From an objective point of view, I'd certainly go for option 2: XhtmlBaseSink.figure() should just forward to XhtmlBaseSink.figure( null ). Unfortunately, I don't remember the details but I suppose there were some backward-compat arguments to keep it the way it is, as otherwise I would not have specifically added the note linked above. Confluence: figure captions not rendered Key: DOXIA-361 URL: https://jira.codehaus.org/browse/DOXIA-361 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.1 Reporter: Lukas Theussl Assignee: Robert Scholte Attachments: DOXIA-361.patch Figure captions seem to go into the img alt= attribute, ie they are not rendered in the xhtml output. -- 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] (DOXIA-361) Confluence: figure captions not rendered
[ https://jira.codehaus.org/browse/DOXIA-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=323662#comment-323662 ] Lukas Theussl commented on DOXIA-361: - Not sure if I'm missing something but I think this issue, concerning only the confluence parser, should be fixed in 1.x. Fixing the XhtmlBaseSink should probably go into 2.0. Confluence: figure captions not rendered Key: DOXIA-361 URL: https://jira.codehaus.org/browse/DOXIA-361 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence, Module - Xhtml Affects Versions: 1.1 Reporter: Lukas Theussl Assignee: Robert Scholte Fix For: 2.0 Attachments: DOXIA-361.patch Figure captions seem to go into the img alt= attribute, ie they are not rendered in the xhtml output. -- 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] (DOXIA-361) Confluence: figure captions not rendered
[ https://jira.codehaus.org/browse/DOXIA-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-361: Attachment: DOXIA-361.patch The fix is simply to use sink events that take a SinkEventAttributeSet, see the Note at http://maven.apache.org/doxia/issues/#Figure_sink_events I have checked by inspection that captions are rendered correctly in html output but got no time to properly implement a test case. :( Confluence: figure captions not rendered Key: DOXIA-361 URL: https://jira.codehaus.org/browse/DOXIA-361 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.1 Reporter: Lukas Theussl Attachments: DOXIA-361.patch Figure captions seem to go into the img alt= attribute, ie they are not rendered in the xhtml output. -- 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] (DOXIA-361) Confluence: figure captions not rendered
[ https://jira.codehaus.org/browse/DOXIA-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=323510#comment-323510 ] Lukas Theussl commented on DOXIA-361: - This issue is about the confluence parser. There is a test in doxia-site-renderer (see [figure.confluence|http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/test/resources/site/confluence/confluence/figure.confluence?view=markup]). As far as I can tell this test is not asserted, but the resulting figure.html file shows the defect. Confluence: figure captions not rendered Key: DOXIA-361 URL: https://jira.codehaus.org/browse/DOXIA-361 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.1 Reporter: Lukas Theussl Figure captions seem to go into the img alt= attribute, ie they are not rendered in the xhtml output. -- 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] (DOXIASITETOOLS-79) APT document with verbatim section including C #include causes NPE
[
https://jira.codehaus.org/browse/DOXIASITETOOLS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321340#comment-321340
]
Lukas Theussl commented on DOXIASITETOOLS-79:
-
Thanks! :)
APT document with verbatim section including C #include causes NPE
--
Key: DOXIASITETOOLS-79
URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-79
Project: Maven Doxia Sitetools
Issue Type: Bug
Reporter: Andy Isaacson
Assignee: Lukas Theussl
Fix For: 1.4
Attachments: mtest.tar.gz
A simple apt.vm document including a C program fragment in a verbatim section
causes mvn site to fail with a NPE. The failure can be worked around by
escaping the # as backslash-# but the requirement to do this is not
documented, nor AFAICS is the feature of supporting #include in verbatim
sections.
Attaching a complete testcase mtest.tar.gz.
{noformat}
% cat src/site/apt/hello.vm
#include stdio.h
int main(void) { printf(hello, world!\n); return 0; }
% mvn --version
Apache Maven 3.0.4
Maven home: /usr/share/maven
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.6.6, arch: amd64, family: unix
% mvn site
...
[WARNING] No project URL defined - decoration links will not be relativized!
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
skin.
[ERROR] Parser Exception: /tmp/mtest/src/site/apt/hello.apt.vm
[ERROR] org.apache.velocity.runtime.parser.ParseException: Encountered
\stdio.h\ at line 2, column 13.
Was expecting:
( ...
at
org.apache.velocity.runtime.parser.Parser.generateParseException(Parser.java:3360)
at
org.apache.velocity.runtime.parser.Parser.jj_consume_token(Parser.java:3237)
...
[ERROR] ResourceManager.getResource() parse exception
[ERROR] org.apache.velocity.exception.ParseErrorException: Encountered
\stdio.h\ at line 2, column 13 of /tmp/mtest/src/site/apt/hello.apt.vm
Was expecting:
( ...
at org.apache.velocity.Template.process(Template.java:137)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102)
at
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:498)
...
[ERROR] Error parsing /tmp/mtest/src/site/apt/hello.apt.vm as a velocity
template, using as text.
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.798s
[INFO] Finished at: Fri Jan 18 12:51:17 PST 2013
[INFO] Final Memory: 11M/153M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
mtest: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.0:site failed.
NullPointerException - [Help 1]
{noformat}
--
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] (MSITE-672) Interpolation of site deploy URL not done in child
[
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318444#comment-318444
]
Lukas Theussl commented on MSITE-672:
-
This seems to be a duplicate of MSITE-135?
Interpolation of site deploy URL not done in child
--
Key: MSITE-672
URL: https://jira.codehaus.org/browse/MSITE-672
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0
Environment: Debian Linux OpenJDK 7 mvn 3.0.4
Reporter: Fred Cooke
I have my parent distribution site config filled out like so:
{{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
When the child tries to release:perform or {{site:deploy}} it tries to upload
with the parent arifactId, groupId and version instead of the current project
values. These should be interpolated like any other variables in the POM to
prevent needless duplication in all children.
--
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] (DOXIASITETOOLS-79) APT document with verbatim section including C #include causes NPE
[
https://jira.codehaus.org/browse/DOXIASITETOOLS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl reopened DOXIASITETOOLS-79:
-
APT document with verbatim section including C #include causes NPE
--
Key: DOXIASITETOOLS-79
URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-79
Project: Maven Doxia Sitetools
Issue Type: Bug
Reporter: Andy Isaacson
Assignee: Lukas Theussl
Attachments: mtest.tar.gz
A simple apt.vm document including a C program fragment in a verbatim section
causes mvn site to fail with a NPE. The failure can be worked around by
escaping the # as backslash-# but the requirement to do this is not
documented, nor AFAICS is the feature of supporting #include in verbatim
sections.
Attaching a complete testcase mtest.tar.gz.
{noformat}
% cat src/site/apt/hello.vm
#include stdio.h
int main(void) { printf(hello, world!\n); return 0; }
% mvn --version
Apache Maven 3.0.4
Maven home: /usr/share/maven
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.6.6, arch: amd64, family: unix
% mvn site
...
[WARNING] No project URL defined - decoration links will not be relativized!
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
skin.
[ERROR] Parser Exception: /tmp/mtest/src/site/apt/hello.apt.vm
[ERROR] org.apache.velocity.runtime.parser.ParseException: Encountered
\stdio.h\ at line 2, column 13.
Was expecting:
( ...
at
org.apache.velocity.runtime.parser.Parser.generateParseException(Parser.java:3360)
at
org.apache.velocity.runtime.parser.Parser.jj_consume_token(Parser.java:3237)
...
[ERROR] ResourceManager.getResource() parse exception
[ERROR] org.apache.velocity.exception.ParseErrorException: Encountered
\stdio.h\ at line 2, column 13 of /tmp/mtest/src/site/apt/hello.apt.vm
Was expecting:
( ...
at org.apache.velocity.Template.process(Template.java:137)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102)
at
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:498)
...
[ERROR] Error parsing /tmp/mtest/src/site/apt/hello.apt.vm as a velocity
template, using as text.
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.798s
[INFO] Finished at: Fri Jan 18 12:51:17 PST 2013
[INFO] Final Memory: 11M/153M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
mtest: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.0:site failed.
NullPointerException - [Help 1]
{noformat}
--
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] (DOXIASITETOOLS-79) APT document with verbatim section including C #include causes NPE
[
https://jira.codehaus.org/browse/DOXIASITETOOLS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIASITETOOLS-79.
---
Resolution: Fixed
Fix Version/s: 1.4
Converted NPE to RendererException:
[r1436769|http://svn.apache.org/viewvc?view=revisionrevision=1436769]
APT document with verbatim section including C #include causes NPE
--
Key: DOXIASITETOOLS-79
URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-79
Project: Maven Doxia Sitetools
Issue Type: Bug
Reporter: Andy Isaacson
Assignee: Lukas Theussl
Fix For: 1.4
Attachments: mtest.tar.gz
A simple apt.vm document including a C program fragment in a verbatim section
causes mvn site to fail with a NPE. The failure can be worked around by
escaping the # as backslash-# but the requirement to do this is not
documented, nor AFAICS is the feature of supporting #include in verbatim
sections.
Attaching a complete testcase mtest.tar.gz.
{noformat}
% cat src/site/apt/hello.vm
#include stdio.h
int main(void) { printf(hello, world!\n); return 0; }
% mvn --version
Apache Maven 3.0.4
Maven home: /usr/share/maven
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.6.6, arch: amd64, family: unix
% mvn site
...
[WARNING] No project URL defined - decoration links will not be relativized!
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
skin.
[ERROR] Parser Exception: /tmp/mtest/src/site/apt/hello.apt.vm
[ERROR] org.apache.velocity.runtime.parser.ParseException: Encountered
\stdio.h\ at line 2, column 13.
Was expecting:
( ...
at
org.apache.velocity.runtime.parser.Parser.generateParseException(Parser.java:3360)
at
org.apache.velocity.runtime.parser.Parser.jj_consume_token(Parser.java:3237)
...
[ERROR] ResourceManager.getResource() parse exception
[ERROR] org.apache.velocity.exception.ParseErrorException: Encountered
\stdio.h\ at line 2, column 13 of /tmp/mtest/src/site/apt/hello.apt.vm
Was expecting:
( ...
at org.apache.velocity.Template.process(Template.java:137)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102)
at
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:498)
...
[ERROR] Error parsing /tmp/mtest/src/site/apt/hello.apt.vm as a velocity
template, using as text.
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.798s
[INFO] Finished at: Fri Jan 18 12:51:17 PST 2013
[INFO] Final Memory: 11M/153M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
mtest: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.0:site failed.
NullPointerException - [Help 1]
{noformat}
--
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] (DOXIASITETOOLS-79) APT document with verbatim section including C #include causes NPE
[
https://jira.codehaus.org/browse/DOXIASITETOOLS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIASITETOOLS-79.
---
Resolution: Not A Bug
Assignee: Lukas Theussl
This only happens when you use filtering (*.vm). In this case the source file
is first piped through velocity which doesn't know anything about apt syntax,
so you have to escape the velocity special characters.
APT document with verbatim section including C #include causes NPE
--
Key: DOXIASITETOOLS-79
URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-79
Project: Maven Doxia Sitetools
Issue Type: Bug
Reporter: Andy Isaacson
Assignee: Lukas Theussl
Attachments: mtest.tar.gz
A simple apt.vm document including a C program fragment in a verbatim section
causes mvn site to fail with a NPE. The failure can be worked around by
escaping the # as backslash-# but the requirement to do this is not
documented, nor AFAICS is the feature of supporting #include in verbatim
sections.
Attaching a complete testcase mtest.tar.gz.
{noformat}
% cat src/site/apt/hello.vm
#include stdio.h
int main(void) { printf(hello, world!\n); return 0; }
% mvn --version
Apache Maven 3.0.4
Maven home: /usr/share/maven
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.6.6, arch: amd64, family: unix
% mvn site
...
[WARNING] No project URL defined - decoration links will not be relativized!
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
skin.
[ERROR] Parser Exception: /tmp/mtest/src/site/apt/hello.apt.vm
[ERROR] org.apache.velocity.runtime.parser.ParseException: Encountered
\stdio.h\ at line 2, column 13.
Was expecting:
( ...
at
org.apache.velocity.runtime.parser.Parser.generateParseException(Parser.java:3360)
at
org.apache.velocity.runtime.parser.Parser.jj_consume_token(Parser.java:3237)
...
[ERROR] ResourceManager.getResource() parse exception
[ERROR] org.apache.velocity.exception.ParseErrorException: Encountered
\stdio.h\ at line 2, column 13 of /tmp/mtest/src/site/apt/hello.apt.vm
Was expecting:
( ...
at org.apache.velocity.Template.process(Template.java:137)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:415)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102)
at
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:498)
...
[ERROR] Error parsing /tmp/mtest/src/site/apt/hello.apt.vm as a velocity
template, using as text.
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.798s
[INFO] Finished at: Fri Jan 18 12:51:17 PST 2013
[INFO] Final Memory: 11M/153M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
mtest: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.0:site failed.
NullPointerException - [Help 1]
{noformat}
--
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] (MSITE-678) Configuring Site Run example contains dead link
[
https://jira.codehaus.org/browse/MSITE-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-678.
---
Resolution: Fixed
Fix Version/s: 3.3
Assignee: Lukas Theussl
Fixed in [r1429808|http://svn.apache.org/viewvc?view=revisionrevision=1429808]
Configuring Site Run example contains dead link
---
Key: MSITE-678
URL: https://jira.codehaus.org/browse/MSITE-678
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: documentation, site:run
Affects Versions: 3.2
Reporter: Michael Osipov
Assignee: Lukas Theussl
Priority: Minor
Fix For: 3.3
Click on the link in For the {{site:run}} goal,... = 404
Check
[this|http://validator.w3.org/checklink?uri=http%3A%2F%2Fmaven.apache.org%2Fplugins%2Fmaven-site-plugin%2Fexamples%2Fsiterun.htmlsummary=onhide_type=alldepth=check=Check]
W3C link checker report.
--
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] (MPDF-41) with maven 3 pdf failure if reporting section is not empty
[ https://jira.codehaus.org/browse/MPDF-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=316766#comment-316766 ] Lukas Theussl commented on MPDF-41: --- The bug is fixed because there is no build failure anymore. The missing feature of report inclusion in m3 is tracked in MPDF-48. with maven 3 pdf failure if reporting section is not empty -- Key: MPDF-41 URL: https://jira.codehaus.org/browse/MPDF-41 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.2 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 1.2 The current mojo use removed methods in maven 3. -- 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] (MCHANGES-46) There is no link to the RSS feed of changes in the changes report
[ https://jira.codehaus.org/browse/MCHANGES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MCHANGES-46. - Resolution: Fixed Fix Version/s: 2.9 Assignee: Lukas Theussl I have [committed my own patch|http://svn.apache.org/viewvc?view=revisionrevision=1423355] after review and slight adaptations. However, I didn't do any extensive testing, so would appreciate any feedback. Use it with a configuration parameter 'feedType' with supported values: rss_0.9, rss_0.91N (RSS 0.91 Netscape), rss_0.91U (RSS 0.91 Userland), rss_0.92, rss_0.93, rss_0.94, rss_1.0, rss_2.0, atom_0.3, atom_1.0 There is no link to the RSS feed of changes in the changes report - Key: MCHANGES-46 URL: https://jira.codehaus.org/browse/MCHANGES-46 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: changes.xml Reporter: Dennis Lundberg Assignee: Lukas Theussl Fix For: 2.9 Attachments: MCHANGES-46-maven-changes-plugin.patch, MCHANGES-46.patch -- 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] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of ../
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315817#comment-315817
]
Lukas Theussl commented on MSITE-669:
-
The problem here is that the site plugin needs one top-level base url that
serves as reference for relative links of all sub-projects. The current
assumption is that this base url is the one defined in the top-level reactor
project. In your project layout this is not the case, some modules get deployed
'above' the top reactor project, i.e. 'beyond root'. So it's not the module
directory layout per se that causes the trouble, but the relative deployment
location of the sub-projects. If you can re-define the urls such that all
modules get deployed to sub-urls of the top project, everything should work.
As a fix for the site plugin, the only solution I can see for this particular
problem is to extract the actual top-level url by looping over all modules
before processing anything. However, first I would encourage you to re-think
your project layout, I would not be surprised if your setup would lead to all
kind of other troubles as well.
site:stage creates incorrect structure when module paths contains sets of
../
---
Key: MSITE-669
URL: https://jira.codehaus.org/browse/MSITE-669
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module, relative links, site:stage(-deploy)
Affects Versions: 3.1, 3.2
Reporter: Lennart Jörelid
Assignee: Lukas Theussl
Attachments: sample.zip
Given the module definitions given below, the site:stage goal produces sets
of maps relative to the staging directory - i.e. outside of the target
directory.
{code:xml}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{code}
The staged site should be fully included within the staging directory. It
would appear that relativization of links for site:stage should take special
links into consideration.
--
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] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of ../
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315829#comment-315829
]
Lukas Theussl commented on MSITE-669:
-
Some of these points are already buried in the docs:
http://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.html#Staging_and_deploying
http://maven.apache.org/plugins/maven-site-plugin/faq.html#Use_of_url
I have added your points
([r1422896|http://svn.apache.org/viewvc?view=revisionrevision=1422896]) and
fixed some wrong information in the FAQ above.
site:stage creates incorrect structure when module paths contains sets of
../
---
Key: MSITE-669
URL: https://jira.codehaus.org/browse/MSITE-669
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module, relative links, site:stage(-deploy)
Affects Versions: 3.1, 3.2
Reporter: Lennart Jörelid
Assignee: Lukas Theussl
Attachments: sample.zip
Given the module definitions given below, the site:stage goal produces sets
of maps relative to the staging directory - i.e. outside of the target
directory.
{code:xml}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{code}
The staged site should be fully included within the staging directory. It
would appear that relativization of links for site:stage should take special
links into consideration.
--
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] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of ../
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315831#comment-315831
]
Lukas Theussl commented on MSITE-669:
-
There should be no requirement wrt the relativePath element (however, in
practice I am not so sure anymore...). One problem I see is that some of your
modules inherit from parents that are not related to the rest of the project.
Eg the codestyle module has no parent, therefore its site gets staged into the
current staging dir, ie into the same dir as the nazgul-tools-reactor if the
build is started from there. The same is true for eg
nazgul-tools-validation-api which inherits from nazgul-tools-parent which has
no parent, ie its site is not related to the reactor site. The relative path
between nazgul-tools-validation-api and nazgul-tools-parent is computed as
../../ and this is appended to the base staging url of the reactor build
giving complete nonsense. I am rather confused by your project layout still but
IIUC this should be a problem specific to staging. Can you try to do a local
file deploy instead (ie indicate file:// urls as distMngmnt site urls and run
site:deploy). If this works it should also work when the site is deployed
remotely.
site:stage creates incorrect structure when module paths contains sets of
../
---
Key: MSITE-669
URL: https://jira.codehaus.org/browse/MSITE-669
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module, relative links, site:stage(-deploy)
Affects Versions: 3.1, 3.2
Reporter: Lennart Jörelid
Assignee: Lukas Theussl
Attachments: sample.zip
Given the module definitions given below, the site:stage goal produces sets
of maps relative to the staging directory - i.e. outside of the target
directory.
{code:xml}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{code}
The staged site should be fully included within the staging directory. It
would appear that relativization of links for site:stage should take special
links into consideration.
--
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] (MSITE-668) using groupId in url href should expand comonent dots . into proper path name
[
https://jira.codehaus.org/browse/MSITE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315806#comment-315806
]
Lukas Theussl commented on MSITE-668:
-
Should be closed 'Won't fix' IMO. The character replacement can be easily done
with velocity, e.g:
{noformat}
#set ( $id = $groupId.replaceAll( '.', '/' ) )
{noformat}
It would be very confusing (and simply incorrect) if the site plugin (or some
doxia macro) would do the replacement by default.
using groupId in url href should expand comonent dots . into proper path name
-
Key: MSITE-668
URL: https://jira.codehaus.org/browse/MSITE-668
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: documentation
Affects Versions: 2.3
Reporter: warren crossing
Priority: Minor
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-relationships.html
groupId
A groupId groups a set of related artifacts. Group identifiers generally
resemble a Java package name. For example, the groupId org.apache.maven is
the base groupId for all artifacts produced by the Apache Maven project.
Group identifiers are translated into paths in the Maven Repository; for
example, the org.apache.maven groupId can be found in
/maven2/org/apache/maven on repo1.maven.org.
Please help me identify where this should be done and if so and I will patch
it.
--
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] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of ../
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-669.
---
Resolution: Incomplete
Assignee: Lukas Theussl
site:stage creates incorrect structure when module paths contains sets of
../
---
Key: MSITE-669
URL: https://jira.codehaus.org/browse/MSITE-669
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module, relative links, site:stage(-deploy)
Affects Versions: 3.1, 3.2
Reporter: Lennart Jörelid
Assignee: Lukas Theussl
Given the module definitions given below, the site:stage goal produces sets
of maps relative to the staging directory - i.e. outside of the target
directory.
{code:xml}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{code}
The staged site should be fully included within the staging directory. It
would appear that relativization of links for site:stage should take special
links into consideration.
--
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] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of ../
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315332#comment-315332
]
Lukas Theussl commented on MSITE-669:
-
IIRC the module structure should be irrelevant for relative link resolution,
what counts is the distributionMngmnt.url. Did you specify correct url's in all
your sub-projects?
site:stage creates incorrect structure when module paths contains sets of
../
---
Key: MSITE-669
URL: https://jira.codehaus.org/browse/MSITE-669
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module, relative links, site:stage(-deploy)
Affects Versions: 3.1, 3.2
Reporter: Lennart Jörelid
Given the module definitions given below, the site:stage goal produces sets
of maps relative to the staging directory - i.e. outside of the target
directory.
{code:xml}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{code}
The staged site should be fully included within the staging directory. It
would appear that relativization of links for site:stage should take special
links into consideration.
--
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] (MSITE-668) using groupId in url href should expand comonent dots . into proper path name
[ https://jira.codehaus.org/browse/MSITE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315098#comment-315098 ] Lukas Theussl commented on MSITE-668: - I don't understand the issue. Can you provide an example of the current behavior vs. what you think it should be? using groupId in url href should expand comonent dots . into proper path name - Key: MSITE-668 URL: https://jira.codehaus.org/browse/MSITE-668 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: documentation Affects Versions: 2.3 Reporter: warren crossing Priority: Minor http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-relationships.html groupId A groupId groups a set of related artifacts. Group identifiers generally resemble a Java package name. For example, the groupId org.apache.maven is the base groupId for all artifacts produced by the Apache Maven project. Group identifiers are translated into paths in the Maven Repository; for example, the org.apache.maven groupId can be found in /maven2/org/apache/maven on repo1.maven.org. Please help me identify where this should be done and if so and I will patch it. -- 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] (MSITE-664) Link onclick in XDOC file swallowed/ignored by Site plugin
[ https://jira.codehaus.org/browse/MSITE-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-664. --- Resolution: Duplicate Assignee: Lukas Theussl Unfortunately there is no workaround, see DOXIA-474 and DOXIA-475. Link onclick in XDOC file swallowed/ignored by Site plugin Key: MSITE-664 URL: https://jira.codehaus.org/browse/MSITE-664 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.2 Reporter: Data Nucleus Assignee: Lukas Theussl I have a doc project (recently migrating from Maven1 site) and in Maven1 I had some javascript in the XDOC file allowing detecting click on a table column, and to impose particular actions when that happens. When I run Maven (3) site plugin it swallows the onclick on the a tag. The doc project is at https://datanucleus.svn.sourceforge.net/svnroot/datanucleus/documentation/accessplatform.datanucleus.org/branches/maven3 and its skin is at https://datanucleus.svn.sourceforge.net/svnroot/datanucleus/documentation/maven2_skins/accessplatform.datanucleus.org/trunk Any workaround to get the onclick to show up? Thanks in advance -- 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] (DOXIA-476) Doxia appends .html to file suffix when linking to a file with confluence markup
[
https://jira.codehaus.org/browse/DOXIA-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-476.
---
Resolution: Duplicate
Assignee: Lukas Theussl
Doxia appends .html to file suffix when linking to a file with confluence
markup
Key: DOXIA-476
URL: https://jira.codehaus.org/browse/DOXIA-476
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Tuukka Mustonen
Assignee: Lukas Theussl
As reported in
http://jira.codehaus.org/browse/DOXIA-298?focusedCommentId=300128page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-300128,
caused by fix of http://jira.codehaus.org/browse/DOXIA-298
Adding a link to a file with Confluence markup causes generated HTML to
always append .html to the file suffix, causing linkage to fail.
To reproduce:
{code}
Click on this [link to a file|a-powerpoint-file.ppt]
{code}
Renders as:
{code}
Click on this a href=a-powerpoint-file.ppt.htmllink to a file/a
{code}
--
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] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.
[ https://jira.codehaus.org/browse/MSITE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311433#comment-311433 ] Lukas Theussl commented on MSITE-659: - WDYM with 'only affects the site:jar goal'? The jar goal just takes the previously generated site and jars it up, but the site itself is identical to the one generated by site:site. I don't think it is a good idea to make the site:jar goal behave differently. Actually, I don't quite understand what the problem is really. If you jar up sites of different sub-modules and deploy them to the right locations then relative/absolute links don't matter. If you deploy the jars to different locations then the sites are independent and you shouldn't be using relative links in the first place. 'relativizeDecorationLinks' relativizes too much. - Key: MSITE-659 URL: https://jira.codehaus.org/browse/MSITE-659 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: relative links Affects Versions: 3.1 Reporter: Christian Schulte Attachments: MSITE-659.zip, MSITE-659.zip When relativizing links, the plugin produces relative links to content not generated by the plugin which should be kept absolute. -- 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] (MSITE-658) 'relativizeDecorationLinks' not working using multiple 'locales'.
[ https://jira.codehaus.org/browse/MSITE-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-658. --- Resolution: Fixed Fix Version/s: 3.3 Assignee: Lukas Theussl Patch applied in [r1398031|http://svn.apache.org/viewvc?view=revisionrevision=1398031] with minor modification to account for null urls, and added an IT. Thanks! 'relativizeDecorationLinks' not working using multiple 'locales'. - Key: MSITE-658 URL: https://jira.codehaus.org/browse/MSITE-658 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: relative links Affects Versions: 3.1 Reporter: Christian Schulte Assignee: Lukas Theussl Priority: Critical Fix For: 3.3 Attachments: MSITE-658.patch, MSITE-658.zip The plugin does not take into account that output will be generated to sub-directories of the location specified by the project URL for all non-default languages setup using the 'locales' parameter and produces incorrect relative links in all non-default language pages. -- 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] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.
[ https://jira.codehaus.org/browse/MSITE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311443#comment-311443 ] Lukas Theussl commented on MSITE-659: - I repeat what I said above, this is a feature not a bug :). Read http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_dont_the_links_between_parent_and_child_modules_work_when_I_run_mvn_site If you want to browse the site locally you have to use site:stage, site:jar is for deployment, in which case you should know where to put individual pieces. 'relativizeDecorationLinks' relativizes too much. - Key: MSITE-659 URL: https://jira.codehaus.org/browse/MSITE-659 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: relative links Affects Versions: 3.1 Reporter: Christian Schulte Attachments: MSITE-659-absolute.zip, MSITE-659.zip, MSITE-659.zip When relativizing links, the plugin produces relative links to content not generated by the plugin which should be kept absolute. -- 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] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.
[ https://jira.codehaus.org/browse/MSITE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311402#comment-311402 ] Lukas Theussl commented on MSITE-659: - Currently it is only possible to either relativize or not relativize *all* links, see the documentation of the [relativizeDecorationLinks|http://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#relativizeDecorationLinks] parameter. 'relativizeDecorationLinks' relativizes too much. - Key: MSITE-659 URL: https://jira.codehaus.org/browse/MSITE-659 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: relative links Affects Versions: 3.1 Reporter: Christian Schulte Attachments: MSITE-659.zip, MSITE-659.zip When relativizing links, the plugin produces relative links to content not generated by the plugin which should be kept absolute. -- 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] (MSITE-648) NoClassDefFoundError upgrading to Maven Site Plugin 3.1
[
https://jira.codehaus.org/browse/MSITE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-648:
Attachment: build.log
Log of successful build.
NoClassDefFoundError upgrading to Maven Site Plugin 3.1
---
Key: MSITE-648
URL: https://jira.codehaus.org/browse/MSITE-648
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Affects Versions: 3.1
Reporter: Ian Brandt
Attachments: build.log, MSITE-648.out
When I update from 3.0 to 3.1 I get the error below. I've reproduced it on a
couple projects, but here is a relatively simple POM that manifests the issue
when updated:
https://github.com/themadcreator/rabinfingerprint/blob/447cd065825b97e62a9b100f080ba217ba821de7/pom.xml
{noformat}
[INFO] --- maven-site-plugin:3.1:site (default-site) @ rabinfingerprint ---
Aug 12, 2012 12:35:05 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
WARNING: Error injecting:
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer
java.lang.NoClassDefFoundError: org/apache/maven/doxia/logging/Log
at java.lang.Class.getDeclaredConstructors0(Native Method)
[...]
Caused by: java.lang.ClassNotFoundException:
org.apache.maven.doxia.logging.Log
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
... 89 more
{noformat}
--
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] (DOXIA-475) Support event attributes
Lukas Theussl created DOXIA-475: --- Summary: Support event attributes Key: DOXIA-475 URL: https://jira.codehaus.org/browse/DOXIA-475 Project: Maven Doxia Issue Type: New Feature Components: Core, Sink API Affects Versions: 1.3 Reporter: Lukas Theussl Currently Doxia does not support any of the [event attributes|http://www.w3schools.com/tags/ref_eventattributes.asp], only [standard attributes|http://www.w3schools.com/tags/ref_standardattributes.asp] are recognized by the sink API. -- 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] (DOXIA-474) Onclick attribute for links gets filtered out
[ https://jira.codehaus.org/browse/DOXIA-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305715#comment-305715 ] Lukas Theussl commented on DOXIA-474: - Doxia does not support any of the [event attributes|http://www.w3schools.com/tags/ref_eventattributes.asp], only [standard attributes|http://www.w3schools.com/tags/ref_standardattributes.asp] are recognized by the sink API. This is documented in the javadocs (see e.g. [link|http://maven.apache.org/doxia/doxia/doxia-sink-api/apidocs/org/apache/maven/doxia/sink/Sink.html#link(java.lang.String, org.apache.maven.doxia.sink.SinkEventAttributes)]). Onclick attribute for links gets filtered out - Key: DOXIA-474 URL: https://jira.codehaus.org/browse/DOXIA-474 Project: Maven Doxia Issue Type: Bug Components: Module - Xdoc Affects Versions: 1.3 Environment: Maven 3.0.3, Maven Maven Site 3.1, Doxia Module Xdoc 1.3 Reporter: Angelina Velinska Priority: Blocker The link attribute onclick gets filtered out after site generation. If the following is defined in an xdoc document: p a onclick=_gaq.push(['_trackPageview', '/path/to/file']); href=./path/to/fileDownload File/a /p after site generation, it ends up to: p a href=./path/to/fileDownload File/a /p -- 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] (MPDF-57) PDF plugin creates FO file that results in fo:list-block is not a valid child element of fo:list-block
[ https://jira.codehaus.org/browse/MPDF-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=302694#comment-302694 ] Lukas Theussl commented on MPDF-57: --- Validation is not performed by default by the site plugin, it has to be switched on explicitly, see the [FAQs|http://maven.apache.org/plugins/maven-site-plugin/faq.html#Can_I_validate_xml]. Running 'mvn -Dvalidate=true site:site' on the attached project you get immediately basic validation errors (no schema definition). PDF plugin creates FO file that results in fo:list-block is not a valid child element of fo:list-block Key: MPDF-57 URL: https://jira.codehaus.org/browse/MPDF-57 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Maven 3.0.3, Linux kernel 3.3.6 Reporter: Data Nucleus Attachments: m2_pdf_plugin_proj.zip The attached project (an attempt to move to using Maven3 for site/pdf, currently using Maven1) causes [ERROR] Failed to execute goal org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf (default-cli) on project datanucleus-site: Error during document generation: Error creating PDF from /home/andy/work/datanucleus/documentation/m2_accessplatform/target/pdf/maven-pdf-plugin.fo: org.apache.fop.fo.ValidationException: file:/home/andy/work/datanucleus/documentation/m2_accessplatform/target/pdf/maven-pdf-plugin.fo:28264:175: Error(28264/175): fo:list-block is not a valid child element of fo:list-block. - [Help 1] The attached project when you run mvn clean pdf:pdf 100% reliably generates the above error. The input docs are all XDOC format. They seem to be parsed/validated ok, so am assuming there is no problem with the content (or maybe there is, but I'm not familiar with FO format to be able to spot it). -- 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] (MAVEN-1870) summary1
[ https://jira.codehaus.org/browse/MAVEN-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl deleted MAVEN-1870: - summary1 Key: MAVEN-1870 URL: https://jira.codehaus.org/browse/MAVEN-1870 Project: Maven 1 Issue Type: Bug Reporter: Alex Priority: Blocker Original Estimate: 1 day Remaining Estimate: 1 day -- 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] (MSITE-644) NullPointerException when site URL is not defined in distributionManagement
[
https://jira.codehaus.org/browse/MSITE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-644.
---
Resolution: Fixed
Fix Version/s: 3.2
Assignee: Lukas Theussl
Fixed in [r1351233|http://svn.apache.org/viewvc?view=revisionrevision=1351233]
NullPointerException when site URL is not defined in distributionManagement
---
Key: MSITE-644
URL: https://jira.codehaus.org/browse/MSITE-644
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: Samuel Langlois
Assignee: Lukas Theussl
Priority: Minor
Fix For: 3.2
Attachments: pom.xml
If you forget to specify the url in the site section:
{code}
distributionManagement
site
idalfresco.website/id
/site
/distributionManagement
{code}
you get a nasty NullPointerException.
{code}
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
alfresco: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.0:site failed.
NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
project alfresco: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.0:site failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-site of goal org.apache.maven.plugins:maven-site-plugin:3.0:site
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at java.io.File.init(File.java:222)
at
org.apache.maven.doxia.tools.DefaultSiteTool.urlEncode(DefaultSiteTool.java:1478)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDistMgmntSiteUrl(DefaultSiteTool.java:1451)
at
org.apache.maven.doxia.tools.DefaultSiteTool.appendMenuItem(DefaultSiteTool.java:1380)
at
org.apache.maven.doxia.tools.DefaultSiteTool.populateModulesMenuItemsFromModels(DefaultSiteTool.java:1344)
at
org.apache.maven.doxia.tools.DefaultSiteTool.populateModulesMenu(DefaultSiteTool.java:905)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:488)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:286)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[jira] (MSITE-644) NullPointerException when site URL is not defined in distributionManagement
[
https://jira.codehaus.org/browse/MSITE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301209#comment-301209
]
Lukas Theussl commented on MSITE-644:
-
What's the point in having a distributionManagement.site with only an id?
NullPointerException when site URL is not defined in distributionManagement
---
Key: MSITE-644
URL: https://jira.codehaus.org/browse/MSITE-644
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: Samuel Langlois
Priority: Minor
Attachments: pom.xml
If you forget to specify the url in the site section:
{code}
distributionManagement
site
idalfresco.website/id
/site
/distributionManagement
{code}
you get a nasty NullPointerException.
{code}
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
alfresco: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.0:site failed.
NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
project alfresco: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.0:site failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-site of goal org.apache.maven.plugins:maven-site-plugin:3.0:site
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at java.io.File.init(File.java:222)
at
org.apache.maven.doxia.tools.DefaultSiteTool.urlEncode(DefaultSiteTool.java:1478)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDistMgmntSiteUrl(DefaultSiteTool.java:1451)
at
org.apache.maven.doxia.tools.DefaultSiteTool.appendMenuItem(DefaultSiteTool.java:1380)
at
org.apache.maven.doxia.tools.DefaultSiteTool.populateModulesMenuItemsFromModels(DefaultSiteTool.java:1344)
at
org.apache.maven.doxia.tools.DefaultSiteTool.populateModulesMenu(DefaultSiteTool.java:905)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:488)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:286)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
{code}
You can try executing {{mvn site -N}} with the attached pom file.
--
This message is
[jira] (DOXIA-298) Confluence: Problem with relative links
[ https://jira.codehaus.org/browse/DOXIA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300140#comment-300140 ] Lukas Theussl commented on DOXIA-298: - Please open a new ticket, link back to this one and provide a concrete example to reproduce the issue. Confluence: Problem with relative links --- Key: DOXIA-298 URL: https://jira.codehaus.org/browse/DOXIA-298 Project: Maven Doxia Issue Type: Improvement Components: Module - Confluence Affects Versions: 1.1 Reporter: Kornel Assignee: Lukas Theussl Fix For: 1.1.1 Attachments: MNG-298-module-confluence.patch, MNG-298-module-confluence.patch Relative links, for example [Overview|overview/index] are not generated correctly. -- 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] (MPDF-56) Pdf generation fails when there is no site
Lukas Theussl created MPDF-56:
-
Summary: Pdf generation fails when there is no site
Key: MPDF-56
URL: https://jira.codehaus.org/browse/MPDF-56
Project: Maven 2.x PDF Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Lukas Theussl
Running pdf:pdf on a project without a site directory (i.e. only reports)
throws an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf (default-cli) on project uri:
Error during document generation: Source directory doesn't exists
{noformat}
--
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] (MPDF-56) Pdf generation fails when there is no site
[
https://jira.codehaus.org/browse/MPDF-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MPDF-56.
-
Resolution: Fixed
Fix Version/s: 1.2
Assignee: Lukas Theussl
Fixed in [r1344160|http://svn.apache.org/viewvc?view=revisionrevision=1344160]
Pdf generation fails when there is no site
--
Key: MPDF-56
URL: https://jira.codehaus.org/browse/MPDF-56
Project: Maven 2.x PDF Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
Fix For: 1.2
Running pdf:pdf on a project without a site directory (i.e. only reports)
throws an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-pdf-plugin:1.1:pdf (default-cli) on project
uri: Error during document generation: Source directory doesn't exists
{noformat}
--
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] (SUREFIRE-659) Maven PDF plugin:showSuccess=false creates empty table causing error
[ https://jira.codehaus.org/browse/SUREFIRE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed SUREFIRE-659. -- Resolution: Fixed Fix Version/s: 2.13 Assignee: Lukas Theussl Fixed in [r1338590|http://svn.apache.org/viewvc?view=revisionrevision=1338590]. Note that the issue is only relevant with Maven 2, the pdf plugin does not generate any reports with Maven 3 (MPDF-41). Maven PDF plugin:showSuccess=false creates empty table causing error Key: SUREFIRE-659 URL: https://jira.codehaus.org/browse/SUREFIRE-659 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Report Plugin Affects Versions: 2.6 Environment: maven 2.2.1, surefire 2.6, maven-pdf-plugin Reporter: Darren Hartford Assignee: Lukas Theussl Fix For: 2.13 The problem is that for showSuccess=false an empty table is written but fo expects some tableRows even if they are empty. Cheers, -Lukas Darren Hartford wrote: Hey all, Not sure where to put this issue, but using the surefire-report(2.6) with showSuccess=false, with the maven-pdf-plugin (1.1) breaks. This is using a multi-module/aggregate report approach, maven 2.2.1. With showSuccess=true, everything works fine. Basic intent is to, on a release, create an aggregate/summary PDF of the release, but some of the items. such as the surefire-report, are too verbose. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId version2.6/version configuration !-- although would prefer this, causing fo:table-body generation issues -- showSuccessfalse/showSuccess aggregatetrue/aggregate /configuration /plugin Error === [ERROR] BUILD ERROR [INFO] [INFO] Error during document generation: Error creating PDF from /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: org.apache.fop.fo.ValidationException: file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): fo:table-body is missing child elements. Required Content Model: marker* (table-row+|table-cell+) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error during document generation: Error creating PDF from /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: org.apache.fop.fo.ValidationException: file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): fo:table-body is missing child elements. Required Content Model: marker* (table-row+|table-cell+) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) 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:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during document generation: Error creating PDF from /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: org.apache.fop.fo.ValidationException: file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): fo:table-body is missing child elements. Required Content Model: marker* (table-row+|table-cell+) at org.apache.maven.plugins.pdf.PdfMojo.generatedPdf(PdfMojo.java:574) at
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=297096#comment-297096
]
Lukas Theussl commented on MSITE-604:
-
I have [added an
IT|http://svn.apache.org/viewvc?view=revisionrevision=1329606], following the
original description of the problem. It passes without your patch applied. What
am I missing?
Properties from settings.xml are not recognized in site distribution
management
Key: MSITE-604
URL: https://jira.codehaus.org/browse/MSITE-604
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0
Environment: Apache Maven 2.2.1 and 3.0.3
Reporter: Marcin Kuthan
Fix For: 3.1
Attachments: MSITE-604-maven3-2.patch, MSITE-604-maven3.patch,
MSITE-604.tgz
My distribution management section looks like:
{code}
distributionManagement
site
id${acme-corporate-pom.siteRepositoryId}/id
url${acme-corporate-pom.siteRepositoryUrl}/url
/site
/distributionManagement
{code}
Where the default property values are defined in the pom:
{code}
properties
acme-corporate-pom.siteRepositoryIdacme-site/acme-corporate-pom.siteRepositoryId
acme-corporate-pom.siteRepositoryUrlscp://sites.intranet.acme.com/var/www/acme-corporate-pom.siteRepositoryUrl
/properties
{code}
I'm able redefine properties from command line, the provided repository is
used instead default one:
{code}
mvn site:site site:deploy
-Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
-Dacme-corporate-pom.siteRepositoryId=somehost
{code}
But when I redefine properties in the profile in {{settings.xml}}, they are
ignored. The profile is activated in {{activeProfiles}} element.
It looks, than only m-site-p ignores properties defined in the
{{settings.xml}} file. m-deploy-p recognizes properties as I expected
(distribution management section for articats deployment is configured in
similar way to site deployment).
--
Marcin Kuthan
Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
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] (MSITE-619) Method calculateLink threw exception for reference $PathTool
[ https://jira.codehaus.org/browse/MSITE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl reopened MSITE-619: - Assignee: (was: Lukas Theussl) I doubt that this worked with any recent version of the site plugin. Unfortunately, the Exception message comes from the Velocity parser, so we'd have to manually check for null hrefs in the vm script. I still maintain that a href is required, so the Exception is valid, but I'd be happy to apply a patch to log a better error message. Method calculateLink threw exception for reference $PathTool Key: MSITE-619 URL: https://jira.codehaus.org/browse/MSITE-619 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3, site descriptor Affects Versions: 3.0 Environment: Maven 3.0.3, MacOS-X 10.6.8 Reporter: Oliver Boehm After running 'mvn site:site' I get the following errors after upgrading to maven-site-plugin 3.0 (with 3.0-beta-3 this error does not happen!): ... [ERROR] Method calculateLink threw exception for reference $PathTool in template org/apache/maven/doxia/siterenderer/resources/default-site.vm at [2,31] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 34.451s [INFO] Finished at: Sun Nov 20 20:29:56 CET 2011 [INFO] Final Memory: 22M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-cli) on project patterntesting-rt: Error during page generation: Error while generating code. Invocation of method 'calculateLink' in class org.codehaus.plexus.util.PathTool threw exception java.lang.NullPointerException @ org/apache/maven/doxia/siterenderer/resources/default-site.vm[2,41] - [Help 1] ... These are the POMs which are used: - http://patterntesting.cvs.sourceforge.net/viewvc/patterntesting/PatternTesting10/patterntesting-parent/pom.xml - http://patterntesting.cvs.sourceforge.net/viewvc/patterntesting/PatternTesting10/patterntesting-rt/pom.xml -- 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] (MPDF-55) Nested items in site.xml are ignored
[ https://jira.codehaus.org/browse/MPDF-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=295264#comment-295264 ] Lukas Theussl commented on MPDF-55: --- Can you attach a simple demonstration project? pdf.xml and site.xml should indeed be equally supported. Nested items in site.xml are ignored Key: MPDF-55 URL: https://jira.codehaus.org/browse/MPDF-55 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Jonas Grote Assignee: Lukas Theussl MPDF-9 is closed, but does not seem to be implemented correctly: Nested items in site.xml are being ignored. If items are nested in pdf.xml, they are being included into the pdf, though. Best regards -- 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] (MPDF-55) Nested items in site.xml are ignored
[ https://jira.codehaus.org/browse/MPDF-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPDF-55. - Resolution: Duplicate Assignee: Lukas Theussl Nested items in site.xml are ignored Key: MPDF-55 URL: https://jira.codehaus.org/browse/MPDF-55 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Jonas Grote Assignee: Lukas Theussl MPDF-9 is closed, but does not seem to be implemented correctly: Nested items in site.xml are being ignored. If items are nested in pdf.xml, they are being included into the pdf, though. Best regards -- 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] (MPDF-55) Nested items in site.xml are ignored
[ https://jira.codehaus.org/browse/MPDF-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=295190#comment-295190 ] Lukas Theussl commented on MPDF-55: --- Already tracked at MPDF-10 and documented at http://maven.apache.org/plugins/maven-pdf-plugin/limitations.html. Nested items in site.xml are ignored Key: MPDF-55 URL: https://jira.codehaus.org/browse/MPDF-55 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Jonas Grote MPDF-9 is closed, but does not seem to be implemented correctly: Nested items in site.xml are being ignored. If items are nested in pdf.xml, they are being included into the pdf, though. Best regards -- 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] (MPDF-29) Improve figure scaling
[
https://jira.codehaus.org/browse/MPDF-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl reopened MPDF-29:
---
Improve figure scaling
--
Key: MPDF-29
URL: https://jira.codehaus.org/browse/MPDF-29
Project: Maven 2.x PDF Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Lukas Theussl
Assignee: Lukas Theussl
From a private mail:
Today, I found an extremely useful tip for how to get the images/graphics
right both in HTML and PDF. As you know and write in the FAQ, there is a
challenge with scaling the images, especially when using APT.
I think it would be useful for others, if you could publish this tip on the
site for the plugin.
What I did was this:
I made a copy of the original fo-styles.xslt, names it pdf-config.xml in my
src/site/resources.
Then I replaced the following section:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=widthauto/xsl:attribute
xsl:attribute name=heightauto/xsl:attribute
xsl:attribute name=content-widthauto/xsl:attribute
xsl:attribute name=content-heightauto/xsl:attribute
/xsl:attribute-set
{code}
with this:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=content-widthscale-down-to-fit/xsl:attribute
xsl:attribute name=content-heightscale-down-to-fit/xsl:attribute
xsl:attribute name=width100%/xsl:attribute
xsl:attribute name=height100%/xsl:attribute
/xsl:attribute-set
{code}
And VOILA, the scaling was perfect!
--
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] (MPDF-29) Improve figure scaling
[
https://jira.codehaus.org/browse/MPDF-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MPDF-29.
-
Resolution: Fixed
Fix Version/s: 1.2
I changed the default behavior in doxia-module-fo, see
[r1304214|http://svn.apache.org/viewvc?view=revisionrevision=1304214]. The
documentation is complete IMO as it links to the original configuration file
where all the available parameters are listed.
Improve figure scaling
--
Key: MPDF-29
URL: https://jira.codehaus.org/browse/MPDF-29
Project: Maven 2.x PDF Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Lukas Theussl
Assignee: Lukas Theussl
Fix For: 1.2
From a private mail:
Today, I found an extremely useful tip for how to get the images/graphics
right both in HTML and PDF. As you know and write in the FAQ, there is a
challenge with scaling the images, especially when using APT.
I think it would be useful for others, if you could publish this tip on the
site for the plugin.
What I did was this:
I made a copy of the original fo-styles.xslt, names it pdf-config.xml in my
src/site/resources.
Then I replaced the following section:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=widthauto/xsl:attribute
xsl:attribute name=heightauto/xsl:attribute
xsl:attribute name=content-widthauto/xsl:attribute
xsl:attribute name=content-heightauto/xsl:attribute
/xsl:attribute-set
{code}
with this:
{code:xml}
xsl:attribute-set name=figure.graphics
xsl:attribute name=content-widthscale-down-to-fit/xsl:attribute
xsl:attribute name=content-heightscale-down-to-fit/xsl:attribute
xsl:attribute name=width100%/xsl:attribute
xsl:attribute name=height100%/xsl:attribute
/xsl:attribute-set
{code}
And VOILA, the scaling was perfect!
--
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] (JXR-58) Syntax highlighting broken for inline comments
[
https://jira.codehaus.org/browse/JXR-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed JXR-58.
Resolution: Won't Fix
Assignee: Lukas Theussl
Syntax highlighting broken for inline comments
--
Key: JXR-58
URL: https://jira.codehaus.org/browse/JXR-58
Project: Maven JXR
Issue Type: Bug
Components: jxr
Affects Versions: 2.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
For instance, for the line
{code}
out.write( text, /*preserveSpace*/ false );
{code}
the whole rest of the line after the comment will also be highlighted in
green, where only the comment should be.
--
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] (JXR-96) [PATCH] JXR Comment handling has several shortcomings
[
https://jira.codehaus.org/browse/JXR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated JXR-96:
-
Affects Version/s: (was: 2.4)
[PATCH] JXR Comment handling has several shortcomings
-
Key: JXR-96
URL: https://jira.codehaus.org/browse/JXR-96
Project: Maven JXR
Issue Type: Bug
Affects Versions: 2.3
Reporter: Matt Benson
Fix For: 2.4
Attachments: JXR-96.patch.txt
I have identified the following issues:
* a // comment does not properly mask a subsequent /* on the same line.
* explicitly tries not to terminate comments if */ is embedded in a string,
but compilers don't behave this way.
* does not handle /**/ construct properly: recognized as javadoc but not
terminated, while it is better interpreted as /*[empty]*/.
I have addressed these issues + JXR-58 by reworking the comment handling
code. Formerly the filters were applied { multiline, inline }; my version of
the code uses { ongoing-multiline, inline, begin-multiline } specifically to
address the first of the issues noted above. I was unable to find any
exhaustive tests for this code; please guide me if there is any further
testing I can provide. I have collapsed the duplicate code in these regions
as much as possible, and since this project is on maven-parent v21 I believe
I was justified in replacing the StringBuffers in affected areas with
StringBuilders (obviously the whole file might benefit minutely from this
treatment).
--
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] (JXR-96) [PATCH] JXR Comment handling has several shortcomings
[
https://jira.codehaus.org/browse/JXR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed JXR-96.
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Lukas Theussl
Patch applied in
[r1296948|http://svn.apache.org/viewvc?view=revisionrevision=1296948]. Thanks!
[PATCH] JXR Comment handling has several shortcomings
-
Key: JXR-96
URL: https://jira.codehaus.org/browse/JXR-96
Project: Maven JXR
Issue Type: Bug
Affects Versions: 2.3
Reporter: Matt Benson
Assignee: Lukas Theussl
Fix For: 2.4
Attachments: JXR-96.patch.txt
I have identified the following issues:
* a // comment does not properly mask a subsequent /* on the same line.
* explicitly tries not to terminate comments if */ is embedded in a string,
but compilers don't behave this way.
* does not handle /**/ construct properly: recognized as javadoc but not
terminated, while it is better interpreted as /*[empty]*/.
I have addressed these issues + JXR-58 by reworking the comment handling
code. Formerly the filters were applied { multiline, inline }; my version of
the code uses { ongoing-multiline, inline, begin-multiline } specifically to
address the first of the issues noted above. I was unable to find any
exhaustive tests for this code; please guide me if there is any further
testing I can provide. I have collapsed the duplicate code in these regions
as much as possible, and since this project is on maven-parent v21 I believe
I was justified in replacing the StringBuffers in affected areas with
StringBuilders (obviously the whole file might benefit minutely from this
treatment).
--
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] (MSITE-632) site from child module ignored
[
https://jira.codehaus.org/browse/MSITE-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=293177#comment-293177
]
Lukas Theussl commented on MSITE-632:
-
This looks like a duplicate of MSITE-600, did you try the latest SNAPSHOT?
site from child module ignored
Key: MSITE-632
URL: https://jira.codehaus.org/browse/MSITE-632
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0
Reporter: Kohsuke Kawaguchi
In trying to deploy
https://github.com/kohsuke/windows-package-checker/tree/4658075119d6ce9e4d6b9975342bbbef477d5f50
, I noticed that the site I specified in this POM is ignored and the one
specified in the parent is used instead. The same site deploys as expected
with Maven2 with the site plugin 2.0-beta-7.
Looking at the source code, I see that
{{SiteDeployMojo.getDeployRepositoryURL()}} uses {{getRootSite}} to determine
the site to deploy, which explains why my site definition is getting
ignored.
I believe the fix is to use the nearest site definition, not the one that's
closest to the root of the inheritance chain. That is, the {{getRootSite()}}
should be changed from:
{code}
protected Site getRootSite( MavenProject project )
throws MojoExecutionException
{
Site site = getSite( project );
MavenProject parent = project;
while ( parent.getParent() != null )
{
// MSITE-585, MNG-1943
parent = siteTool.getParentProject( parent, reactorProjects,
localRepository );
try
{
site = getSite( parent );
}
catch ( MojoExecutionException e )
{
break;
}
}
return site;
}
{code}
to
{code}
protected Site getRootSite( MavenProject project )
throws MojoExecutionException
{
Site site = getSite( project );
MavenProject parent = project;
while ( site ==null parent.getParent() != null )
{
// MSITE-585, MNG-1943
parent = siteTool.getParentProject( parent, reactorProjects,
localRepository );
try
{
site = getSite( parent );
}
catch ( MojoExecutionException e )
{
break;
}
}
return site;
}
{code}
--
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] (DOXIA-461) An incomplete fix for the resource leak bugs in LatexBookRenderer.java
[
https://jira.codehaus.org/browse/DOXIA-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292440#comment-292440
]
Lukas Theussl commented on DOXIA-461:
-
Please attach a patch instead of pasting code, see the [Guide to Developing
Maven|http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_patch].
An incomplete fix for the resource leak bugs in LatexBookRenderer.java
--
Key: DOXIA-461
URL: https://jira.codehaus.org/browse/DOXIA-461
Project: Maven Doxia
Issue Type: Bug
Components: Module - Latex
Reporter: Guangtai Liang
Priority: Critical
The fix revision 740164 was aimed to remove resource leak bugs on the
FileWriter object writer(created in line 204) and the FileReader object
reader (created in line 219) in the method writeSection()of the file
/maven/doxia/doxia/trunk/doxia-book/src/main/java/org/apache/maven/doxia/book/services/renderer/LatexBookRenderer.java
, but it is incomplete.
There are some problems:
1. the LatexBookSink object sink is not closed.
2. when the statements at lines 206-215 throw some exception, writer will
be leaked.
The best way to close such resource objects is putting such close operations
for all resource objects in the finaly block of a try-catch-finally structure.
Although a later fix (rev1003021) try to close sink, the problems still
exists in the head revision. The buggy code is copied as bellows (sink and
writer will be leaked when the statements at lines 202-207 throw some
exception):
private SectionInfo writeSection( Section section, BookContext context )
throws IOException, BookDoxiaException
{
File file = new File( context.getOutputDirectory(), ( section.getId()
+ .tex ) );
198Writer writer = WriterFactory.newWriter( file,
context.getOutputEncoding() );
200LatexBookSink sink = new LatexBookSink( writer );
BookContext.BookFile bookFile = (BookContext.BookFile)
context.getFiles().get( section.getId() );
if ( bookFile == null )
{
throw new BookDoxiaException( No document that matches section
with id=
+ section.getId() + . );
}
Reader reader = null;
try
{
reader = ReaderFactory.newReader( bookFile.getFile(),
context.getInputEncoding() );
doxia.parse( reader, bookFile.getParserId(), sink );
}
catch ( ParserNotFoundException e )
{
throw new BookDoxiaException( Parser not found:
+ bookFile.getParserId() + ., e );
}
catch ( ParseException e )
{
throw new BookDoxiaException( Error while parsing document:
+ bookFile.getFile().getAbsolutePath() + ., e );
}
catch ( FileNotFoundException e )
{
throw new BookDoxiaException( Could not find document:
+ bookFile.getFile().getAbsolutePath() + ., e );
}
finally
{
233sink.flush();
234sink.close();
236IOUtil.close( reader );
237IOUtil.close( writer );
}
SectionInfo info = new SectionInfo();
info.id = section.getId();
info.title = sink.getTitle();
return info;
}
--
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] (DOXIASITETOOLS-63) Make publish date configurable
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl moved DOXIA-458 to DOXIASITETOOLS-63: --- Fix Version/s: (was: 1.3) 1.3 Component/s: (was: Site Renderer) Site renderer Affects Version/s: (was: 1.2) 1.2 Key: DOXIASITETOOLS-63 (was: DOXIA-458) Project: Maven Doxia Sitetools (was: Maven Doxia) Make publish date configurable -- Key: DOXIASITETOOLS-63 URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-63 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site renderer Affects Versions: 1.2 Reporter: Robert Scholte Assignee: Robert Scholte Priority: Minor Fix For: 1.3 When reskinning a site, the content won't change. So the publish date shouldn't change either. A lot of people relate this date to the deployment-date. -- 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] (DOXIASITETOOLS-64) Change style for menuitems to recognize the ones with a long name
[
https://jira.codehaus.org/browse/DOXIASITETOOLS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl moved DOXIA-459 to DOXIASITETOOLS-64:
---
Fix Version/s: (was: 1.3)
1.3
Component/s: (was: Site Renderer)
Site renderer
Affects Version/s: (was: 1.2)
1.2
Key: DOXIASITETOOLS-64 (was: DOXIA-459)
Project: Maven Doxia Sitetools (was: Maven Doxia)
Change style for menuitems to recognize the ones with a long name
-
Key: DOXIASITETOOLS-64
URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-64
Project: Maven Doxia Sitetools
Issue Type: Improvement
Components: Site renderer
Affects Versions: 1.2
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Minor
Fix For: 1.3
If a menuitem has long name, it will break on spaces. So you have a menuitem
divided over two lines, but it looks like 2 separate items. By using
{{text-indent}} (see MSKINS-10) you'll recognize each item much better.
--
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] (MSITE-624) Usage page has incorrect information on the id used by site:stage-deploy
[
https://jira.codehaus.org/browse/MSITE-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-624.
---
Resolution: Fixed
Fix Version/s: 3.1
Assignee: Lukas Theussl
Fixed in [r1222599|http://svn.apache.org/viewvc?rev=1222599view=rev].
Usage page has incorrect information on the id used by site:stage-deploy
Key: MSITE-624
URL: https://jira.codehaus.org/browse/MSITE-624
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Environment:
http://maven.apache.org/plugins/maven-site-plugin/usage.html
Reporter: SebbASF
Assignee: Lukas Theussl
Fix For: 3.1
{quote}
To stage a site and to deploy it, just execute the site:stage-deploy goal
from your project with the required parameters. The site:stage-deploy goal
will use the id stagingSite for deployment. So if you need to add your
username or password in settings.xml, you should use idstagingSite/id for
that server section.
{quote}
This is incorrect; the id stagingSite is not necessarily used, see:
http://maven.apache.org/plugins/maven-site-plugin/stage-deploy-mojo.html#stagingRepositoryId
--
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] Commented: (MSITE-621) empty outputDirectory causes mvn clean to delete whole tree
[
https://jira.codehaus.org/browse/MSITE-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285202#comment-285202
]
Lukas Theussl commented on MSITE-621:
-
Shouldn't this be reported to MNG as well? If m2 does nothing and m3 removes
everything, then this is a dangerous regression IMO.
empty outputDirectory causes mvn clean to delete whole tree
---
Key: MSITE-621
URL: https://jira.codehaus.org/browse/MSITE-621
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: documentation
Affects Versions: 3.0
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600)
Maven home: D:\maven\apache-maven-3.0.3\bin\..
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: D:\j2sdk1.6.0_24\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: x86, family: windows
Reporter: Jim McCaskey
Assignee: Herve Boutemy
Fix For: 3.1
On this page:
http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Old_configuration_Maven_2__3
There is this little code snippet:
{code}
reporting
excludeDefaultstrue/excludeDefaults
outputDirectory/outputDirectory
plugins
{code}
Notice the empty outputDirectory property? Well, in Maven 2.2.1 that appears
to be ignored. In Maven 3.0.3 however, it deletes the entire project! The
documentation for this should be changed as soon as possible. We lost a bit
of work because of this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-623) lifecycle dependency failure with code generation versus javadocs versus the site plugin
[ https://jira.codehaus.org/browse/MSITE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285204#comment-285204 ] Lukas Theussl commented on MSITE-623: - Seems related to MSITE-171? lifecycle dependency failure with code generation versus javadocs versus the site plugin Key: MSITE-623 URL: https://jira.codehaus.org/browse/MSITE-623 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3 Affects Versions: 3.0 Reporter: Benson Margulies This is related to MSITE-622. In a multi-module project, one module has a plugin execution in phase 'process-classes' that produces an attached artifact (with type 'wsdl'). A second module depends on it, and has another plugin execution in phase 'generate-sources' that depends on the artifact from the first one. The second project declares this dependency. When I run site:site, it does not run compile, or process-classes, so the wsdl artifact is not in the reactor, and then the second plugin can't find it, and the build fails (and, as per -622, no explanation is shown without -X). (That's particularly odd, since it should be sitting in the local repo from a previous build.) How is something like this supposed to work? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 3.0 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=284656#comment-284656 ] Lukas Theussl commented on MSITE-600: - Please open another ticket. A test case using local file deploy will help. Thanks! site plugin 3.0 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.3, 3.0 Reporter: Benson Margulies Assignee: Lukas Theussl Fix For: 2.4, 3.1 Attachments: child-pom.xml, muddle.tar, parent-pom.xml The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-455) No XML Entity Encoding (Escaping) is done in FO Footer Generation
[
https://jira.codehaus.org/browse/DOXIA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=284132#comment-284132
]
Lukas Theussl commented on DOXIA-455:
-
Yeah, when I asked for tests I was thinking of JUnit test cases! ;)
No XML Entity Encoding (Escaping) is done in FO Footer Generation
-
Key: DOXIA-455
URL: https://jira.codehaus.org/browse/DOXIA-455
Project: Maven Doxia
Issue Type: Bug
Components: Module - FO
Affects Versions: 1.2, 1.3
Reporter: Birger Zimmermann
Assignee: Lukas Theussl
Priority: Minor
Attachments: doxia-module-fo-test.zip, patch.txt
When using an ampersand in the pom.xml organization.name e.g. Some Company
Friends the resulting fo file has xml parse errors.
Soulution seems to be:
{noformat}
### Eclipse Workspace Patch 1.0
#P doxia-module-fo
Index: src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
===
--- src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(revision 1205142)
+++ src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(working copy)
@@ -733,7 +733,7 @@
actualYear = Calendar.getInstance().get( Calendar.YEAR );
}
-return #169; + actualYear + , + companyName + add;
+return #169; + actualYear + , + escaped(companyName, false) +
add;
}
/**
@@ -826,11 +826,11 @@
if ( headerText == null )
{
-write( docTitle );
+text( docTitle );
}
else
{
-write( headerText );
+text( headerText );
}
writeEndTag( BLOCK_TAG );
@@ -927,7 +927,7 @@
atts.addAttribute( text-align-last, justify );
writeStartTag( BLOCK_TAG, atts );
writeStartTag( BASIC_LINK_TAG, internal-destination, ref );
-write( tocItem.getName() );
+text( tocItem.getName() );
writeEndTag( BASIC_LINK_TAG );
writeEmptyTag( LEADER_TAG, toc.leader.style );
writeStartTag( INLINE_TAG, page.number );
@@ -985,7 +985,7 @@
writeStartTag( BOOKMARK_TAG, internal-destination, ref );
writeStartTag( BOOKMARK_TITLE_TAG );
-write( tocItem.getName() );
+text( tocItem.getName() );
writeEndTag( BOOKMARK_TITLE_TAG );
if ( tocItem.getItems() != null )
@@ -1134,7 +1134,7 @@
writeStartTag( TABLE_CELL_TAG, number-columns-spanned, 2,
cover.border.left );
writeStartTag( BLOCK_TAG, cover.title );
-write( title == null ? : title );
+text( title == null ? : title );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
writeEndTag( TABLE_ROW_TAG );
@@ -1146,10 +1146,10 @@
writeStartTag( TABLE_CELL_TAG, number-columns-spanned, 2,
cover.border.left.bottom );
writeStartTag( BLOCK_TAG, cover.subtitle );
-write( subtitle == null ? ( version == null ? : v. + version
) : subtitle );
+text( subtitle == null ? ( version == null ? : v. + version )
: subtitle );
writeEndTag( BLOCK_TAG );
writeStartTag( BLOCK_TAG, cover.subtitle );
-write( type == null ? : type );
+text( type == null ? : type );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
writeEndTag( TABLE_ROW_TAG );
@@ -1214,7 +1214,7 @@
att.addAttribute( height, 0.3in );
att.addAttribute( text-align, left );
writeStartTag( BLOCK_TAG, att );
-write( compName == null ? ( cover.getAuthor() == null ? :
cover.getAuthor() ) : compName );
+text( compName == null ? ( cover.getAuthor() == null ? :
cover.getAuthor() ) : compName );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
@@ -1223,7 +1223,7 @@
att.addAttribute( height, 0.3in );
att.addAttribute( text-align, right );
writeStartTag( BLOCK_TAG, att );
-write( date == null ? : date );
+text( date == null ? : date );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-455) No XML Entity Encoding (Escaping) is done in FO Footer Generation
[
https://jira.codehaus.org/browse/DOXIA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated DOXIA-455:
Description:
When using an ampersand in the pom.xml organization.name e.g. Some Company
Friends the resulting fo file has xml parse errors.
Soulution seems to be:
{noformat}
### Eclipse Workspace Patch 1.0
#P doxia-module-fo
Index: src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
===
--- src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(revision 1205142)
+++ src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(working copy)
@@ -733,7 +733,7 @@
actualYear = Calendar.getInstance().get( Calendar.YEAR );
}
-return #169; + actualYear + , + companyName + add;
+return #169; + actualYear + , + escaped(companyName, false) +
add;
}
/**
@@ -826,11 +826,11 @@
if ( headerText == null )
{
-write( docTitle );
+text( docTitle );
}
else
{
-write( headerText );
+text( headerText );
}
writeEndTag( BLOCK_TAG );
@@ -927,7 +927,7 @@
atts.addAttribute( text-align-last, justify );
writeStartTag( BLOCK_TAG, atts );
writeStartTag( BASIC_LINK_TAG, internal-destination, ref );
-write( tocItem.getName() );
+text( tocItem.getName() );
writeEndTag( BASIC_LINK_TAG );
writeEmptyTag( LEADER_TAG, toc.leader.style );
writeStartTag( INLINE_TAG, page.number );
@@ -985,7 +985,7 @@
writeStartTag( BOOKMARK_TAG, internal-destination, ref );
writeStartTag( BOOKMARK_TITLE_TAG );
-write( tocItem.getName() );
+text( tocItem.getName() );
writeEndTag( BOOKMARK_TITLE_TAG );
if ( tocItem.getItems() != null )
@@ -1134,7 +1134,7 @@
writeStartTag( TABLE_CELL_TAG, number-columns-spanned, 2,
cover.border.left );
writeStartTag( BLOCK_TAG, cover.title );
-write( title == null ? : title );
+text( title == null ? : title );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
writeEndTag( TABLE_ROW_TAG );
@@ -1146,10 +1146,10 @@
writeStartTag( TABLE_CELL_TAG, number-columns-spanned, 2,
cover.border.left.bottom );
writeStartTag( BLOCK_TAG, cover.subtitle );
-write( subtitle == null ? ( version == null ? : v. + version )
: subtitle );
+text( subtitle == null ? ( version == null ? : v. + version ) :
subtitle );
writeEndTag( BLOCK_TAG );
writeStartTag( BLOCK_TAG, cover.subtitle );
-write( type == null ? : type );
+text( type == null ? : type );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
writeEndTag( TABLE_ROW_TAG );
@@ -1214,7 +1214,7 @@
att.addAttribute( height, 0.3in );
att.addAttribute( text-align, left );
writeStartTag( BLOCK_TAG, att );
-write( compName == null ? ( cover.getAuthor() == null ? :
cover.getAuthor() ) : compName );
+text( compName == null ? ( cover.getAuthor() == null ? :
cover.getAuthor() ) : compName );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
@@ -1223,7 +1223,7 @@
att.addAttribute( height, 0.3in );
att.addAttribute( text-align, right );
writeStartTag( BLOCK_TAG, att );
-write( date == null ? : date );
+text( date == null ? : date );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
{noformat}
was:
When using an ampersand in the pom.xml organization.name e.g. Some Company
Friends the resulting fo file has xml parse errors.
Soulution seems to be:
### Eclipse Workspace Patch 1.0
#P doxia-module-fo
Index: src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
===
--- src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(revision 1205142)
+++ src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(working copy)
@@ -733,7 +733,7 @@
actualYear = Calendar.getInstance().get( Calendar.YEAR );
}
-return #169; + actualYear + , + companyName + add;
+return #169; + actualYear + , + escaped(companyName, false) +
add;
}
/**
@@ -826,11 +826,11 @@
if ( headerText == null )
{
-write( docTitle );
+text( docTitle );
}
else
{
-write( headerText );
+text( headerText );
}
writeEndTag( BLOCK_TAG );
@@ -927,7 +927,7 @@
atts.addAttribute( text-align-last, justify );
[jira] Closed: (DOXIA-455) No XML Entity Encoding (Escaping) is done in FO Footer Generation
[
https://jira.codehaus.org/browse/DOXIA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-455.
---
Resolution: Not A Bug
Assignee: Lukas Theussl
The company name is a plain text element, so the ampersand has to be escaped in
the pom.xml: {code:xml}nameSome Company amp; Friends/name{code}
No XML Entity Encoding (Escaping) is done in FO Footer Generation
-
Key: DOXIA-455
URL: https://jira.codehaus.org/browse/DOXIA-455
Project: Maven Doxia
Issue Type: Bug
Components: Module - FO
Affects Versions: 1.2, 1.3
Reporter: Birger Zimmermann
Assignee: Lukas Theussl
Priority: Minor
Attachments: patch.txt
When using an ampersand in the pom.xml organization.name e.g. Some Company
Friends the resulting fo file has xml parse errors.
Soulution seems to be:
{noformat}
### Eclipse Workspace Patch 1.0
#P doxia-module-fo
Index: src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
===
--- src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(revision 1205142)
+++ src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(working copy)
@@ -733,7 +733,7 @@
actualYear = Calendar.getInstance().get( Calendar.YEAR );
}
-return #169; + actualYear + , + companyName + add;
+return #169; + actualYear + , + escaped(companyName, false) +
add;
}
/**
@@ -826,11 +826,11 @@
if ( headerText == null )
{
-write( docTitle );
+text( docTitle );
}
else
{
-write( headerText );
+text( headerText );
}
writeEndTag( BLOCK_TAG );
@@ -927,7 +927,7 @@
atts.addAttribute( text-align-last, justify );
writeStartTag( BLOCK_TAG, atts );
writeStartTag( BASIC_LINK_TAG, internal-destination, ref );
-write( tocItem.getName() );
+text( tocItem.getName() );
writeEndTag( BASIC_LINK_TAG );
writeEmptyTag( LEADER_TAG, toc.leader.style );
writeStartTag( INLINE_TAG, page.number );
@@ -985,7 +985,7 @@
writeStartTag( BOOKMARK_TAG, internal-destination, ref );
writeStartTag( BOOKMARK_TITLE_TAG );
-write( tocItem.getName() );
+text( tocItem.getName() );
writeEndTag( BOOKMARK_TITLE_TAG );
if ( tocItem.getItems() != null )
@@ -1134,7 +1134,7 @@
writeStartTag( TABLE_CELL_TAG, number-columns-spanned, 2,
cover.border.left );
writeStartTag( BLOCK_TAG, cover.title );
-write( title == null ? : title );
+text( title == null ? : title );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
writeEndTag( TABLE_ROW_TAG );
@@ -1146,10 +1146,10 @@
writeStartTag( TABLE_CELL_TAG, number-columns-spanned, 2,
cover.border.left.bottom );
writeStartTag( BLOCK_TAG, cover.subtitle );
-write( subtitle == null ? ( version == null ? : v. + version
) : subtitle );
+text( subtitle == null ? ( version == null ? : v. + version )
: subtitle );
writeEndTag( BLOCK_TAG );
writeStartTag( BLOCK_TAG, cover.subtitle );
-write( type == null ? : type );
+text( type == null ? : type );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
writeEndTag( TABLE_ROW_TAG );
@@ -1214,7 +1214,7 @@
att.addAttribute( height, 0.3in );
att.addAttribute( text-align, left );
writeStartTag( BLOCK_TAG, att );
-write( compName == null ? ( cover.getAuthor() == null ? :
cover.getAuthor() ) : compName );
+text( compName == null ? ( cover.getAuthor() == null ? :
cover.getAuthor() ) : compName );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
@@ -1223,7 +1223,7 @@
att.addAttribute( height, 0.3in );
att.addAttribute( text-align, right );
writeStartTag( BLOCK_TAG, att );
-write( date == null ? : date );
+text( date == null ? : date );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-455) No XML Entity Encoding (Escaping) is done in FO Footer Generation
[
https://jira.codehaus.org/browse/DOXIA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=284067#comment-284067
]
Lukas Theussl commented on DOXIA-455:
-
Ok, confirmed. If you could also add some tests that would be great! :)
No XML Entity Encoding (Escaping) is done in FO Footer Generation
-
Key: DOXIA-455
URL: https://jira.codehaus.org/browse/DOXIA-455
Project: Maven Doxia
Issue Type: Bug
Components: Module - FO
Affects Versions: 1.2, 1.3
Reporter: Birger Zimmermann
Assignee: Lukas Theussl
Priority: Minor
Attachments: patch.txt
When using an ampersand in the pom.xml organization.name e.g. Some Company
Friends the resulting fo file has xml parse errors.
Soulution seems to be:
{noformat}
### Eclipse Workspace Patch 1.0
#P doxia-module-fo
Index: src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
===
--- src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(revision 1205142)
+++ src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
(working copy)
@@ -733,7 +733,7 @@
actualYear = Calendar.getInstance().get( Calendar.YEAR );
}
-return #169; + actualYear + , + companyName + add;
+return #169; + actualYear + , + escaped(companyName, false) +
add;
}
/**
@@ -826,11 +826,11 @@
if ( headerText == null )
{
-write( docTitle );
+text( docTitle );
}
else
{
-write( headerText );
+text( headerText );
}
writeEndTag( BLOCK_TAG );
@@ -927,7 +927,7 @@
atts.addAttribute( text-align-last, justify );
writeStartTag( BLOCK_TAG, atts );
writeStartTag( BASIC_LINK_TAG, internal-destination, ref );
-write( tocItem.getName() );
+text( tocItem.getName() );
writeEndTag( BASIC_LINK_TAG );
writeEmptyTag( LEADER_TAG, toc.leader.style );
writeStartTag( INLINE_TAG, page.number );
@@ -985,7 +985,7 @@
writeStartTag( BOOKMARK_TAG, internal-destination, ref );
writeStartTag( BOOKMARK_TITLE_TAG );
-write( tocItem.getName() );
+text( tocItem.getName() );
writeEndTag( BOOKMARK_TITLE_TAG );
if ( tocItem.getItems() != null )
@@ -1134,7 +1134,7 @@
writeStartTag( TABLE_CELL_TAG, number-columns-spanned, 2,
cover.border.left );
writeStartTag( BLOCK_TAG, cover.title );
-write( title == null ? : title );
+text( title == null ? : title );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
writeEndTag( TABLE_ROW_TAG );
@@ -1146,10 +1146,10 @@
writeStartTag( TABLE_CELL_TAG, number-columns-spanned, 2,
cover.border.left.bottom );
writeStartTag( BLOCK_TAG, cover.subtitle );
-write( subtitle == null ? ( version == null ? : v. + version
) : subtitle );
+text( subtitle == null ? ( version == null ? : v. + version )
: subtitle );
writeEndTag( BLOCK_TAG );
writeStartTag( BLOCK_TAG, cover.subtitle );
-write( type == null ? : type );
+text( type == null ? : type );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
writeEndTag( TABLE_ROW_TAG );
@@ -1214,7 +1214,7 @@
att.addAttribute( height, 0.3in );
att.addAttribute( text-align, left );
writeStartTag( BLOCK_TAG, att );
-write( compName == null ? ( cover.getAuthor() == null ? :
cover.getAuthor() ) : compName );
+text( compName == null ? ( cover.getAuthor() == null ? :
cover.getAuthor() ) : compName );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
@@ -1223,7 +1223,7 @@
att.addAttribute( height, 0.3in );
att.addAttribute( text-align, right );
writeStartTag( BLOCK_TAG, att );
-write( date == null ? : date );
+text( date == null ? : date );
writeEndTag( BLOCK_TAG );
writeEndTag( TABLE_CELL_TAG );
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-619) Method calculateLink threw exception for reference $PathTool
[ https://jira.codehaus.org/browse/MSITE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-619. --- Resolution: Not A Bug Assignee: Lukas Theussl Method calculateLink threw exception for reference $PathTool Key: MSITE-619 URL: https://jira.codehaus.org/browse/MSITE-619 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3, site descriptor Affects Versions: 3.0 Environment: Maven 3.0.3, MacOS-X 10.6.8 Reporter: Oliver Boehm Assignee: Lukas Theussl After running 'mvn site:site' I get the following errors after upgrading to maven-site-plugin 3.0 (with 3.0-beta-3 this error does not happen!): ... [ERROR] Method calculateLink threw exception for reference $PathTool in template org/apache/maven/doxia/siterenderer/resources/default-site.vm at [2,31] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 34.451s [INFO] Finished at: Sun Nov 20 20:29:56 CET 2011 [INFO] Final Memory: 22M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-cli) on project patterntesting-rt: Error during page generation: Error while generating code. Invocation of method 'calculateLink' in class org.codehaus.plexus.util.PathTool threw exception java.lang.NullPointerException @ org/apache/maven/doxia/siterenderer/resources/default-site.vm[2,41] - [Help 1] ... These are the POMs which are used: - http://patterntesting.cvs.sourceforge.net/viewvc/patterntesting/PatternTesting10/patterntesting-parent/pom.xml - http://patterntesting.cvs.sourceforge.net/viewvc/patterntesting/PatternTesting10/patterntesting-rt/pom.xml -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-619) Method calculateLink threw exception for reference $PathTool
[ https://jira.codehaus.org/browse/MSITE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283970#comment-283970 ] Lukas Theussl commented on MSITE-619: - There is a breadcrumb without an href in your site.xml, please check if this fixes it. Note that all item elements in site.xml require a href. Method calculateLink threw exception for reference $PathTool Key: MSITE-619 URL: https://jira.codehaus.org/browse/MSITE-619 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3, site descriptor Affects Versions: 3.0 Environment: Maven 3.0.3, MacOS-X 10.6.8 Reporter: Oliver Boehm After running 'mvn site:site' I get the following errors after upgrading to maven-site-plugin 3.0 (with 3.0-beta-3 this error does not happen!): ... [ERROR] Method calculateLink threw exception for reference $PathTool in template org/apache/maven/doxia/siterenderer/resources/default-site.vm at [2,31] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 34.451s [INFO] Finished at: Sun Nov 20 20:29:56 CET 2011 [INFO] Final Memory: 22M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-cli) on project patterntesting-rt: Error during page generation: Error while generating code. Invocation of method 'calculateLink' in class org.codehaus.plexus.util.PathTool threw exception java.lang.NullPointerException @ org/apache/maven/doxia/siterenderer/resources/default-site.vm[2,41] - [Help 1] ... These are the POMs which are used: - http://patterntesting.cvs.sourceforge.net/viewvc/patterntesting/PatternTesting10/patterntesting-parent/pom.xml - http://patterntesting.cvs.sourceforge.net/viewvc/patterntesting/PatternTesting10/patterntesting-rt/pom.xml -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MECLIPSE-702) -Declipse.addVersionToProjectName=true option does not add Version to referenced project names.
[ https://jira.codehaus.org/browse/MECLIPSE-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl moved MPECLIPSE-137 to MECLIPSE-702: -- Affects Version/s: (was: 1.12) Workflow: Maven New (was: jira) Key: MECLIPSE-702 (was: MPECLIPSE-137) Project: Maven 2.x Eclipse Plugin (was: Maven 1.x Eclipse Plugin) -Declipse.addVersionToProjectName=true option does not add Version to referenced project names. --- Key: MECLIPSE-702 URL: https://jira.codehaus.org/browse/MECLIPSE-702 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Environment: java 1.6.25, Windows 7 Reporter: Jake Lee Priority: Minor When calling 'mvn eclipse:eclipse -Declipse.addVersionToProjectName=true' from a parent directory, so that all underlying projects will be created, the plugin does not add the Version to the name of projects referenced. When it is loaded into eclipse, eclipse cannot find the project with name [refrenced-project-name] even though the project is available with the name [referenced-project-name]-[version]. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-617) Variable substitution in the site url doesn't work
[
https://jira.codehaus.org/browse/MSITE-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=282581#comment-282581
]
Lukas Theussl commented on MSITE-617:
-
Did you check version 2.4-SNAPSHOT or 3.1-SNAPSHOT of the site-plugin?
Variable substitution in the site url doesn't work
--
Key: MSITE-617
URL: https://jira.codehaus.org/browse/MSITE-617
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 2.3
Environment: Windows 7 and RHEL6
Reporter: Claus Nielsen
site:deploy fails because variable substitution in the site url no longer
works (it did in version 2.2).
The distributionManagement section in out POM looks something like this:
distributionManagement
site
idsites/id
nameProject Website/name
urlscp://server/sites/${project.artifactId}/${project.version}/url
/site
/distributionManagement
Copying the site to the above mentioned url fails with this message:
[INFO] Error uploading site
Embedded error: Error performing commands for file transfer
Exit code: 1 - bash:
/sites/${project.artifactId}/${project.version}/../../id-of-the-artifact/0.2.8-SNAPSHOT:
bad substitution
Ie. the substitutiuon variables have not been substituted, instead the
property values have been appended to the url along with a few dots and
dashes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-452) AptParser ignores UTF-8 BOMs
[ https://jira.codehaus.org/browse/DOXIA-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-452: Summary: AptParser ignores UTF-8 BOMs (was: Doxia doesn't know about UTF-8 BOMs) Confirmed. AptParser ignores UTF-8 BOMs Key: DOXIA-452 URL: https://jira.codehaus.org/browse/DOXIA-452 Project: Maven Doxia Issue Type: Bug Components: Module - Apt Affects Versions: 1.2 Reporter: Benson Margulies Attachments: doxia-452.tar If an input apt doc is in UTF-8 with a BOM, the BOM passes through as noise characters inside the HTML result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-452) Doxia doesn't know about UTF-8 BOMs
[ https://jira.codehaus.org/browse/DOXIA-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=281607#comment-281607 ] Lukas Theussl commented on DOXIA-452: - How did you test this? If with the site plugin: did you set the input- and outputEncoding in the site plugin configuration? Can you provide a test case? Doxia doesn't know about UTF-8 BOMs --- Key: DOXIA-452 URL: https://jira.codehaus.org/browse/DOXIA-452 Project: Maven Doxia Issue Type: Bug Components: Module - Apt Affects Versions: 1.2 Reporter: Benson Margulies If an input apt doc is in UTF-8 with a BOM, the BOM passes through as noise characters inside the HTML result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-448) Div class attribute replicated to nested h2 element
[
https://jira.codehaus.org/browse/DOXIA-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated DOXIA-448:
Component/s: Core
Assignee: Lukas Theussl
Div class attribute replicated to nested h2 element
---
Key: DOXIA-448
URL: https://jira.codehaus.org/browse/DOXIA-448
Project: Maven Doxia
Issue Type: Bug
Components: Core, Module - Xdoc
Reporter: Simone Tripodi
Assignee: Lukas Theussl
while generating the [Apache DirectMemory
site|http://incubator.apache.org/directmemory/] using the xdoc format, I
noticed that for every {{section}} element, if {{class}} attribute is
specified, it is replicated to the nested {{h2}} element.
For example, for
{code}
section name=Apache DirectMemory class=hero-unit
pApache DirectMemory is a multi layered cache implementation
featuring off-heap memory management (a-la BigMemory)
to enable efficient handling of a large number of java objects
without affecting jvm garbage collection
performance./p
/section
{code}
Has been rendered as
{code}
div class=hero-unit
h2 class=hero-unitApache DirectMemorya
name=Apache_DirectMemory/a/h2
pApache DirectMemory is a multi layered cache implementation
featuring off-heap memory management (a-la BigMemory)
to enable efficient handling of a large number of java objects
without affecting jvm garbage collection
performance./p
/div
{code}
Of course, depending on the skin, it could cause undesired effects.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-448) Div class attribute replicated to nested h2 element
[
https://jira.codehaus.org/browse/DOXIA-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-448.
---
Resolution: Fixed
Fix Version/s: 1.3
Fixed in [r1185529|http://svn.apache.org/viewvc?view=revisionrevision=1185529]
Div class attribute replicated to nested h2 element
---
Key: DOXIA-448
URL: https://jira.codehaus.org/browse/DOXIA-448
Project: Maven Doxia
Issue Type: Bug
Components: Core, Module - Xdoc
Reporter: Simone Tripodi
Assignee: Lukas Theussl
Fix For: 1.3
while generating the [Apache DirectMemory
site|http://incubator.apache.org/directmemory/] using the xdoc format, I
noticed that for every {{section}} element, if {{class}} attribute is
specified, it is replicated to the nested {{h2}} element.
For example, for
{code}
section name=Apache DirectMemory class=hero-unit
pApache DirectMemory is a multi layered cache implementation
featuring off-heap memory management (a-la BigMemory)
to enable efficient handling of a large number of java objects
without affecting jvm garbage collection
performance./p
/section
{code}
Has been rendered as
{code}
div class=hero-unit
h2 class=hero-unitApache DirectMemorya
name=Apache_DirectMemory/a/h2
pApache DirectMemory is a multi layered cache implementation
featuring off-heap memory management (a-la BigMemory)
to enable efficient handling of a large number of java objects
without affecting jvm garbage collection
performance./p
/div
{code}
Of course, depending on the skin, it could cause undesired effects.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-451) Tweak Doxia Markdown module HTML to better match
[ https://jira.codehaus.org/browse/DOXIA-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-451. --- Resolution: Fixed Fix Version/s: 1.3 Assignee: Lukas Theussl Patch applied in [r1185539|http://svn.apache.org/viewvc?view=revisionrevision=1185539]. Thanks! Tweak Doxia Markdown module HTML to better match Key: DOXIA-451 URL: https://jira.codehaus.org/browse/DOXIA-451 Project: Maven Doxia Issue Type: Improvement Components: Module - Markdown Affects Versions: 1.3 Reporter: Brian Ferris Assignee: Lukas Theussl Fix For: 1.3 Attachments: doxia-module-markdown-HtmlSerializationStrategy.patch The Doxia Markdown module currently uses the Pegdown module to generate HTML and then relies on the Doxia xhtml module to parse that. The Pegdown HTML generation currently produces HTML that doesn't exactly match what other modules produce, which causes some style errors. Specifically, for code blocks, there is no wrapping div class=source/ wrapper, which causes output to look strange. The attached patch adjusts the output. Of course, if the markdown module is going to be refactored to produce actual Doxia AST events, that might make this less of an issue. But I still think it'd be good to commit this patch in the meantime, especially if 1.3 is released before the refactoring. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-550) site:site attributes parameter does not work
[
https://jira.codehaus.org/browse/MSITE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=281373#comment-281373
]
Lukas Theussl commented on MSITE-550:
-
After 3.0 was made to work with both maven 2 and 3, the 2.4 branch was
abandoned.
site:site attributes parameter does not work
--
Key: MSITE-550
URL: https://jira.codehaus.org/browse/MSITE-550
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: SebbASF
Assignee: Lukas Theussl
Fix For: 2.4, 3.0
Attachments: MSITE-550.zip
The site:site goal has an optional attributes parameter:
{quote}
attributes:
The template properties for rendering the site.
* Type: java.util.Map
* Required: No
* Expression: ${attributes}
{quote}
However this does not work - no parameters are created for the template.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-447) APT doesn't support specific code snippets embedded inside XML as verbatim text
[
https://jira.codehaus.org/browse/DOXIA-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-447.
---
Resolution: Not A Bug
Assignee: Lukas Theussl
This is not a bug but a documented 'feature' of Velocity, see
http://velocity.apache.org/engine/devel/user-guide.html#escapinginvalidvtlreferences
APT doesn't support specific code snippets embedded inside XML as verbatim
text
---
Key: DOXIA-447
URL: https://jira.codehaus.org/browse/DOXIA-447
Project: Maven Doxia
Issue Type: Bug
Components: Module - Apt
Reporter: Parameswaran Raman
Assignee: Lukas Theussl
Priority: Blocker
Attachments: test.apt.vm
As part of compiling documentation for our project Oozie, we require adding
XML snippets with expressions of a particular kind such as:
${wf:errorCode('wordcount')}. These expressions are known as EL functions and
they would appear at numerous places in the documentation. Unfortunately,
Doxia APT compiler is not able to parse these expressions and throws an
exception.
Following is the XML snippet desired (to be placed inside verbatim tag):
configuration
property
namemapred.job.queue.name/name
value${queueName}/value
/property
property
nameerror.message/name
valueSomething went wrong: ${wf:errorCode('wordcount')}/value
/property
/configuration
On trying to build the maven project for the site documentation,
$ mvn site
I get the following error:
--
[ERROR] org.apache.velocity.runtime.parser.ParseException: Encountered
:errorCode(\'wordcount\')}/message\n/kill/\nend
name=\'end\'/\n/workflow-app\n--\n\n
Notes:\n\n at line 134, column 44.
Was expecting one of:
} ...
DOT ...
Observations:
-
1) It appears that whenever I use any text of the format:
${wf:errorCode('wordcount')} , APT throws a parse exception (even if its
contained in the verbatim block).
2) I tried escaping the characters - {, $, :, etc.. but it doesnt work
either.
3) In general we tried the following patterns and found that:
${foo} works
${foo()} fails
${foo:bar} fails
${foo:bar()} fails
We found a workaround (that solves this issue partially), however we would
need this bug to be fixed as early as possible as it is a critical blocker in
our documentation process.
Workaround (based on response from the maven nabble forum):
---
(Source:
http://maven.40175.n5.nabble.com/APT-Issue-with-adding-xml-code-snippets-as-Verbatim-tt4831524.html#a4831572
)
I have attached a sample source file (test.apt.vm) that you can use to
reproduce the bug.
--
Thanks,
Params
parame...@gmail.com
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-449) Xdoc: content of style tag in head is swallowed
Xdoc: content of style tag in head is swallowed
---
Key: DOXIA-449
URL: https://jira.codehaus.org/browse/DOXIA-449
Project: Maven Doxia
Issue Type: Bug
Components: Core, Module - Xdoc
Reporter: Lukas Theussl
Using the following xdoc snippet
{code:xml}
head
style type=text/css
![CDATA[
h2 {
font-size: 50px;
}
]]
/style
/head
{code}
the content of the style tag is swallowed in the html output, only an empty
'style type=text/css/style' is generated.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-446) XhtmlBaseSink: problems with xdoc source attributes
[
https://jira.codehaus.org/browse/DOXIA-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-446.
---
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Lukas Theussl
Fixed in [r1182273|http://svn.apache.org/viewvc?rev=1182273view=rev]
XhtmlBaseSink: problems with xdoc source attributes
---
Key: DOXIA-446
URL: https://jira.codehaus.org/browse/DOXIA-446
Project: Maven Doxia
Issue Type: Bug
Components: Core
Affects Versions: 1.2
Reporter: Lukas Theussl
Assignee: Lukas Theussl
Fix For: 1.3
Given the xdoc snippet
{code:xml}
source class=prettysome source/source
{code}
the generated html output is
{code:xml}
div class=sourcepresome source/pre/div
{code}
ie the class attribute gets replaced. I think the correct output should be
{code:xml}
div class=sourcepre class=prettysome source/pre/div
{code}
Another problem: take
{code:xml}
source id=prettysome source/source
{code}
This gets transformed into
{code:xml}
div class=source id=prettypre id=prettysome source/pre/div
{code}
which is not valid xhtml because of the duplicate id.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-446) XhtmlBaseSink: problems with xdoc source attributes
XhtmlBaseSink: problems with xdoc source attributes
---
Key: DOXIA-446
URL: https://jira.codehaus.org/browse/DOXIA-446
Project: Maven Doxia
Issue Type: Bug
Components: Core
Affects Versions: 1.2
Reporter: Lukas Theussl
Given the xdoc snippet
{code:xml}
source class=prettysome source/source
{code}
the generated html output is
{code:xml}
div class=sourcepresome source/pre/div
{code}
ie the class attribute gets replaced. I think the correct output should be
{code:xml}
div class=sourcepre class=prettysome source/pre/div
{code}
Another problem: take
{code:xml}
source id=prettysome source/source
{code}
This gets transformed into
{code:xml}
div class=source id=prettypre id=prettysome source/pre/div
{code}
which is not valid xhtml because of the duplicate id.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-613) Regression in 3.0 - site:stage Could not resolve dependencies for project on multi-module project
[ https://jira.codehaus.org/browse/MSITE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280132#comment-280132 ] Lukas Theussl commented on MSITE-613: - Problem 1 is something I would expect, see MSITE-171. What is surprising is that it works with 3.0-beta-3, need to investigate. Problem 2 is also the expected behaviour if I understand your description correctly. Running site will put the aggregated report into target/site/cobertura/, running site:stage will put it into target/staging/localhost/home/user/mysite/cobertura/, so that cross links from within the staged site work correctly. Regression in 3.0 - site:stage Could not resolve dependencies for project on multi-module project --- Key: MSITE-613 URL: https://jira.codehaus.org/browse/MSITE-613 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: multi module Affects Versions: 3.0 Reporter: Miguel Almeida Attachments: parentA.zip Running the attached testcase, which has: parentA:| |module1 |module2 1) Run: mvn site:site 2) Run mvn site:stage 2) fails with [ERROR] Failed to execute goal on project module2: Could not resolve dependencies for project org.example:module2:jar:1.0.0-SNAPSHOT: Failure to find org.example:module1:jar:1.0.0-SNAPSHOT in http://192.178.1.120:8082/archiva/repository/my-internal/ was cached in the local repository, resolution will not be reattempted until the update interval of my-internal has elapsed or updates are forced 3) Change plugin version to 3.0-beta-3 4) Repeat 1 and 2 site:stage will run successfully -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-613) Regression in 3.0 - site:stage Could not resolve dependencies for project on multi-module project
[ https://jira.codehaus.org/browse/MSITE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280133#comment-280133 ] Lukas Theussl commented on MSITE-613: - Btw, you can work around problem 1 by running 'install' before 'site'. Regression in 3.0 - site:stage Could not resolve dependencies for project on multi-module project --- Key: MSITE-613 URL: https://jira.codehaus.org/browse/MSITE-613 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: multi module Affects Versions: 3.0 Reporter: Miguel Almeida Attachments: parentA.zip Running the attached testcase, which has: parentA:| |module1 |module2 1) Run: mvn site:site 2) Run mvn site:stage 2) fails with [ERROR] Failed to execute goal on project module2: Could not resolve dependencies for project org.example:module2:jar:1.0.0-SNAPSHOT: Failure to find org.example:module1:jar:1.0.0-SNAPSHOT in http://192.178.1.120:8082/archiva/repository/my-internal/ was cached in the local repository, resolution will not be reattempted until the update interval of my-internal has elapsed or updates are forced 3) Change plugin version to 3.0-beta-3 4) Repeat 1 and 2 site:stage will run successfully -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-604:
Fix Version/s: 3.1
Properties from settings.xml are not recognized in site distribution
management
Key: MSITE-604
URL: https://jira.codehaus.org/browse/MSITE-604
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0
Environment: Apache Maven 2.2.1 and 3.0.3
Reporter: Marcin Kuthan
Fix For: 3.1
My distribution management section looks like:
{code}
distributionManagement
site
id${acme-corporate-pom.siteRepositoryId}/id
url${acme-corporate-pom.siteRepositoryUrl}/url
/site
/distributionManagement
{code}
Where the default property values are defined in the pom:
{code}
properties
acme-corporate-pom.siteRepositoryIdacme-site/acme-corporate-pom.siteRepositoryId
acme-corporate-pom.siteRepositoryUrlscp://sites.intranet.acme.com/var/www/acme-corporate-pom.siteRepositoryUrl
/properties
{code}
I'm able redefine properties from command line, the provided repository is
used instead default one:
{code}
mvn site:site site:deploy
-Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
-Dacme-corporate-pom.siteRepositoryId=somehost
{code}
But when I redefine properties in the profile in {{settings.xml}}, they are
ignored. The profile is activated in {{activeProfiles}} element.
It looks, than only m-site-p ignores properties defined in the
{{settings.xml}} file. m-deploy-p recognizes properties as I expected
(distribution management section for articats deployment is configured in
similar way to site deployment).
--
Marcin Kuthan
Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-611) property interpolation in systemPath during site build is not working
[ https://jira.codehaus.org/browse/MSITE-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-611: Fix Version/s: 3.1 property interpolation in systemPath during site build is not working - Key: MSITE-611 URL: https://jira.codehaus.org/browse/MSITE-611 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: multi module, property interpolation Affects Versions: 3.0 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /home/marcel/apache-maven-3.0.3 Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre Default locale: de_DE, platform encoding: UTF-8 OS name: linux, version: 2.6.32-5-amd64, arch: amd64, family: unix Reporter: Marcel Patzlaff Fix For: 3.1 Attachments: output-3.0-beta-3.log, output.log, testproject.tar.gz, test-settings.xml I have specified a property in my settings.xml (see attachment test-settings.xml) that points to a directory. This property is used to specify the systemPath of a system dependency in my child module. Everything works (compilation, packaging, etc) except building the site. Calling mvn clean site on the parent project results in an error (see attachment output.log). Invoking the same line in the child project still gives the error message but the site-build itself succeeds. Please find the working project tree attached in testproject.tar.gz. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-610) No doc for reportPlugins in main goal docs
[ https://jira.codehaus.org/browse/MSITE-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-610: Fix Version/s: 3.1 Assignee: Olivier Lamy There is a rudimentary comment in AbstractSiteRenderingMojo now, but it is not clear still how to use this. Olivier: is this really supposed to be user-settable? If yes, please provide an example. No doc for reportPlugins in main goal docs -- Key: MSITE-610 URL: https://jira.codehaus.org/browse/MSITE-610 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: documentation Affects Versions: 3.0 Reporter: Benson Margulies Assignee: Olivier Lamy Fix For: 3.1 Under site:site, 'reportPlugins' is content-free. I'd recommend at least a link to the page http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-608) aggregating breadcrumb behavior disappears in the presence of a menu in the parent
[
https://jira.codehaus.org/browse/MSITE-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-608:
Fix Version/s: 3.1
aggregating breadcrumb behavior disappears in the presence of a menu in the
parent
--
Key: MSITE-608
URL: https://jira.codehaus.org/browse/MSITE-608
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 3.0
Reporter: Benson Margulies
Fix For: 3.1
Attachments: site-breadcrumb-inheritance.jar
This may turn out to belong in Doxia. I don't know.
The attached project consists of an aggregating project and its module. The
breadcrumbs in the module are, I claim, wrong -- they lack the breadcrumb to
visit the parent.
If you remove this menu:
{code}
menu name=tc
item name=Home href=index.html/
/menu
{code}
from the parent's src/site/site.xml, all is well. Once it's here, the
parent-level breadcrumb is omitted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-607) no documentation for breadcrumbs in the doc of site.xml
[ https://jira.codehaus.org/browse/MSITE-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-607: Fix Version/s: 3.1 no documentation for breadcrumbs in the doc of site.xml --- Key: MSITE-607 URL: https://jira.codehaus.org/browse/MSITE-607 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: documentation Affects Versions: 3.0 Reporter: Benson Margulies Fix For: 3.1 Some information from http://www.sonatype.com/books/mvnref-book/reference/site-generation-sect-tips-tricks.html#site-generation-add-breadcumbs should be on http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-603) ClassNotFoundException on site:site when validating XML input documents
[
https://jira.codehaus.org/browse/MSITE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-603:
Fix Version/s: 3.1
Assignee: Lukas Theussl
ClassNotFoundException on site:site when validating XML input documents
---
Key: MSITE-603
URL: https://jira.codehaus.org/browse/MSITE-603
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_20, vendor: Sun Microsystems Inc.
Default locale: en_CA, platform encoding: UTF-8
OS name: linux, version: 2.6.32-33-generic, arch: i386, family: unix
Reporter: Andreas Sewe
Assignee: Lukas Theussl
Fix For: 3.1
Attachments: testcase.tar.gz
When setting {{validate}} to {{true}} the 3.0 release of the
{{maven-site-plugin}} fails with a {{ClassNotFoundException}} (sample
project included):
{quote}
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:125)
... 20 more
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory
at
org.apache.http.impl.client.AbstractHttpClient.init(AbstractHttpClient.java:159)
at
org.apache.http.impl.client.DefaultHttpClient.init(DefaultHttpClient.java:178)
at
org.apache.maven.doxia.parser.AbstractXmlParser$CachedFileEntityResolver.toByteArray(AbstractXmlParser.java:796)
at
org.apache.maven.doxia.parser.AbstractXmlParser$CachedFileEntityResolver.resolveEntity(AbstractXmlParser.java:738)
at org.apache.xerces.util.EntityResolverWrapper.resolveEntity(Unknown
Source)
at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown
Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.apache.maven.doxia.util.XmlValidator.validate(XmlValidator.java:108)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.validate(DefaultSiteRenderer.java:831)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:365)
at
org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Caused by: java.lang.ClassNotFoundException:
org.apache.commons.logging.LogFactory
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
... 47 more
{quote}
This problem only shows up if there are XML input documents (FML, XDoc)
present to be validated.
It doesn't occur with 3.0-beta-3 instead of 3.0.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-602) The staged site is deployed to the wrong place
[
https://jira.codehaus.org/browse/MSITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-602:
Fix Version/s: 3.1
The staged site is deployed to the wrong place
--
Key: MSITE-602
URL: https://jira.codehaus.org/browse/MSITE-602
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 2.3, 3.0
Reporter: Dennis Lundberg
Assignee: Dennis Lundberg
Fix For: 3.1
When running 'mvn site:stage-deploy' the site is deployed to the wrong place.
Below is the output from a test run performed on the Checkstyle Plugin
project.
{noformat}
[INFO] --- maven-site-plugin:3.0:stage-deploy (default-cli) @
maven-checkstyle-plugin ---
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT
[INFO] Parent project loaded from repository:
org.apache.maven.plugins:maven-plugins:pom:21
[INFO] Parent project loaded from repository:
org.apache.maven:maven-parent:pom:20
[INFO] Parent project loaded from repository: org.apache:apache:pom:9
: Keyboard interactive required, supplied password is ignored
Password: :
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
- Session: Opened
[INFO] Pushing
G:\apache\maven\trunks\plugins\maven-checkstyle-plugin\target\site
[INFO] to
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin
Executing command: mkdir -p
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin
Executing command: mkdir -p
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin
Executing command: scp -t
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/wagon592489540427231356.zip
Uploading: plugins/maven-checkstyle-plugin/wagon592489540427231356.zip to
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
###
Transfer finished. 224640 bytes copied in 1.699 seconds
Executing command: cd
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin;
unzip -q -o wagon592489540427231356.zip; rm -f wagon592489540427231356.zip
Executing command: chmod -Rf g+w,a+rX
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
- Session: Disconnecting
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
- Session: Disconnected
{noformat}
Notice how it gets deployed to
{noformat}
/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/
{noformat}
instead of
{noformat}
/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-601) Period added to URL prevents proper cloning with Mercurial
[
https://jira.codehaus.org/browse/MSITE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-601:
Fix Version/s: 3.1
Period added to URL prevents proper cloning with Mercurial
--
Key: MSITE-601
URL: https://jira.codehaus.org/browse/MSITE-601
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0-beta-3
Environment: Javac 7 on Fedora Linux 15, Mercurial 1.9
Reporter: Leon Blakey
Priority: Critical
Fix For: 3.1
I deploy my Maven site over Mercurial on Google Code. I use this configuration
{code:xml}distributionManagement
!--Site deploy repository--
site
idMYPROJECT.googlecode.com/id
urlscm:hg:https://code.google.com/p/MYPROJECT.site//url
/site
/distributionManagement{code}
And a standard server in settings.xml
{code:xml}servers
server
idMYPROJECT.googlecode.com/id
usernameUSERNAME/username
passwordPASSWORD/password
/server
/servers{code}
However when running site:deploy it decides that it should add a dot to the
URL, meaning it tries to execute this command
EXECUTING: /bin/sh -c cd /tmp hg clone -r tip
https://USERNAME:passw...@code.google.com/p/MYPROJECT.site//.
/tmp/wagon-scm1348091978.checkout
Which on Google and other repositories gives a 404 since the file . (look at
the end of the URL) doesn't exist. Why is that period there? Is it coming
from Maven Site or the Mercurial plugin (I'm assuming here)? Can it get
removed
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 3.0 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280015#comment-280015 ] Lukas Theussl commented on MSITE-600: - Jenkins seems happy now, so I'm closing this. I also merged the fix back to the 2.4 branch ([r1176233|http://svn.apache.org/viewvc?rev=1176233view=rev]) and deployed a snapshot, if someone wants to test. site plugin 3.0 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.3, 3.0 Reporter: Benson Margulies Assignee: Lukas Theussl Fix For: 2.4, 3.1 Attachments: child-pom.xml, muddle.tar, parent-pom.xml The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-600) site plugin 3.0 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-600. --- Resolution: Fixed site plugin 3.0 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.3, 3.0 Reporter: Benson Margulies Assignee: Lukas Theussl Fix For: 3.1 Attachments: child-pom.xml, muddle.tar, parent-pom.xml The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-600) site plugin 3.0 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-600: Fix Version/s: 2.4 site plugin 3.0 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.3, 3.0 Reporter: Benson Margulies Assignee: Lukas Theussl Fix For: 2.4, 3.1 Attachments: child-pom.xml, muddle.tar, parent-pom.xml The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-596) inheritedReports IT fails
[ https://jira.codehaus.org/browse/MSITE-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-596: Fix Version/s: 3.1 If this cannot get fixed for 3.1, we need to document the different behaviour. inheritedReports IT fails - Key: MSITE-596 URL: https://jira.codehaus.org/browse/MSITE-596 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: inheritance, Maven 3 Affects Versions: 3.0-beta-3 Reporter: Herve Boutemy Fix For: 3.1 as discovered in MSITE-595: - with M2, each report is added: child has 2 reports generated = index+summary - with M3, each report replaces previous one: child has 1 report = summary What is the expected behaviour? I'd say M2 is buggy, since POM inheritance logic usually replaces instead adding Should we try to stick with M2 behaviour? (if feasible, I still didn't check) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-607) no documentation for breadcrumbs in the doc of site.xml
[ https://jira.codehaus.org/browse/MSITE-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-607. --- Resolution: Fixed Assignee: Lukas Theussl Done in [r1176301|http://svn.apache.org/viewvc?rev=1176301view=rev]. no documentation for breadcrumbs in the doc of site.xml --- Key: MSITE-607 URL: https://jira.codehaus.org/browse/MSITE-607 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: documentation Affects Versions: 3.0 Reporter: Benson Margulies Assignee: Lukas Theussl Fix For: 3.1 Some information from http://www.sonatype.com/books/mvnref-book/reference/site-generation-sect-tips-tricks.html#site-generation-add-breadcumbs should be on http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-603) ClassNotFoundException on site:site when validating XML input documents
[
https://jira.codehaus.org/browse/MSITE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280040#comment-280040
]
Lukas Theussl commented on MSITE-603:
-
This was introduced with
[r991009|http://svn.apache.org/viewvc?view=revisionrevision=991009], not sure
why the commons-logging exclusion was needed.
ClassNotFoundException on site:site when validating XML input documents
---
Key: MSITE-603
URL: https://jira.codehaus.org/browse/MSITE-603
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_20, vendor: Sun Microsystems Inc.
Default locale: en_CA, platform encoding: UTF-8
OS name: linux, version: 2.6.32-33-generic, arch: i386, family: unix
Reporter: Andreas Sewe
Assignee: Lukas Theussl
Fix For: 3.1
Attachments: testcase.tar.gz
When setting {{validate}} to {{true}} the 3.0 release of the
{{maven-site-plugin}} fails with a {{ClassNotFoundException}} (sample
project included):
{quote}
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:125)
... 20 more
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory
at
org.apache.http.impl.client.AbstractHttpClient.init(AbstractHttpClient.java:159)
at
org.apache.http.impl.client.DefaultHttpClient.init(DefaultHttpClient.java:178)
at
org.apache.maven.doxia.parser.AbstractXmlParser$CachedFileEntityResolver.toByteArray(AbstractXmlParser.java:796)
at
org.apache.maven.doxia.parser.AbstractXmlParser$CachedFileEntityResolver.resolveEntity(AbstractXmlParser.java:738)
at org.apache.xerces.util.EntityResolverWrapper.resolveEntity(Unknown
Source)
at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown
Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.apache.maven.doxia.util.XmlValidator.validate(XmlValidator.java:108)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.validate(DefaultSiteRenderer.java:831)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:365)
at
org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Caused by: java.lang.ClassNotFoundException:
org.apache.commons.logging.LogFactory
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
... 47 more
{quote}
This problem only shows up if there are XML input documents (FML, XDoc)
present to be validated.
It doesn't occur with 3.0-beta-3 instead of 3.0.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-603) ClassNotFoundException on site:site when validating XML input documents
[
https://jira.codehaus.org/browse/MSITE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-603.
---
Resolution: Fixed
Fixed: [r1176337|http://svn.apache.org/viewvc?rev=1176337view=rev]
ClassNotFoundException on site:site when validating XML input documents
---
Key: MSITE-603
URL: https://jira.codehaus.org/browse/MSITE-603
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_20, vendor: Sun Microsystems Inc.
Default locale: en_CA, platform encoding: UTF-8
OS name: linux, version: 2.6.32-33-generic, arch: i386, family: unix
Reporter: Andreas Sewe
Assignee: Lukas Theussl
Fix For: 3.1
Attachments: testcase.tar.gz
When setting {{validate}} to {{true}} the 3.0 release of the
{{maven-site-plugin}} fails with a {{ClassNotFoundException}} (sample
project included):
{quote}
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:125)
... 20 more
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory
at
org.apache.http.impl.client.AbstractHttpClient.init(AbstractHttpClient.java:159)
at
org.apache.http.impl.client.DefaultHttpClient.init(DefaultHttpClient.java:178)
at
org.apache.maven.doxia.parser.AbstractXmlParser$CachedFileEntityResolver.toByteArray(AbstractXmlParser.java:796)
at
org.apache.maven.doxia.parser.AbstractXmlParser$CachedFileEntityResolver.resolveEntity(AbstractXmlParser.java:738)
at org.apache.xerces.util.EntityResolverWrapper.resolveEntity(Unknown
Source)
at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown
Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.apache.maven.doxia.util.XmlValidator.validate(XmlValidator.java:108)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.validate(DefaultSiteRenderer.java:831)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:365)
at
org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Caused by: java.lang.ClassNotFoundException:
org.apache.commons.logging.LogFactory
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
... 47 more
{quote}
This problem only shows up if there are XML input documents (FML, XDoc)
present to be validated.
It doesn't occur with 3.0-beta-3 instead of 3.0.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-602) The staged site is deployed to the wrong place
[
https://jira.codehaus.org/browse/MSITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280044#comment-280044
]
Lukas Theussl commented on MSITE-602:
-
I will review this, there might be an easier fix. It would help to have a test
case as none of our ITs have caught this.
The staged site is deployed to the wrong place
--
Key: MSITE-602
URL: https://jira.codehaus.org/browse/MSITE-602
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 2.3, 3.0
Reporter: Dennis Lundberg
Assignee: Dennis Lundberg
Fix For: 3.1
When running 'mvn site:stage-deploy' the site is deployed to the wrong place.
Below is the output from a test run performed on the Checkstyle Plugin
project.
{noformat}
[INFO] --- maven-site-plugin:3.0:stage-deploy (default-cli) @
maven-checkstyle-plugin ---
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT
[INFO] Parent project loaded from repository:
org.apache.maven.plugins:maven-plugins:pom:21
[INFO] Parent project loaded from repository:
org.apache.maven:maven-parent:pom:20
[INFO] Parent project loaded from repository: org.apache:apache:pom:9
: Keyboard interactive required, supplied password is ignored
Password: :
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
- Session: Opened
[INFO] Pushing
G:\apache\maven\trunks\plugins\maven-checkstyle-plugin\target\site
[INFO] to
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin
Executing command: mkdir -p
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin
Executing command: mkdir -p
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin
Executing command: scp -t
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/wagon592489540427231356.zip
Uploading: plugins/maven-checkstyle-plugin/wagon592489540427231356.zip to
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
###
Transfer finished. 224640 bytes copied in 1.699 seconds
Executing command: cd
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin;
unzip -q -o wagon592489540427231356.zip; rm -f wagon592489540427231356.zip
Executing command: chmod -Rf g+w,a+rX
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
- Session: Disconnecting
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
- Session: Disconnected
{noformat}
Notice how it gets deployed to
{noformat}
/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/
{noformat}
instead of
{noformat}
/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-600) site plugin 3.0 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-600: Summary: site plugin 3.0 does not permit a child to fully override parent site deployment URL (was: site plugin 2.4 does not permit a child to fully override parent site deployment URL) site plugin 3.0 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.3, 3.0 Reporter: Benson Margulies Assignee: Lukas Theussl Fix For: 3.1 Attachments: child-pom.xml, muddle.tar, parent-pom.xml The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 2.4 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=279754#comment-279754 ] Lukas Theussl commented on MSITE-600: - I committed a fix that works for me locally (but I expect problems on Windows which I can't test): [r1174614|http://svn.apache.org/viewvc?rev=1174614view=rev]. 3.1-SNAPSHOT is deployed, any feedback appreciated. site plugin 2.4 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.3, 3.0 Reporter: Benson Margulies Assignee: Lukas Theussl Fix For: 3.1 Attachments: child-pom.xml, muddle.tar, parent-pom.xml The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-208) DefaultSiteTool.getRelativePath does not work between files
DefaultSiteTool.getRelativePath does not work between files
---
Key: MSHARED-208
URL: https://jira.codehaus.org/browse/MSHARED-208
Project: Maven Shared Components
Issue Type: Bug
Components: maven-doxia-tools
Affects Versions: maven-doxia-tools-1.4
Reporter: Lukas Theussl
See test case committed in
[r1174674|http://svn.apache.org/viewvc?rev=1174674view=rev]. Given
{code}
to = http://maven.apache.org/downloads.html;;
from = http://maven.apache.org/index.html;;
{code}
getRelativePath( to, from ) returns ../downloads.html instead of
downloads.html. It seems like the 'from' parameter is always supposed to be a
directory. That's confusing and not very useful, also the
[javadocs|http://maven.apache.org/shared/maven-doxia-tools/apidocs/org/apache/maven/doxia/tools/SiteTool.html#getRelativePath%28java.lang.String,%20java.lang.String%29]
state that the method should 'Calculate the relative path between two URLs or
between two files.'.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
