from:"Lukas Theussl $JIRA$"

[jira] Closed: (MPIR-189) Allow configuration of mailing list header text.

2010-06-16 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPIR-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPIR-189.
--

Resolution: Fixed

Please do not re-open issues that have been marked as fixed in released 
versions. Open a new issue instead.

 Allow configuration of mailing list header text.
 

 Key: MPIR-189
 URL: http://jira.codehaus.org/browse/MPIR-189
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: mailing-list
Reporter: SebbASF
Assignee: Olivier Lamy
 Fix For: 2.2


 The generated mailing list report has a header which provides basic info on 
 the page.
 However, in some cases this information is not enough.
 For example, some lists may not allow posting; it would be useful to be able 
 to explain why.
 In the case of Apache Commons, the lists are shared, so users need to add a 
 prefix to the subject line.
 There are no doubt other use cases.
 It would be useful to be able to override the introduction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-395) Add sink.script

2010-06-07 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-395.
---

Resolution: Won't Fix
  Assignee: Lukas Theussl

This should be achieved with the unknown sink even, available since Doxia 1.1. 
The XhtmlSink should understand something like

{code}
Object[] required = new Object[] { new Integer( HtmlMarkup.TAG_TYPE_SIMPLE ) };
SinkEventAttributeSet attribs = new SinkEventAttributeSet(new String[] {type, 
text/javascript,src, http://www.google.com/jsapi});
sink.unknown( HtmlMarkup.SCRIPT.toString(), required, attribs );
{code}

 Add sink.script
 ---

 Key: DOXIA-395
 URL: http://jira.codehaus.org/browse/DOXIA-395
 Project: Maven Doxia
  Issue Type: Wish
  Components: Sink API
Reporter: qualitesys
Assignee: Lukas Theussl

 For some particular use, would be nice to insert javascript, in the head 
 part for example :
 script type=text/javascript src=http://www.google.com/jsapi;/script
 A sink.script(String text) is enough

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MPDF-29) Improve figure scaling

2010-06-07 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPDF-29.
-

   Resolution: Not A Bug
Fix Version/s: (was: 1.2)
 Assignee: Lukas Theussl

This tip is already published: 
http://maven.apache.org/plugins/maven-pdf-plugin/usage.html (Specific FOP 
Configuration Properties).

 Improve figure scaling
 --

 Key: MPDF-29
 URL: http://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 contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-394) Transitive dependency to old commons-logging through HttpClient causes problems

2010-06-04 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=224055#action_224055
 ] 

Lukas Theussl commented on DOXIA-394:
-

This patch makes the fml module test fail.

 Transitive dependency to old commons-logging through HttpClient causes 
 problems
 ---

 Key: DOXIA-394
 URL: http://jira.codehaus.org/browse/DOXIA-394
 Project: Maven Doxia
  Issue Type: Bug
  Components: Maven plugin
Affects Versions: 1.1.3
Reporter: isabel drost
 Attachments: DOXIA-394.diff


 The issue (and resulting trouble) is described in more detail over in the 
 MSITE issue tracker: http://jira.codehaus.org/browse/MSITE-459
 Excluding the dependency entirely solved the problem for me. See attached 
 diff for the changes I made.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MPIR-194) [WARNING] Deprecated API called

2010-06-04 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MPIR-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=224069#action_224069
 ] 

Lukas Theussl commented on MPIR-194:


You have to use site-plugin-2.1, see eg 
http://www.mail-archive.com/us...@maven.apache.org/msg109240.html

 [WARNING] Deprecated API called
 ---

 Key: MPIR-194
 URL: http://jira.codehaus.org/browse/MPIR-194
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Lukas Theussl
Priority: Minor

 Version 2.2 spits out a warning for each generated page:
 {noformat}
 [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink 
 instance and no SinkFactory available. Please update this plugin.
 {noformat}
 The warning can be ignored AFAICT but it is annoying and confusing for users.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-456) [regression] Site navigation not generated

2010-06-04 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=224079#action_224079
 ] 

Lukas Theussl commented on MSITE-456:
-

Your link does not exist and it does not work is hard to diagnose. Please 
give us a chance and be more specific.

 [regression] Site navigation not generated
 --

 Key: MSITE-456
 URL: http://jira.codehaus.org/browse/MSITE-456
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
 Java version: 1.6.0_16
 Java home: d:\jdk1.6.0_16\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Paul Benedict
Assignee: Dennis Lundberg
Priority: Critical
 Fix For: 2.1.1, 3.0-alpha-1

 Attachments: MSITE-456.zip


 My corporate POM locks down the maven-site-plugin to version 2.1. The site of 
 the corporate POM generates just fine. However, when a child project inherits 
 from it, that project's site contains no left-hand navigation. Reverting to 
 2.0.1 is my workaround.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MPDF-29) Improve figure scaling

2010-06-04 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MPDF-29:
--

Fix Version/s: 1.2

 Improve figure scaling
 --

 Key: MPDF-29
 URL: http://jira.codehaus.org/browse/MPDF-29
 Project: Maven 2.x PDF Plugin
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: 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 contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MPDF-32) PDF generation fails due to velocity template error

2010-06-04 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MPDF-32:
--

Fix Version/s: 1.2

 PDF generation fails due to velocity template error
 ---

 Key: MPDF-32
 URL: http://jira.codehaus.org/browse/MPDF-32
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Maven 2.0.10 JDK6, XP SP3
Reporter: Michael Osipov
 Fix For: 1.2

 Attachments: pdf.log


 I was trying to run mvn pdf:pdf and it suddenly failed. See attached log. The 
 failing template works flawlessly with the site goal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Moved: (MPIR-196) Add a DateBuilt field to the Build Information section of the Project Summary page

2010-06-03 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPIR-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl moved MSITE-485 to MPIR-196:
--

Affects Version/s: (was: 2.1)
   2.2
  Key: MPIR-196  (was: MSITE-485)
  Project: Maven 2.x Project Info Reports Plugin  (was: Maven 2.x 
Site Plugin)

 Add a DateBuilt field to the Build Information section of the Project Summary 
 page
 --

 Key: MPIR-196
 URL: http://jira.codehaus.org/browse/MPIR-196
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: William Ferguson

 One of the biggest problems (IMHO) when looking at project documentation is 
 the inability to readily determine the age of a component or the age age of 
 the documentation. Such information is often sued to make a decision on how 
 relevant a new component might be.
 The Project Summary page generated by the Site plugin contains a Build 
 Information section.
 This section identifies the GroupId, ArtifactId, Version, and Type. 
 If it also published the DateTime at which a component was built then it 
 solve the problem above.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MSITE-440) Site document validation fails if unable to retrieve schema (in offline mode)

2010-06-01 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/MSITE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Lukas Theussl closed MSITE-440.
---

Resolution: Fixed
Assignee: Lukas Theussl

I consider this fixed with MSITE-474 since no more exception occurs. Current
drawback is that validation is not possible in off-line mode, but that's
another issue.

Site document validation fails if unable to retrieve schema (in offline mode)
-

Key: MSITE-440
URL: http://jira.codehaus.org/browse/MSITE-440
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: doxia integration
Affects Versions: 2.1
Environment: Maven 2.2.1
Site Plugin 2.1-SNAPSHOT
Doxia 1.1.2
Reporter: Dave Meibusch
Assignee: Lukas Theussl
Priority: Critical
Fix For: 2.1.1

The changes included DOXIA-263 to validate XML documents retrieves the
DTD/Schema to validate the document.
For example, for FML, xsi:schemaLocation=http://maven.apache.org/FML/1.0.1
http://maven.apache.org/xsd/fml-1.0.1.xsd; the Doxia FML parser will retrieve
http://maven.apache.org/xsd/fml-1.0.1.xsd before validating the document.
If in offline mode, or in an environment without connectivity to apache.org,
site generation will appear to hang until the HTTP client code times out
(which is many minutes for each retry) then fail.
Workaround: remove the schema definition from the document (and lose
validation when online and IDE editing support).
Perhaps each Doxia parser should have some embedded schemas (for FML, at
least http://maven.apache.org/FML/1.0.1) so the entities can be resolved
locally.
Or at least a property for disabling document validation.
I don't think v2.1 can be released with this issue unresolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MSITE-440) Site generation fails if unable to retrieve schema (in offline mode)

2010-06-01 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MSITE-440:


Summary: Site generation fails if unable to retrieve schema (in offline 
mode)  (was: Site document validation fails if unable to retrieve schema (in 
offline mode))

 Site generation fails if unable to retrieve schema (in offline mode)
 

 Key: MSITE-440
 URL: http://jira.codehaus.org/browse/MSITE-440
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: doxia integration
Affects Versions: 2.1
 Environment: Maven 2.2.1
 Site Plugin 2.1-SNAPSHOT
 Doxia 1.1.2
Reporter: Dave Meibusch
Assignee: Lukas Theussl
Priority: Critical
 Fix For: 2.1.1


 The changes included DOXIA-263 to validate XML documents retrieves the 
 DTD/Schema to validate the document.
 For example, for FML, xsi:schemaLocation=http://maven.apache.org/FML/1.0.1 
 http://maven.apache.org/xsd/fml-1.0.1.xsd; the Doxia FML parser will retrieve 
 http://maven.apache.org/xsd/fml-1.0.1.xsd before validating the document.
 If in offline mode, or in an environment without connectivity to apache.org, 
 site generation will appear to hang until the HTTP client code times out 
 (which is many minutes for each retry) then fail.
 Workaround: remove the schema definition from the document (and lose 
 validation when online and IDE editing support).
 Perhaps each Doxia parser should have some embedded schemas (for FML, at 
 least http://maven.apache.org/FML/1.0.1) so the entities can be resolved 
 locally.
 Or at least a property for disabling document validation.
 I don't think v2.1 can be released with this issue unresolved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MSITE-483) Site validation fails in off-line mode

2010-06-01 Thread Lukas Theussl (JIRA)

Site validation fails in off-line mode
--

 Key: MSITE-483
 URL: http://jira.codehaus.org/browse/MSITE-483
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Lukas Theussl


By itself this is not necessarily an issue since we could require access to 
on-line schemas or DTDs for validation. The problem is that in the current 
implementation any entities are resolved by the validation run. So if you want 
to use entities (even if locally defined) you *have* to switch on validation 
and this will fail in off-line mode.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-393) Unable to deploy site for fml and xdoc modules

2010-05-28 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222953#action_222953
 ] 

Lukas Theussl commented on DOXIA-393:
-

I deployed without problems to a local directory. However, the directory it 
tries to create in your case looks weird. Those tasks are executed by the 
antrun plugin in the xdoc and fml poms, I don't think it has anything to do 
specificly with xsddoc.

 Unable to deploy site for fml and xdoc modules
 --

 Key: DOXIA-393
 URL: http://jira.codehaus.org/browse/DOXIA-393
 Project: Maven Doxia
  Issue Type: Bug
  Components: Module - Fml, Module - Xdoc
Affects Versions: 1.1.3
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
 Java version: 1.5.0_22
 Java home: C:\Program\Java\jdk1.5.0_22\jre
 Default locale: sv_SE, platform encoding: Cp1252
 OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Dennis Lundberg

 When trying to deploy the site for version 1.1.3  I get the following failure 
 in the FML and XDoc modules. It seems to have something to do with xsddoc.
 Command line is:
 mvn site-deploy -Preporting -e
 {noformat}
 [INFO] Generating Surefire Report report.
 [INFO] [antrun:run {execution: default}]
 [INFO] Executing tasks
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] An Ant BuildException has occured: Directory 
 G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
  creation was not successful for an unknown reason
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: An Ant BuildException 
 has occured: Directory 
 G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
  creation was not successful for an unknown reason
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
 at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
 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:592)
 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: An Ant 
 BuildException has occured: Directory 
 G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
  creation was not successful for an unknown reason
 at 
 org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:131)
 at 
 org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
 ... 17 more
 Caused by: Directory 
 G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\G:\apache\maven\trunks\doxia\doxia\target\checkout\doxia-modules\doxia-module-fml\target\site\xsddoc
  creation was not

[jira] Updated: (MSITE-227) site:deploy - wrong links in ${modules} when artifactId=module's directory

2010-05-27 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MSITE-227:


Attachment: MSITE-227-working.zip

The workaround is to specify a {{url}} element for all modules and the 
parent. See attached working test project. Actually I am not sure if this 
should be called a workaround or the proper solution, I didn't find any docs on 
it.

Note that with published site-plugin-2.1 the links are ok as well but the 
modules sites suffer from MSITE-456, which is fixed in 2.1.1-SNAPSHOT.


 site:deploy - wrong links in ${modules} when artifactId=module's directory
 ---

 Key: MSITE-227
 URL: http://jira.codehaus.org/browse/MSITE-227
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: multi module
Affects Versions: 2.0-beta-5, 2.0
 Environment: Eclipse IDE
Reporter: Guimiot Isabelle
 Attachments: MSITE-227-working.zip, MSITE-227.zip


 I have a problem in the ${modules} part when I run the site:deploy goal.
 my project contains a root module and 2 sub-modules, at the same directory 
 depth (I'm using Eclipse) :
 workspace/myRoot/
 workspace/myModule1/
 workspace/myModule2/
 my root pom contains this module declaration :
 modules
   module../myModule1/module
   module../myModule1/module
 /modules
 the site:deploy goal gives this structure :
 [deploydir]/myRoot/index.html -- root's index
 [deploydir]/myRoot/myModule1/index.html -- first module's index
 [deploydir]/myRoot/myModule2/index.html -- second module's index
 when the project name (directory name in the workspace) and the artifactId 
 are exactly the same, I have wrong links, both in root and in sub-modules 
 pages :
 - in the root page, my links to submodules are like this :
 h5Modules/h5
 ul 
 li class=none
a href=../myModule1/index.htmlmyModule1/a !-- should be 
 myModule1/index.html instead --
 /li  
 li class=none
a href=../myModule2/index.htmlmyModule2/a !-- should be 
 myModule2/index.html instead --
 /li
 /ul
 - and in both modules pages, my link to the parent project is like this :
 h5Parent project/h5
 ul
 li class=none
a href=../myRoot/index.htmlmyRoot/a !-- should be 
 ../index.html instead --
 /li
 /ul
 The weirdest thing is that everything is fine when the artefactId and the 
 eclipse project name (directory) are different !!! the problem appears only 
 when they are identical...
 Thanks for your help !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MPIR-195) Attempting to configure maven-project-info-reports-plugin in reporting section of pom causes java.lang.ArrayIndexOutOfBoundsException to be thrown by site goal

2010-05-23 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPIR-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPIR-195.
--

Resolution: Not A Bug

There is no default version of the pir-plugin. It is not specified in any 
version of the maven super pom, so maven will use the last version it finds in 
your repo. OTOH, the site plugin version is specified in the super pom, so 
there is a default version, but it depends on which maven version you are 
running. In brief, your build is not reproducible (the fact that it works for 
you does not imply that it will also work for me), that's why you should always 
specify explicitly the versions of all plugins you are using [1]. This is all 
standard maven philosophy, if you have any questions about it please read up on 
the docs (admittedly often hard to find), or discuss it on the mailing list.

Finally, it has been specifically emphasized in the release notes that pir-2.2 
requires site plugin 2.1. This is not a bug.


[1] http://maven.apache.org/guides/mini/guide-configuring-plugins.html

 Attempting to configure maven-project-info-reports-plugin in reporting 
 section of pom causes java.lang.ArrayIndexOutOfBoundsException to be thrown 
 by site goal
 ---

 Key: MPIR-195
 URL: http://jira.codehaus.org/browse/MPIR-195
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Steve Gilbert
Assignee: Lukas Theussl
Priority: Critical

 With an empty local repository using Maven 2.2.1, if plugin is added to the 
 reporting section of the pom.xml, the site goal throws a 
 java.lang.ArrayIndexOutOfBoundsException and the build fails.
 Removing the plugin from the section or changing the version back to 2.1.2 
 (from 2.2) resolves the problem.
 This prevents using any configuration of the plugin.
 Placing the following pom into an empty directory and executing mvn site 
 demonstrates the bug.
 {code}
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/maven-v4_0_0.xsd;
   modelVersion4.0.0/modelVersion
   groupIdtestgroup/groupId
   artifactIdtestart/artifactId
   packagingjar/packaging
   version1.0-SNAPSHOT/version
   reporting
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-project-info-reports-plugin/artifactId
 version2.2/version
   /plugin
 /plugins
   /reporting
 /project
 {code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MPIR-195) Attempting to configure maven-project-info-reports-plugin in reporting section of pom causes java.lang.ArrayIndexOutOfBoundsException to be thrown by site goal

2010-05-23 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/MPIR-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222390#action_222390
]

Lukas Theussl commented on MPIR-195:

bq. Whatever it pulls down is the default version.

But this default version (as you define it) depends on your default repository
and settings (if I happen to have an old version of pir in my local repo, maven
will use that; if you start with an empty repo, maven will use the latest
version it finds in whatever remote repos you have specified), and whenever we
release a new version, maven will give you a new default. So your build is
not reproducible and you shouldn't be surprised if it breaks at one point.

bq. The fact that it is not declared in a pom does not mean there is no default
version.

Yes it does. What is not in your pom is not defined.

bq. I still assert this is a regression bug.

No it isn't.

bq. We've not declared our site plugin version so that we use the latest
version released by your team. I believe what you are saying is that in fact
that practice is bad and that we should be tied to a specific version and
relying on the latest released version is a bad idea.

Your experience proofs that it is indeed a very bad idea...

Attempting to configure maven-project-info-reports-plugin in reporting
section of pom causes java.lang.ArrayIndexOutOfBoundsException to be thrown
by site goal
---

Key: MPIR-195
URL: http://jira.codehaus.org/browse/MPIR-195
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Steve Gilbert
Assignee: Lukas Theussl
Priority: Critical

With an empty local repository using Maven 2.2.1, if plugin is added to the
reporting section of the pom.xml, the site goal throws a
java.lang.ArrayIndexOutOfBoundsException and the build fails.
Removing the plugin from the section or changing the version back to 2.1.2
(from 2.2) resolves the problem.
This prevents using any configuration of the plugin.
Placing the following pom into an empty directory and executing mvn site
demonstrates the bug.
{code}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdtestgroup/groupId
artifactIdtestart/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
version2.2/version
/plugin
/plugins
/reporting
/project
{code}

[jira] Closed: (DOXIA-370) Confluence module cannot parse horizontal separator

2010-05-22 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-370.
---

   Resolution: Fixed
Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

Patch applied in 
[r947266|http://svn.apache.org/viewvc?view=revisionrevision=947266]. Thanks!

 Confluence module cannot parse horizontal separator
 ---

 Key: DOXIA-370
 URL: http://jira.codehaus.org/browse/DOXIA-370
 Project: Maven Doxia
  Issue Type: Bug
  Components: Module - Confluence
Affects Versions: 1.1.1
Reporter: Dave Syer
Assignee: Lukas Theussl
 Fix For: 1.1.3

 Attachments: DOXIA-370.patch


 Confluence module cannot parse horizontal separator.  E.g. if you parse this
 {code}
 Up
 
 Down
 {code}
 you get out of bounds exception in the ListBlockParser.  This code looks 
 pretty flakey (I probably wrote it, so apologies if it was my fault):
 {code}
private boolean isList( String line )
 {
 line = line.trim();
 if ( line.startsWith( * ) || line.startsWith( - ) || 
 line.startsWith( # ) )
 {
 String temp = line.substring( 1 );
 while ( temp.charAt( 0 ) == '*' || temp.charAt( 0 ) == '-' || 
 temp.charAt( 0 ) == '#' )
 {
 temp = temp.substring( 1 );
 }
 if ( temp.charAt( 0 ) == ' ' )
 {
 return true;
 }
 }
 return false;
 }
 {code}
 There are a load of potential out of bounds exceptions there.   This one 
 happens to come from the fact that the loop never terminates before the temp 
 string is exhausted.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-356) Relative URLs for images don't work with PDF

2010-05-22 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-356.
---

Resolution: Duplicate
  Assignee: Lukas Theussl

 Relative URLs for images don't work with PDF
 

 Key: DOXIA-356
 URL: http://jira.codehaus.org/browse/DOXIA-356
 Project: Maven Doxia
  Issue Type: Bug
  Components: Book
Affects Versions: 1.1.2
 Environment: OSX 10.5.7, Java 5
Reporter: Nathan Sowatskey
Assignee: Lukas Theussl

 Hi
 With APT based sites only, one can use a relative URL for images:
 [../images/picture.jpg]
 With the PDF generation though, this won't work, so we need to have:
 [http://site/images/picture.jpg]
 Is there a good reason for this. Can it be changed?
 Thanks
 Nathan

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-386) Snippet Macro: Reference file does not support UTF-8 file format to generate the page garbage

2010-05-22 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222162#action_222162
 ] 

Lukas Theussl commented on DOXIA-386:
-

Problem is there is no direct way to pass the encoding to the parser. This 
needs a more general solution.

 Snippet Macro:  Reference file does not support UTF-8 file format to generate 
 the page garbage
 --

 Key: DOXIA-386
 URL: http://jira.codehaus.org/browse/DOXIA-386
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2
 Environment: windows7 zh_CN
Reporter: pinghe

 plugin
   artifactIdmaven-site-plugin/artifactId
   version2.1/version
   configuration
 localeszh_CN/locales
 inputEncodingUTF-8/inputEncoding
 outputEncodingUTF-8/outputEncoding
   /configuration
 /plugin
 my sample apt file:
 %{snippet|file=target/site/reference/html/sample.html|verbatim=false}
 sample.html:
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE html
   PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN 
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html 
 xmlns=http://www.w3.org/1999/xhtml;headtitle#20013;#25991;/title/headbody/body/html
 org.apache.maven.doxia.macro.snippet.SnippetReader
 readLines:
  reader = new BufferedReader(new InputStreamReader(source.openStream()));
 use InputStreamReader(InputStream in) 
 change to:
  InputStreamReader(InputStream in, Charset cs)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MPIR-195) Attempting to configure maven-project-info-reports-plugin in reporting section of pom causes java.lang.ArrayIndexOutOfBoundsException to be thrown by site goal

2010-05-22 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPIR-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPIR-195.
--

Resolution: Not A Bug
  Assignee: Lukas Theussl

I put the above pom into an empty diretory, added site-plugin-2.1 in the build 
section and got no Exception.

 Attempting to configure maven-project-info-reports-plugin in reporting 
 section of pom causes java.lang.ArrayIndexOutOfBoundsException to be thrown 
 by site goal
 ---

 Key: MPIR-195
 URL: http://jira.codehaus.org/browse/MPIR-195
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Steve Gilbert
Assignee: Lukas Theussl
Priority: Critical

 With an empty local repository using Maven 2.2.1, if plugin is added to the 
 reporting section of the pom.xml, the site goal throws a 
 java.lang.ArrayIndexOutOfBoundsException and the build fails.
 Removing the plugin from the section or changing the version back to 2.1.2 
 (from 2.2) resolves the problem.
 This prevents using any configuration of the plugin.
 Placing the following pom into an empty directory and executing mvn site 
 demonstrates the bug.
 {code}
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/maven-v4_0_0.xsd;
   modelVersion4.0.0/modelVersion
   groupIdtestgroup/groupId
   artifactIdtestart/artifactId
   packagingjar/packaging
   version1.0-SNAPSHOT/version
   reporting
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-project-info-reports-plugin/artifactId
 version2.2/version
   /plugin
 /plugins
   /reporting
 /project
 {code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-224) Add source name in parser

2010-05-21 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222018#action_222018
 ] 

Lukas Theussl commented on DOXIA-224:
-

Also the basedir is needed in multi-module builds, see DOXIA-373.

 Add source name in parser
 -

 Key: DOXIA-224
 URL: http://jira.codehaus.org/browse/DOXIA-224
 Project: Maven Doxia
  Issue Type: New Feature
  Components: Core
Affects Versions: 1.0-alpha-10
Reporter: Vincent Siveton
 Fix For: 1.2


 Should be useful when warn log are call

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DOXIA-373) Macro snippet with file option in a multi-pom project

2010-05-21 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/DOXIA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Lukas Theussl updated DOXIA-373:

Fix Version/s: 1.2

Macro snippet with file option in a multi-pom project
-

Key: DOXIA-373
URL: http://jira.codehaus.org/browse/DOXIA-373
Project: Maven Doxia
Issue Type: Bug
Environment: Window XP
Reporter: poulfich
Fix For: 1.2

The project is a multi pom project. In the main pom project, I declare the
other pom like this :
modules
module../moduleA/module
module../moduleB/module
...
/modules
To avoid duplicate code,I use the macro snippet in my documentation in
modules A, B and Main. For convenient, the following syntax :
%{snippet|id=myid|file=src/main/java/mypackage/File.java}.
When I build the site from each module A or B, all work fine. But when the
site was generated from the main module, the snippet seem not work : All the
pages who include a snippet's macros in A or B are not generated. I obtain
the same problem if i do a simple site or a site:stage

The maven site work fine work include pictures and schemas of local
documentation (in A et B). I try to use
the velocity macro and transform MyFile.apt to MyFile.apt.vm like these :
MyFile.apt.vm
%{snippet|id=myid|file=${basedir}/src/main/java/mypackage/File.java}.
It's fail too.
I use maven 2.1.0
Sorry for my poor english

[jira] Commented: (DOXIA-373) Macro snippet with file option in a multi-pom project

2010-05-21 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/DOXIA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222019#action_222019
]

Lukas Theussl commented on DOXIA-373:
-

The problem is that current parsers don't know anything about the origin of the
sources they are parsing, see DOXIA-224. The getBasedir() in AbstractParser
returns the directory where the build is started, unless the system property
basedir is set, so the workaround above is valid.

Macro snippet with file option in a multi-pom project
-

Key: DOXIA-373
URL: http://jira.codehaus.org/browse/DOXIA-373
Project: Maven Doxia
Issue Type: Bug
Environment: Window XP
Reporter: poulfich
Fix For: 1.2

[jira] Updated: (DOXIA-376) FO: add periods to numbered lists

2010-05-21 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated DOXIA-376:


Summary: FO: add periods to numbered lists  (was: add periods to numbered 
lists)

 FO: add periods to numbered lists
 -

 Key: DOXIA-376
 URL: http://jira.codehaus.org/browse/DOXIA-376
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Module - FO
Affects Versions: 1.1.2
 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 13:10:27-0600)
 Java version: 1.6.0_16
 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux version: 2.6.26-2-686 arch: i386 Family: unix
Reporter: deckrider

 For numbered lists as follows in apt syntax:
 [[1]] One
 [[2]] Two
 [[3]] Three
 The following logic is produced:
 1 One
 2 Two
 3 Three
 It would be nice instead if the following logic is produced:
 1. One
 2. Two
 3. Three
 Thank you.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-376) FO: add periods to numbered lists

2010-05-21 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-376.
---

   Resolution: Fixed
Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

Done in [r946933|http://svn.apache.org/viewvc?view=revisionrevision=946933]

 FO: add periods to numbered lists
 -

 Key: DOXIA-376
 URL: http://jira.codehaus.org/browse/DOXIA-376
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Module - FO
Affects Versions: 1.1.2
 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 13:10:27-0600)
 Java version: 1.6.0_16
 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux version: 2.6.26-2-686 arch: i386 Family: unix
Reporter: deckrider
Assignee: Lukas Theussl
 Fix For: 1.1.3


 For numbered lists as follows in apt syntax:
 [[1]] One
 [[2]] Two
 [[3]] Three
 The following logic is produced:
 1 One
 2 Two
 3 Three
 It would be nice instead if the following logic is produced:
 1. One
 2. Two
 3. Three
 Thank you.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-382) Sink cannot be reused after parsing with ConfluenceParser

2010-05-21 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-382.
---

   Resolution: Fixed
Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

Patch applied with modifications in 
[r946935|http://svn.apache.org/viewvc?view=revisionrevision=946935]. Thanks!

 Sink cannot be reused after parsing with ConfluenceParser 
 --

 Key: DOXIA-382
 URL: http://jira.codehaus.org/browse/DOXIA-382
 Project: Maven Doxia
  Issue Type: Bug
  Components: Module - Confluence
Affects Versions: 1.1.2
Reporter: Sebastian Annies
Assignee: Lukas Theussl
 Fix For: 1.1.3

 Attachments: Patch_and_TestCase_for_DOXIA-382.patch


 The ConfluenceParser closes the Sink in #parse(Reader, Sink). That makes it 
 impossible to reuse the sink as target for a second parse. So you won't be 
 able to parse more than one Confluence document. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MPIR-194) [WARNING] Deprecated API called

2010-05-21 Thread Lukas Theussl (JIRA)

[WARNING] Deprecated API called
---

 Key: MPIR-194
 URL: http://jira.codehaus.org/browse/MPIR-194
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Lukas Theussl
Priority: Minor


Version 2.2 spits out a warning for each generated page:

{noformat}
[WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink instance 
and no SinkFactory available. Please update this plugin.
{noformat}

The warning can be ignored AFAICT but it is annoying and confusing for users.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MPIR-194) [WARNING] Deprecated API called

2010-05-21 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MPIR-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222036#action_222036
 ] 

Lukas Theussl commented on MPIR-194:


Well, it gets triggered by upgrading MPIR to v2.2 (no warnings with 2.1.2), so 
that's where it manifests itself and where users see it. So I think it should 
be reported here and marked as fixed once it's fixed in the deps.

 [WARNING] Deprecated API called
 ---

 Key: MPIR-194
 URL: http://jira.codehaus.org/browse/MPIR-194
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Lukas Theussl
Priority: Minor

 Version 2.2 spits out a warning for each generated page:
 {noformat}
 [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink 
 instance and no SinkFactory available. Please update this plugin.
 {noformat}
 The warning can be ignored AFAICT but it is annoying and confusing for users.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MPDF-39) Make validation configurable

2010-05-21 Thread Lukas Theussl (JIRA)

Make validation configurable


 Key: MPDF-39
 URL: http://jira.codehaus.org/browse/MPDF-39
 Project: Maven 2.x PDF Plugin
  Issue Type: New Feature
Affects Versions: 1.1
Reporter: Lukas Theussl


Like MSITE-474: the validation in the Parser is not configurable, so it has to 
be performed externally.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MPDF-39) Make validation configurable

2010-05-21 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPDF-39.
-

   Resolution: Fixed
Fix Version/s: 1.2
 Assignee: Lukas Theussl

Done in [r947014|http://svn.apache.org/viewvc?view=revisionrevision=947014]. 
The configuration parameter is the same as for the site plugin: {{validate}} 
and it defaults to false.

 Make validation configurable
 

 Key: MPDF-39
 URL: http://jira.codehaus.org/browse/MPDF-39
 Project: Maven 2.x PDF Plugin
  Issue Type: New Feature
Affects Versions: 1.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.2


 Like MSITE-474: the validation in the Parser is not configurable, so it has 
 to be performed externally.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-390) Validation logic is not correct

2010-05-12 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-390.
---

Resolution: Fixed

Done in [r943450|http://svn.apache.org/viewvc?view=revisionrevision=943450]

 Validation logic is not correct
 ---

 Key: DOXIA-390
 URL: http://jira.codehaus.org/browse/DOXIA-390
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.1.3


 Currently the AbstractXmlParser skips validation if a document has no DTD nor 
 xsd, even if validate=true. I think the behavior should only be controlled by 
 the validate flag and if a document has no DTD nor xsd, validation should 
 fail.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIASITETOOLS-37) Make SiteRenderer validate xml docs

2010-05-12 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIASITETOOLS-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIASITETOOLS-37.
---

Resolution: Fixed

Done in [r943453|http://svn.apache.org/viewvc?view=revisionrevision=943453]

 Make SiteRenderer validate xml docs
 ---

 Key: DOXIASITETOOLS-37
 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-37
 Project: Maven Doxia Sitetools
  Issue Type: Improvement
  Components: Site renderer
Affects Versions: 1.1.2
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.1.3


 Since 1.1, Doxia's AbstractXmlParser is validating input docs by default, but 
 this option is not configurable from outside, see MSITE-474, at least I don't 
 see a way to do it without some major API change. I therefore propose to let 
 the SiteRenderer do the validation, where it can be configured by the site 
 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-392) Switch off xml validation by default

2010-05-12 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-392.
---

Resolution: Fixed

Done in [r943451|http://svn.apache.org/viewvc?view=revisionrevision=943451]

 Switch off xml validation by default
 

 Key: DOXIA-392
 URL: http://jira.codehaus.org/browse/DOXIA-392
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.1.3


 In 1.1 the AbstractXmlParser validates *every* xml document that has either a 
 DOCTYPE or an xsd declaration, see DOXIA-390. I think validation should be an 
 option and be switched off by default.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MSITE-474) Make validation configurable

2010-05-12 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSITE-474.
---

Resolution: Fixed
  Assignee: Lukas Theussl

Done in [r943455|http://svn.apache.org/viewvc?view=revisionrevision=943455]

 Make validation configurable
 

 Key: MSITE-474
 URL: http://jira.codehaus.org/browse/MSITE-474
 Project: Maven 2.x Site Plugin
  Issue Type: New Feature
Affects Versions: 2.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 2.1.1


 There should be a configuration parameter to switch on/off the validation, 
 default should be off.
 Note that there is a setValidate() method in Doxia core's AbstractXmlParser 
 but this cannot be accessed from the SiteRenderer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-474) Make validation configurable

2010-05-12 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221004#action_221004
 ] 

Lukas Theussl commented on MSITE-474:
-

For reference: the new configuration parameter is {{validate}} and it 
defaults to false.

 Make validation configurable
 

 Key: MSITE-474
 URL: http://jira.codehaus.org/browse/MSITE-474
 Project: Maven 2.x Site Plugin
  Issue Type: New Feature
Affects Versions: 2.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 2.1.1


 There should be a configuration parameter to switch on/off the validation, 
 default should be off.
 Note that there is a setValidate() method in Doxia core's AbstractXmlParser 
 but this cannot be accessed from the SiteRenderer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-440) Site document validation fails if unable to retrieve schema (in offline mode)

2010-05-12 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/MSITE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221005#action_221005
]

Lukas Theussl commented on MSITE-440:
-

I have deployed site-plugin-2.1.1-SNAPSHOT that includes MSITE-474, please test
if that helps anybody here. It doesn't really fix this issue (see DOXIA-388)
but it provides a more coherent workaround.

Site document validation fails if unable to retrieve schema (in offline mode)
-

[jira] Closed: (MSITE-464) Site generation fails on !DOCTYPE in xdoc documentation

2010-05-12 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSITE-464.
---

   Resolution: Fixed
Fix Version/s: 2.1.1
 Assignee: Lukas Theussl

This should be fixed with MSITE-474 and DOXIA-390. Validation is only run when 
explicitly specified, in which case a xsd is required.

 Site generation fails on !DOCTYPE in xdoc documentation
 -

 Key: MSITE-464
 URL: http://jira.codehaus.org/browse/MSITE-464
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows XP, Maven 2.2.1, JDK 1.6.0_17
Reporter: Niall Pemberton
Assignee: Lukas Theussl
 Fix For: 2.1.1

 Attachments: MSITE-464.zip, test_doctype.xml


 Apache Commons has a couple of components with documentation showing examples 
 of XML documents including the !DOCTYPE element - these are enclosed in 
 CDATA elements and docs generated with no problems using version 2.0.1 of the 
 maven-site-plugin - but fail with version 2.1.
 Running mvn site  fails with the following error:
 {code}
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error during page generation
 Embedded error: Error parsing 
 'C:\svn\commons-proper\chain\xdocs\test_doctype.xml': line [-1] Error 
 validating the model: Error:
   Public ID: null
   System ID: null
   Line number: 3
   Column number: 11
   Message: cvc-elt.1: Cannot find the declaration of element 'document'.
 {code}
 I'm attaching an example xdoc document which causes this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-384) Including a DTD reference in a source element results in a SAXParseException

2010-05-12 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-384.
---

   Resolution: Fixed
Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

Should be fixed with DOXIA-390, I added your test case. Thanks!

 Including a DTD reference in a source element results in a SAXParseException
 --

 Key: DOXIA-384
 URL: http://jira.codehaus.org/browse/DOXIA-384
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2
Reporter: Niall Pemberton
Assignee: Lukas Theussl
 Fix For: 1.1.3

 Attachments: Doxia-source-dtd-test.patch


 Including a DTD in a source element should be ignored. But the 
 PATTERN_DOCTYPE regular expresion used in the validate() method in 
 AbstractXmlParser finds this and results in the XML being validated and 
 causes a SAXParseException.
 This is causing MSITE-464 reported against the maven-site-plugin.
 We're also seeing a similar problem with the maven-pmd-plugin which may be 
 related.
 Attaching a test case which demonstrates this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DOXIA-390) Validation logic is not correct

2010-05-10 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated DOXIA-390:


Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

 Validation logic is not correct
 ---

 Key: DOXIA-390
 URL: http://jira.codehaus.org/browse/DOXIA-390
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.1.3


 Currently the AbstractXmlParser skips validation if a document has no DTD nor 
 xsd, even if validate=true. I think the behavior should only be controlled by 
 the validate flag and if a document has no DTD nor xsd, validation should 
 fail.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DOXIA-392) Switch off xml validation by default

2010-05-10 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated DOXIA-392:


Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

 Switch off xml validation by default
 

 Key: DOXIA-392
 URL: http://jira.codehaus.org/browse/DOXIA-392
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.1.3


 In 1.1 the AbstractXmlParser validates *every* xml document that has either a 
 DOCTYPE or an xsd declaration, see DOXIA-390. I think validation should be an 
 option and be switched off by default.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DOXIA-392) Switch off xml validation by default

2010-05-10 Thread Lukas Theussl (JIRA)

Switch off xml validation by default


 Key: DOXIA-392
 URL: http://jira.codehaus.org/browse/DOXIA-392
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.1
Reporter: Lukas Theussl


In 1.1 the AbstractXmlParser validates *every* xml document that has either a 
DOCTYPE or an xsd declaration, see DOXIA-390. I think validation should be an 
option and be switched off by default.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MSITE-474) Make validation configurable

2010-05-07 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MSITE-474:


Fix Version/s: 2.1.1

 Make validation configurable
 

 Key: MSITE-474
 URL: http://jira.codehaus.org/browse/MSITE-474
 Project: Maven 2.x Site Plugin
  Issue Type: New Feature
Affects Versions: 2.1
Reporter: Lukas Theussl
 Fix For: 2.1.1


 There should be a configuration parameter to switch on/off the validation, 
 default should be off.
 Note that there is a setValidate() method in Doxia core's AbstractXmlParser 
 but this cannot be accessed from the SiteRenderer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DOXIASITETOOLS-37) Make SiteRenderer validate xml docs

2010-05-07 Thread Lukas Theussl (JIRA)

Make SiteRenderer validate xml docs
---

 Key: DOXIASITETOOLS-37
 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-37
 Project: Maven Doxia Sitetools
  Issue Type: Improvement
  Components: Site renderer
Affects Versions: 1.1.2
Reporter: Lukas Theussl


Since 1.1, Doxia's AbstractXmlParser is validating input docs by default, but 
this option is not configurable from outside, see MSITE-474, at least I don't 
see a way to do it without some major API change. I therefore propose to let 
the SiteRenderer do the validation, where it can be configured by the site 
plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DOXIASITETOOLS-37) Make SiteRenderer validate xml docs

2010-05-07 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIASITETOOLS-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated DOXIASITETOOLS-37:


Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

 Make SiteRenderer validate xml docs
 ---

 Key: DOXIASITETOOLS-37
 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-37
 Project: Maven Doxia Sitetools
  Issue Type: Improvement
  Components: Site renderer
Affects Versions: 1.1.2
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.1.3


 Since 1.1, Doxia's AbstractXmlParser is validating input docs by default, but 
 this option is not configurable from outside, see MSITE-474, at least I don't 
 see a way to do it without some major API change. I therefore propose to let 
 the SiteRenderer do the validation, where it can be configured by the site 
 plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DOXIA-387) Add RandomAccessSink

2010-05-06 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated DOXIA-387:


Fix Version/s: 1.2

As a new feature, schedule for a minor release. A minor note: please add 
license header and javadocs to any future patches, see 
http://maven.apache.org/developers/conventions/code.html. 

 Add RandomAccessSink
 

 Key: DOXIA-387
 URL: http://jira.codehaus.org/browse/DOXIA-387
 Project: Maven Doxia
  Issue Type: New Feature
  Components: Sink API
Affects Versions: 1.1.2
Reporter: Robert Scholte
Priority: Minor
 Fix For: 1.2

 Attachments: DOXIA-387.patch, randomaccesssink.patch


 In some cases components have to write to different parts of a page. With the 
 current implementation you can only keep appending the page.
 I've attached a new class, with which it should be possible to add subsinks 
 to which you can write at any time.
 Code might look like this
 {code}
 baseSink.text(Hello World);
 Sink top = baseSink.addSink();
 baseSink.horizontalRule();
 Sink content = baseSink.addSink();
 baseSink.text(So long, farewell);
 {code}
 After flushing the basesink, subsinks will flush to the basesink.
 Closing the basesink will close al subsinks as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-391) Repare markmail references

2010-05-04 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-391.
---

   Resolution: Fixed
Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

Fixed, thanks! I also updated the links in doxia main component, doxia 
sitetools and doxia-tools.

 Repare markmail references
 --

 Key: DOXIA-391
 URL: http://jira.codehaus.org/browse/DOXIA-391
 Project: Maven Doxia
  Issue Type: Task
Reporter: Robert Scholte
Assignee: Lukas Theussl
Priority: Minor
 Fix For: 1.1.3

 Attachments: markmail.patch


 Component is actually 'Site'. It seems like markmail uses other URL's 
 nowadays. I've attached a patch which updates the URL's in the pom.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-477) menu ref=modules/ href's drop the leading character in the href

2010-05-03 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=219705#action_219705
 ] 

Lukas Theussl commented on MSITE-477:
-

Please attach a little test project.

 menu ref=modules/ href's drop the leading character in the href
 ---

 Key: MSITE-477
 URL: http://jira.codehaus.org/browse/MSITE-477
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: multi module
Affects Versions: 2.0.1, 2.1
Reporter: Andrew Hughes

 parent pom.xml:
 {noformat}
 modulemodule-a/modules
 {noformat}
 parent site.xml:
 {noformat}
 menu ref=modules/
 {noformat}
 The generated html links to module-a look like this
 {noformat}
 a href=odule-a/index.html title=module-amodule-a/a
 {noformat}
 Note, the href is missing the leading character m, it should be..
 {noformat}
 a href=module-a/index.html title=module-amodule-a/a
 {noformat}
 I tried to run this wil 2.0.1 and 2.1 - but got the same result with both. 
 Hopfully this is a mis-configuration on my part, but if it is then perhaps it 
 can be tested by the plugin and can fail the build.
 Thanks for reading :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MSITE-474) Make validation configurable

2010-04-28 Thread Lukas Theussl (JIRA)

Make validation configurable


 Key: MSITE-474
 URL: http://jira.codehaus.org/browse/MSITE-474
 Project: Maven 2.x Site Plugin
  Issue Type: New Feature
Affects Versions: 2.1
Reporter: Lukas Theussl


There should be a configuration parameter to switch on/off the validation, 
default should be off.

Note that there is a setValidate() method in Doxia core's AbstractXmlParser but 
this cannot be accessed from the SiteRenderer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DOXIA-388) Include common DTDs and xsds

2010-04-28 Thread Lukas Theussl (JIRA)

Include common DTDs and xsds


 Key: DOXIA-388
 URL: http://jira.codehaus.org/browse/DOXIA-388
 Project: Maven Doxia
  Issue Type: New Feature
  Components: Module - Fml, Module - Xdoc, Module - Xhtml, Modules
Reporter: Lukas Theussl


I think that at least xdoc and fml (maybe xhtml) modules should include the 
necessary files do enable validation without internet connection.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Deleted: (DOXIA-389) Validation logic is not correct

2010-04-28 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl deleted DOXIA-389:



 Validation logic is not correct
 ---

 Key: DOXIA-389
 URL: http://jira.codehaus.org/browse/DOXIA-389
 Project: Maven Doxia
  Issue Type: Bug
Reporter: Lukas Theussl



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DOXIA-389) Validation logic is not correct

2010-04-28 Thread Lukas Theussl (JIRA)

Validation logic is not correct
---

 Key: DOXIA-389
 URL: http://jira.codehaus.org/browse/DOXIA-389
 Project: Maven Doxia
  Issue Type: Bug
Reporter: Lukas Theussl




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DOXIA-390) Validation logic is not correct

2010-04-28 Thread Lukas Theussl (JIRA)

Validation logic is not correct
---

 Key: DOXIA-390
 URL: http://jira.codehaus.org/browse/DOXIA-390
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2
Reporter: Lukas Theussl


Currently the AbstractXmlParser skips validation if a document has no DTD nor 
xsd, even if validate=true. I think the behavior should only be controlled by 
the validate flag and if a document has no DTD nor xsd, validation should fail.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-388) Include common DTDs and xsds

2010-04-28 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=219270#action_219270
 ] 

Lukas Theussl commented on DOXIA-388:
-

I am still learning..., the xsds for xdoc and fml are actually already 
distributed. Now we should also use them whenever a document contains the 
correct declaration and the build is run in offline mode.

 Include common DTDs and xsds
 

 Key: DOXIA-388
 URL: http://jira.codehaus.org/browse/DOXIA-388
 Project: Maven Doxia
  Issue Type: New Feature
  Components: Module - Fml, Module - Xdoc, Module - Xhtml, Modules
Reporter: Lukas Theussl

 I think that at least xdoc and fml (maybe xhtml) modules should include the 
 necessary files do enable validation without internet connection.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DOXIA-388) Use internal xdoc and fml xsds for validation when in offline mode

2010-04-28 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated DOXIA-388:


Summary: Use internal xdoc and fml xsds for validation when in offline mode 
 (was: Include common DTDs and xsds)

 Use internal xdoc and fml xsds for validation when in offline mode
 --

 Key: DOXIA-388
 URL: http://jira.codehaus.org/browse/DOXIA-388
 Project: Maven Doxia
  Issue Type: New Feature
  Components: Module - Fml, Module - Xdoc, Module - Xhtml, Modules
Reporter: Lukas Theussl

 I think that at least xdoc and fml (maybe xhtml) modules should include the 
 necessary files do enable validation without internet connection.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-387) Add RandomAccessSink

2010-04-27 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=219054#action_219054
 ] 

Lukas Theussl commented on DOXIA-387:
-

Your sink is itself an implementation so it should go into core. A test case 
will help as I don't quite understand the use case (yet).

 Add RandomAccessSink
 

 Key: DOXIA-387
 URL: http://jira.codehaus.org/browse/DOXIA-387
 Project: Maven Doxia
  Issue Type: New Feature
  Components: Sink API
Affects Versions: 1.1.2
Reporter: Robert Scholte
Priority: Minor
 Attachments: randomaccesssink.patch


 In some cases components have to write to different parts of a page. With the 
 current implementation you can only keep appending the page.
 I've attached a new class, with which it should be possible to add subsinks 
 to which you can write at any time.
 Code might look like this
 {code}
 baseSink.text(Hello World);
 Sink top = baseSink.addSink();
 baseSink.horizontalRule();
 Sink content = baseSink.addSink();
 baseSink.text(So long, farewell);
 {code}
 After flushing the basesink, subsinks will flush to the basesink.
 Closing the basesink will close al subsinks as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-470) Classpath (ex/im)plosion with site plugin 2.1

2010-04-12 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=217653#action_217653
 ] 

Lukas Theussl commented on MSITE-470:
-

This seems to duplicate MSITE-459, can you check if the workaround there helps 
anything?

 Classpath (ex/im)plosion with site plugin 2.1
 -

 Key: MSITE-470
 URL: http://jira.codehaus.org/browse/MSITE-470
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Benson Margulies
 Attachments: mvn.log


 I'm not sure how to chase this. I got here with mvn javadoc:javadoc 
 javadoc:test-javadoc site:site site:deploy
 {noformat}
 [INFO] 
 
 [INFO] Building Manifest jar for training jobs
 [INFO] 
 
 [WARNING] Removing: check from forked lifecycle, to prevent recursive 
 invocation.
 [INFO] [checkstyle:checkstyle {execution: validate}]
 [INFO] Preparing javadoc:javadoc
 [WARNING] Removing: check from forked lifecycle, to prevent recursive 
 invocation.
 [INFO] [checkstyle:checkstyle {execution: validate}]
 [INFO] Starting audit...
 Audit done.
 [INFO] [site:site]
 [INFO] Parent project loaded from repository.
 [INFO] Generating Dependency Convergence report.
 [INFO] Generating Project Plugins report.
 [INFO] Generating Project License report.
 [INFO] Generating Project Team report.
 [INFO] Generating Project Summary report.
 [INFO] Generating Continuous Integration report.
 [INFO] Generating About report.
 [INFO] Generating Issue Tracking report.
 [INFO] Generating Dependency Management report.
 [INFO] Generating Source Repository report.
 [INFO] Generating Plugin Management report.
 [INFO] Generating Mailing Lists report.
 [INFO] Generating Dependencies report.
 [INFO] Generating JavaDocs report.
 [WARNING] Are you sure about the javadocVersion/ parameter? It seems to be 
 1.6
 [FATAL ERROR] org.apache.maven.plugins.site.SiteMojo#execute() caused a 
 linkage error (java.lang.ExceptionInInitializerError) and may be out-of-date. 
 Check the realms:
 [FATAL ERROR] Plugin realm = 
 app0.child-container[org.apache.maven.plugins:maven-site-plugin:2.1]
 urls[0] = 
 file:/Users/benson/.m2/repository/org/apache/maven/plugins/maven-site-plugin/2.1/maven-site-plugin-2.1.jar
 urls[1] = 
 file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar
 urls[2] = 
 file:/Users/benson/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.1.2/doxia-module-xhtml-1.1.2.jar
 urls[3] = 
 file:/Users/benson/.m2/repository/org/apache/maven/doxia/doxia-core/1.1.2/doxia-core-1.1.2.jar
 urls[4] = 
 file:/Users/benson/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
 urls[5] = 
 file:/Users/benson/.m2/repository/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar
 urls[6] = 
 file:/Users/benson/.m2/repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
 urls[7] = 
 file:/Users/benson/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar
 urls[8] = 
 file:/Users/benson/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
 urls[9] = 
 file:/Users/benson/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
 urls[10] = 
 file:/Users/benson/.m2/repository/org/apache/maven/doxia/doxia-module-apt/1.1.2/doxia-module-apt-1.1.2.jar
 urls[11] = 
 file:/Users/benson/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.1.2/doxia-module-xdoc-1.1.2.jar
 urls[12] = 
 file:/Users/benson/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.1.2/doxia-module-fml-1.1.2.jar
 urls[13] = 
 file:/Users/benson/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.1.2/doxia-decoration-model-1.1.2.jar
 urls[14] = 
 file:/Users/benson/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.1.2/doxia-site-renderer-1.1.2.jar
 urls[15] = 
 file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar
 urls[16] = 
 file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.8/plexus-velocity-1.1.8.jar
 urls[17] = 
 file:/Users/benson/.m2/repository/org/apache/velocity/velocity/1.5/velocity-1.5.jar
 urls[18] = 
 file:/Users/benson/.m2/repository/commons-collections/commons-collections/3.2/commons-collections-3.2.jar
 urls[19] = file:/Users/benson/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar
 urls[20] = 
 file:/Users/benson/.m2/repository/org/apache/maven/shared/maven-doxia-tools/1.2/maven-doxia-tools-1.2.jar
 urls[21] = 
 file:/Users/benson/.m2/repository/commons-io/commons-io/1.4/commons-io-1.4.jar
 urls[22] = 
 file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar
 urls[23] =

[jira] Updated: (DOXIA-78) Doxia XDOC parser and XHTML renderer ignore rowspan and colspan attributes for tables

2010-04-11 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated DOXIA-78:
---

Comment: was deleted

(was: [cheap 
dress|http://www.facts11.com/download/attachments/1048855/hpd1.html]
[cheap dress 
pants|http://www.facts11.com/download/attachments/1048855/hpd2.html]
[cheap dress 
shops|http://www.facts11.com/download/attachments/1048855/hpd3.html]
[cheap dresses for 
juniors|http://www.facts11.com/download/attachments/1048855/hpd4.html]
[cheap dress 
shoes|http://www.facts11.com/download/attachments/1048855/hpd5.html]
[cheap dress for a 
wedding|http://www.facts11.com/download/attachments/1048855/hpd6.html]
[cheap dress 
rentals|http://www.facts11.com/download/attachments/1048855/hpd7.html]
[cheap dress for 
prom|http://www.facts11.com/download/attachments/1048855/hpd8.html]
[cheap dresses for 
prom|http://www.facts11.com/download/attachments/1048855/hpd9.html]
[cheap dress 
clothes|http://www.facts11.com/download/attachments/1048855/hpd10.html]
[cheap dresses for 
juniors|http://www.facts11.com/download/attachments/1048855/hpd11.html]
[cheap dress 
clothes|https://wiki.luc.edu/download/attachments/21266444/hpd12.html]
[cheap dresses for 
women|https://wiki.luc.edu/download/attachments/21266444/hpd13.html]
[cheap dress up|https://wiki.luc.edu/download/attachments/21266444/hpd14.html]
[cheap dress 
websites|https://wiki.luc.edu/download/attachments/21266444/hpd15.html]
[cheap dress 
online|https://wiki.luc.edu/download/attachments/21266444/hpd16.html]
[cheap dress 
shops|https://wiki.luc.edu/download/attachments/21266444/hpd17.html]
[cheap dresses for 
homecoming|https://wiki.luc.edu/download/attachments/21266444/hpd18.html]
[cheap dress shirts for 
men|https://wiki.luc.edu/download/attachments/21266444/hpd19.html]
[cheap dress for 
sale|https://wiki.luc.edu/download/attachments/21266444/hpd20.html]
[cheap dress 
stores|https://wiki.luc.edu/download/attachments/21266444/hpd21.html]
[cheap dress 
suits|https://wiki.luc.edu/download/attachments/21266444/hpd22.html]
[cheap dress 
forms|https://wiki.luc.edu/download/attachments/21266444/hpd23.html]
[cheap dress boots|http://www.inventiondb.com/view.php?id=545]
[cheap dress for prom|http://www.inventiondb.com/view.php?id=546]
[cheap dressing tables|http://www.inventiondb.com/view.php?id=547]
[cheap dress fabric|http://www.inventiondb.com/view.php?id=548]
[cheap dress for wedding|http://www.inventiondb.com/view.php?id=549]
[cheap dress for sale|http://www.inventiondb.com/view.php?id=550]
[cheap dressage saddles|http://www.inventiondb.com/view.php?id=551]
[cheap dress hire|http://www.inventiondb.com/view.php?id=552]
[cheap dressing mirror|http://www.inventiondb.com/view.php?id=553]
[cheap dressmakers|http://www.inventiondb.com/view.php?id=554]
[cheap dress shirts for men|http://www.inventiondb.com/view.php?id=555]
[cheap dress sandals|http://risd.openprojectdb.org/view.php?id=18]
[cheap dress patterns|http://risd.openprojectdb.org/view.php?id=19]
[cheap dress up clothes|http://risd.openprojectdb.org/view.php?id=20]
[cheap dress watches|http://risd.openprojectdb.org/view.php?id=21]
[cheap dress fabric|http://risd.openprojectdb.org/view.php?id=22]
[cheap dress shoes for men|http://risd.openprojectdb.org/view.php?id=23]
[cheap dressy dresses|http://risd.openprojectdb.org/view.php?id=24]
[cheap dressy shoes|http://risd.openprojectdb.org/view.php?id=25]
[cheap dressy tops|http://risd.openprojectdb.org/view.php?id=26]
[cheap dressing up costumes|http://risd.openprojectdb.org/view.php?id=27]
[cheap dresses for prom|http://opdb.risd.edu/view.php?id=28]
[cheap dress up costumes|http://opdb.risd.edu/view.php?id=29]
[cheap dress patterns|http://opdb.risd.edu/view.php?id=30]
[cheap dress socks|http://opdb.risd.edu/view.php?id=31]
[cheap dress tops|http://opdb.risd.edu/view.php?id=32]
[cheap dress up clothes for kids|http://opdb.risd.edu/view.php?id=33]
[cheap dress watch|http://opdb.risd.edu/view.php?id=34]
[cheap dress ties|http://opdb.risd.edu/view.php?id=35]
[cheap dress wear|http://opdb.risd.edu/view.php?id=36]
[cheap dressage saddles|http://opdb.risd.edu/view.php?id=37]
[cheap dress material|http://opdb.risd.edu/view.php?id=38]
[cheap dresses to wear to a wedding|http://opdb.risd.edu/view.php?id=39]
[cheap dressing tables with mirror|http://opdb.risd.edu/view.php?id=40]
[cheap dressmakers dummy|http://opdb.risd.edu/view.php?id=41]
[cheap dress pumps|http://opdb.risd.edu/view.php?id=42]
[cheap dress makers|http://opdb.risd.edu/view.php?id=43]
[cheap dress 
heels|https://gaia.lbl.gov/bcvtb/Abbass%20Razan?action=AttachFiledo=gettarget=sdre1]
[cheap dress 
material|https://gaia.lbl.gov/bcvtb/Abbass%20Razan?action=AttachFiledo=gettarget=sdre2]
[cheap dressmaking 
fabric|https://gaia.lbl.gov/bcvtb/Abbass%20Razan?action=AttachFiledo=gettarget=sdre3]
[cheap dress 
makers|https://gaia.lbl.gov/bcvtb/Abbass%20Razan?action=AttachFiledo=gettarget=sdre4]
[cheap dress

[jira] Closed: (MPMD-119) CPD generates no duplicates in HTML report with site plugin 2.1

2010-04-09 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPMD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPMD-119.
--

   Resolution: Fixed
Fix Version/s: 2.5
 Assignee: Lukas Theussl

This seems to be fixed in current 2.5-SNAPSHOT. Snapshot is deployed, please 
test and confirm.

 CPD generates no duplicates in HTML report with site plugin 2.1
 ---

 Key: MPMD-119
 URL: http://jira.codehaus.org/browse/MPMD-119
 Project: Maven 2.x PMD Plugin
  Issue Type: Bug
  Components: CPD
Affects Versions: 2.4
Reporter: Kathryn Huxtable
Assignee: Lukas Theussl
 Fix For: 2.5


 Using site plugin 2.1 the pmd plugin generates a cpd.html file with no 
 duplicates, not even a notice of no duplicates. The cpd.xml file is fine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MSITE-468) Absolute links item href's are stripped to become relative

2010-04-08 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSITE-468.
---

Resolution: Duplicate
  Assignee: Lukas Theussl

See MSITE-159 and 
http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_do_my_absolute_links_get_translated_into_relative_links

 Absolute links item href's are stripped to become relative
 --

 Key: MSITE-468
 URL: http://jira.codehaus.org/browse/MSITE-468
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 2.0.1
Reporter: Andrew Hughes
Assignee: Lukas Theussl

 When I add the follwing to site.xml:
 {noformat} 
 links
   item name=BLAH href=http://xyz.com/blah/
 /links
 {noformat} 
 The generated html output is:
 {noformat} 
 a href=blahBLAH/a
 {noformat} 
 This is wrong, if I stipulate http://*; this should be an external (and 
 absolute link), the generated html should have an absolute href url, like 
 this:
 {noformat} 
 a href=http://xyz.com/blah;BLAH/a
 {noformat} 
 The conditions when this relative href translation occurs is when I have  
 have ${project.url}==http://xyz.com; in my pom.xml, like this: 
 {noformat} 
 project
   ...
   urlhttp://xyz.com/url
   ...
 /project
 {noformat} 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-385) Xdoc: tables without align attribute is center aligned

2010-03-22 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-385.
---

   Resolution: Fixed
Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

Fixed in r926049. The align attribute was inserted by the XhtmlBaseSink, which 
is certainly wrong. I also removed a corresponding align attribute that was 
inserted for table cells.

 Xdoc: tables without align attribute is center aligned
 

 Key: DOXIA-385
 URL: http://jira.codehaus.org/browse/DOXIA-385
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2
Reporter: Dennis Lundberg
Assignee: Lukas Theussl
 Fix For: 1.1.3


 If the Xdoc table doesn't have the align-attribute set, the produced xhtml 
 gets this attribute: align=center. This is a regression compared to 
 previous behavior.
 I think that if no align-attribute is set in the Xdoc source file, then no 
 align-attribute should be output in the xhtml document.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (DOXIA-385) Xdoc: tables without align attribute is center aligned

2010-03-22 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/DOXIA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=214795#action_214795
]

Lukas Theussl edited comment on DOXIA-385 at 3/22/10 7:46 AM:
--

Fixed in [r926049|http://svn.apache.org/viewvc?view=revisionrevision=926049].
The align attribute was inserted by the XhtmlBaseSink, which is certainly
wrong. I also removed a corresponding align attribute that was inserted for
table cells.

was (Author: lukas):
Fixed in r926049. The align attribute was inserted by the XhtmlBaseSink,
which is certainly wrong. I also removed a corresponding align attribute that
was inserted for table cells.

Xdoc: tables without align attribute is center aligned

Key: DOXIA-385
URL: http://jira.codehaus.org/browse/DOXIA-385
Project: Maven Doxia
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Reporter: Dennis Lundberg
Assignee: Lukas Theussl
Fix For: 1.1.3

If the Xdoc table doesn't have the align-attribute set, the produced xhtml
gets this attribute: align=center. This is a regression compared to
previous behavior.
I think that if no align-attribute is set in the Xdoc source file, then no
align-attribute should be output in the xhtml document.

[jira] Commented: (DOXIA-385) Xdoc: tables without align attribute is center aligned

2010-03-20 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=214649#action_214649
 ] 

Lukas Theussl commented on DOXIA-385:
-

Why is this a regression? I think specifying the alignment explicitly was 
necessary to guarantee the equivalent rendering to different sinks. Eg fo (used 
by the pdf plugin) specifies different default values for the align properties, 
so tables would look different in html and pdf even if produced from the same 
source document.

 Xdoc: tables without align attribute is center aligned
 

 Key: DOXIA-385
 URL: http://jira.codehaus.org/browse/DOXIA-385
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2
Reporter: Dennis Lundberg

 If the Xdoc table doesn't have the align-attribute set, the produced xhtml 
 gets this attribute: align=center. This is a regression compared to 
 previous behavior.
 I think that if no align-attribute is set in the Xdoc source file, then no 
 align-attribute should be output in the xhtml document.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-464) Site generation fails on !DOCTYPE in xdoc documentation

2010-03-11 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=213507#action_213507
 ] 

Lukas Theussl commented on MSITE-464:
-

Another workaround: don't use CDATA and escape the xml special chars:

{code:xml}
source
lt;!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
http://java.sun.com/j2ee/dtds/web-app_2.2.dtd;
/source
{code}

 Site generation fails on !DOCTYPE in xdoc documentation
 -

 Key: MSITE-464
 URL: http://jira.codehaus.org/browse/MSITE-464
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows XP, Maven 2.2.1, JDK 1.6.0_17
Reporter: Niall Pemberton
 Attachments: MSITE-464.zip, test_doctype.xml


 Apache Commons has a couple of components with documentation showing examples 
 of XML documents including the !DOCTYPE element - these are enclosed in 
 CDATA elements and docs generated with no problems using version 2.0.1 of the 
 maven-site-plugin - but fail with version 2.1.
 Running mvn site  fails with the following error:
 {code}
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error during page generation
 Embedded error: Error parsing 
 'C:\svn\commons-proper\chain\xdocs\test_doctype.xml': line [-1] Error 
 validating the model: Error:
   Public ID: null
   System ID: null
   Line number: 3
   Column number: 11
   Message: cvc-elt.1: Cannot find the declaration of element 'document'.
 {code}
 I'm attaching an example xdoc document which causes this issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-384) Including a DTD reference in a source element results in a SAXParseException

2010-03-11 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=213508#action_213508
 ] 

Lukas Theussl commented on DOXIA-384:
-

We probably shouldn't use regexps at all. The DOCTYPE might also appear in a 
comment which will cause the same issue.

 Including a DTD reference in a source element results in a SAXParseException
 --

 Key: DOXIA-384
 URL: http://jira.codehaus.org/browse/DOXIA-384
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.2
Reporter: Niall Pemberton
 Attachments: Doxia-source-dtd-test.patch


 Including a DTD in a source element should be ignored. But the 
 PATTERN_DOCTYPE regular expresion used in the validate() method in 
 AbstractXmlParser finds this and results in the XML being validated and 
 causes a SAXParseException.
 This is causing MSITE-464 reported against the maven-site-plugin.
 We're also seeing a similar problem with the maven-pmd-plugin which may be 
 related.
 Attaching a test case which demonstrates this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MCHANGES-190) HTML in changes.xml stopped working

2010-03-07 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=212947#action_212947
]

Lukas Theussl commented on MCHANGES-190:

bq. no processing of the content from the changes.xml file should be performed
at all.

How do you want to generate anything without processing the content of
changes.xml?

bq. What if someone decides to send out HTML announcement mails ?

Then the content of changes.xml should be processed to produce an HTML mail (eg
via an option in the changes:announcement-mail goal).

The point of this issue is really just backward compatibility, the current
behavior of the plugin is perfectly correct IMO. The fact that in earlier
versions you could put arbitrary html inside CDATA is an undocumented (and I
would guess unintentional) feature, which should really be considered a bug (it
only works for html output, ie site generation, but you can't use it for eg
producing a pdf of the changes report via the pdf plugin).

HTML in changes.xml stopped working
---

Key: MCHANGES-190
URL: http://jira.codehaus.org/browse/MCHANGES-190
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: changes-report
Affects Versions: 2.3
Environment: Maven version: 2.0.10
Java version: 1.5.0_17
OS name: linux version: 2.6.32-686 arch: i386 Family: unix
Reporter: Christian Schulte
Priority: Critical
Attachments: changes.xml, changes.xml, MCHANGES-190.zip

The fix for MCHANGES-189 does not seem to be correct. A changes.xml file
containing HTML-Tags got rendered correctly using version 2.2. Starting with
version 2.3, HTML-Tags will be encoded using HTML entities for the '' and
'' characters leading to the actual tags getting shown in the report. See
the attached example changes.xml file containing HTML no longer working with
version 2.3.

[jira] Reopened: (MSITE-417) CLONE -The modules menu is not inherited if the parent project has no modules of its own

2010-03-02 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl reopened MSITE-417:
-


Re-open for examination

 CLONE -The modules menu is not inherited if the parent project has no modules 
 of its own
 

 Key: MSITE-417
 URL: http://jira.codehaus.org/browse/MSITE-417
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: inheritance
Affects Versions: 2.0
 Environment: ubuntu linux / debian linux
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Attachments: MSITE-417.zip


 if I have a site.xml in a parent project that contains the line menu 
 ref=modules inherit=top / it is not inherited by child projects.
 menu ref=reports inherit=top / works, as does parent.
 This happens when the parent project has no modules of its own.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-380) Use of #include in APT page causes NullPointerException during page rendering

2010-02-21 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=210943#action_210943
 ] 

Lukas Theussl commented on DOXIA-380:
-

Let's leave it open for reference until somebody figures out what is going on 
exactly...

 Use of #include in APT page causes NullPointerException during page rendering
 -

 Key: DOXIA-380
 URL: http://jira.codehaus.org/browse/DOXIA-380
 Project: Maven Doxia
  Issue Type: Bug
  Components: Site Renderer
 Environment: maven 2.2.1
Reporter: Alan Alberghini
Priority: Minor
 Attachments: apt-include.log, VelocityTest.tar.gz


 In the last 2 days I tried to get this thing working.
 The situation is the following: I'm working on a maven site project and, for 
 some pages, I'm currently using the APT format.
 I'd really like to be able to include existing APT pages inside an APT page, 
 in order to make the collaboration between the 4 members of the project much 
 easier and smoother.
 To give an idea, I'd like to do this:
 merged-page.apt:
   ---
   Title
   ---
   ---
   ---
   Develeper 1 proposal:
   include page 1
   Developer 2 proposal:
   include page 2
   etc.
 At first, I tried using the %snippet DOXIA macro, but the included APT page 
 would not be rendered to HTML even setting verbatim=false.
 Then, I tried the #include macro from Velocity. I renamed my APT file to 
 filename.apt.vm in order to trigger the Velocity processor on it and put the 
 #include line in the file, but, whenever I launch maven site I keep getting 
 this error:
 and the page is not generated.
 Is there a way to fix this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-380) Use of #include in APT page causes NullPointerException during page rendering

2010-02-18 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/DOXIA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=210621#action_210621
]

Lukas Theussl commented on DOXIA-380:
-

bq. I saw that message, but the issue was not resolved so I decided to open a
bug report.

Well done! :)

bq. Out of curiosity, why version 2.1 of the site-plugin is not automatically
chosen if I don't specify the artifact version in the POM? Is it because of the
major changes involved in Doxia 1.1?

If you don't specify the version of a plugin, maven will use whatever is given
in the super pom, ie it depends on the maven version you are using.That's why
it is strongly recommended to always pin down the versions of all plugins you
are using.

Use of #include in APT page causes NullPointerException during page rendering
-

Key: DOXIA-380
URL: http://jira.codehaus.org/browse/DOXIA-380
Project: Maven Doxia
Issue Type: Bug
Components: Site Renderer
Environment: maven 2.2.1
Reporter: Alan Alberghini
Priority: Minor
Attachments: apt-include.log, VelocityTest.tar.gz

In the last 2 days I tried to get this thing working.
The situation is the following: I'm working on a maven site project and, for
some pages, I'm currently using the APT format.
I'd really like to be able to include existing APT pages inside an APT page,
in order to make the collaboration between the 4 members of the project much
easier and smoother.
To give an idea, I'd like to do this:
merged-page.apt:
---
Title
---
---
---
Develeper 1 proposal:
include page 1
Developer 2 proposal:
include page 2
etc.
At first, I tried using the %snippet DOXIA macro, but the included APT page
would not be rendered to HTML even setting verbatim=false.
Then, I tried the #include macro from Velocity. I renamed my APT file to
filename.apt.vm in order to trigger the Velocity processor on it and put the
#include line in the file, but, whenever I launch maven site I keep getting
this error:
and the page is not generated.
Is there a way to fix this?

[jira] Commented: (DOXIA-380) Use of #include in APT page causes NullPointerException during page rendering

2010-02-16 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=210354#action_210354
 ] 

Lukas Theussl commented on DOXIA-380:
-

For reference: this has been reported before: 
http://www.mail-archive.com/us...@maven.apache.org/msg98932.html

 Use of #include in APT page causes NullPointerException during page rendering
 -

 Key: DOXIA-380
 URL: http://jira.codehaus.org/browse/DOXIA-380
 Project: Maven Doxia
  Issue Type: Bug
  Components: Site Renderer
 Environment: maven 2.2.1
Reporter: Alan Alberghini
Priority: Minor
 Attachments: apt-include.log, VelocityTest.tar.gz


 In the last 2 days I tried to get this thing working.
 The situation is the following: I'm working on a maven site project and, for 
 some pages, I'm currently using the APT format.
 I'd really like to be able to include existing APT pages inside an APT page, 
 in order to make the collaboration between the 4 members of the project much 
 easier and smoother.
 To give an idea, I'd like to do this:
 merged-page.apt:
   ---
   Title
   ---
   ---
   ---
   Develeper 1 proposal:
   include page 1
   Developer 2 proposal:
   include page 2
   etc.
 At first, I tried using the %snippet DOXIA macro, but the included APT page 
 would not be rendered to HTML even setting verbatim=false.
 Then, I tried the #include macro from Velocity. I renamed my APT file to 
 filename.apt.vm in order to trigger the Velocity processor on it and put the 
 #include line in the file, but, whenever I launch maven site I keep getting 
 this error:
 and the page is not generated.
 Is there a way to fix this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-380) Use of #include in APT page causes NullPointerException during page rendering

2010-02-16 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=210355#action_210355
 ] 

Lukas Theussl commented on DOXIA-380:
-

Using site-plugin 2.1 (ie Doxia-1.1) I get the same error message but the 
resulting index.html is actually correct. Can you confirm?

 Use of #include in APT page causes NullPointerException during page rendering
 -

 Key: DOXIA-380
 URL: http://jira.codehaus.org/browse/DOXIA-380
 Project: Maven Doxia
  Issue Type: Bug
  Components: Site Renderer
 Environment: maven 2.2.1
Reporter: Alan Alberghini
Priority: Minor
 Attachments: apt-include.log, VelocityTest.tar.gz


 In the last 2 days I tried to get this thing working.
 The situation is the following: I'm working on a maven site project and, for 
 some pages, I'm currently using the APT format.
 I'd really like to be able to include existing APT pages inside an APT page, 
 in order to make the collaboration between the 4 members of the project much 
 easier and smoother.
 To give an idea, I'd like to do this:
 merged-page.apt:
   ---
   Title
   ---
   ---
   ---
   Develeper 1 proposal:
   include page 1
   Developer 2 proposal:
   include page 2
   etc.
 At first, I tried using the %snippet DOXIA macro, but the included APT page 
 would not be rendered to HTML even setting verbatim=false.
 Then, I tried the #include macro from Velocity. I renamed my APT file to 
 filename.apt.vm in order to trigger the Velocity processor on it and put the 
 #include line in the file, but, whenever I launch maven site I keep getting 
 this error:
 and the page is not generated.
 Is there a way to fix this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-380) Use of #include in APT page causes NullPointerException during page rendering

2010-02-15 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/DOXIA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=210244#action_210244
]

Lukas Theussl commented on DOXIA-380:
-

Can you attach a test project to reproduce the issue? (Just the velocity case,
the snippet macro behaves as it should).

Use of #include in APT page causes NullPointerException during page rendering
-

[jira] Closed: (MPDF-38) Allow selective report inclusion

2010-02-01 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPDF-38.
-

Resolution: Not A Bug
  Assignee: Lukas Theussl

Inclusion of reports is configured just like for the site plugin, see 
http://maven.apache.org/plugins/maven-pdf-plugin/examples/configuring-reports.html.

 Allow selective report inclusion
 

 Key: MPDF-38
 URL: http://jira.codehaus.org/browse/MPDF-38
 Project: Maven 2.x PDF Plugin
  Issue Type: Improvement
Reporter: Dominik Bartholdi
Assignee: Lukas Theussl

 It would be a big enhancement to allow selective report inclusion to the 
 final PDF. I know there is the flag 'includeReports', but this is a all or 
 nothing flag.
 There are many reports quite interessting for a web report, but some of theme 
 just don't make sence within the PDF because it is just to omutch data for 
 some endusers (e.g. dependency). But on the other hand there are reports 
 needed by some managers (e.g. project-team).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DOXIA-379) Regression: title block isn't parsed in APT file if comment is present before it

2010-01-28 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated DOXIA-379:


Fix Version/s: 1.1.3

 Regression: title block isn't parsed in APT file if comment is present before 
 it
 

 Key: DOXIA-379
 URL: http://jira.codehaus.org/browse/DOXIA-379
 Project: Maven Doxia
  Issue Type: Bug
  Components: Module - Apt
Affects Versions: 1.1.2
Reporter: Marat Radchenko
 Fix For: 1.1.3


 I recently updated to maven-site-plugin-2.1 (which pulled doxia-1.1.2) and 
 suddenly page
 title block stopped working.
 My apt file [1] (didn't change it) now renders as [2].
 Notice no page title and ugly -- About -- Marat Radchenko -- 
 2009-04-09 line at top of page.
 Page starts to render correctly if title block is but before commented 
 license banner, so it becomes a first element.
 [1] 
 http://autodao.git.sourceforge.net/git/gitweb.cgi?p=autodao/autodao;a=blob;f=src/site/apt/index.apt;h=cda99c5a0500b657162c2ac7f6419df334c41771;hb=HEAD#l17
 [2] http://autodao.sourceforge.net/index.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DOXIA-377) Make position of page numbers configurable

2010-01-06 Thread Lukas Theussl (JIRA)

Make position of page numbers configurable
--

 Key: DOXIA-377
 URL: http://jira.codehaus.org/browse/DOXIA-377
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Module - FO
Affects Versions: 1.1.2
Reporter: Lukas Theussl


Page numbers currently always appear on top of a page. We should make the 
layout configurable as far as possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MPDF-37) Make position of page numbers configurable

2010-01-06 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MPDF-37:
--

Summary: Make position of page numbers configurable  (was: how to customize 
the layout?)

The position of page numbers is currently hard-coded in the FoSink, so it's not 
possible to configure it. This needs another Doxia release, see DOXIA-377.

 Make position of page numbers configurable
 --

 Key: MPDF-37
 URL: http://jira.codehaus.org/browse/MPDF-37
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 13:10:27-0600)
 Java version: 1.6.0_16
 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux version: 2.6.26-2-686 arch: i386 Family: unix
Reporter: deckrider

 Our group has a 'standard' that all page numbers should be at the bottom 
 (footer), but the pdf generated has them at the top.
 How can this be customized for our 'standard'?
 By the way, thank you for this plugin, it has already been very useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MCHANGES-172) Bump to Doxia 1.1.2

2010-01-03 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MCHANGES-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MCHANGES-172:
---

Description: Quick patch to upgrade to latest Doxia. However this 
assumes that the plugin will require maven 2.1 (and site-plugin 2.1). If we 
want to stay compatible with maven 2.0.x we have to add some shading, see 
http://maven.apache.org/doxia/developers/maven-integration.html.
Patch Submitted: [Yes]
 Attachment: MCHANGES-172.patch
Summary: Bump to Doxia 1.1.2  (was: Bump to Doxia 1.1.1)

 Bump to Doxia 1.1.2
 ---

 Key: MCHANGES-172
 URL: http://jira.codehaus.org/browse/MCHANGES-172
 Project: Maven 2.x Changes Plugin
  Issue Type: Task
Reporter: Vincent Siveton
 Attachments: MCHANGES-172.patch


 Quick patch to upgrade to latest Doxia. However this assumes that the plugin 
 will require maven 2.1 (and site-plugin 2.1). If we want to stay compatible 
 with maven 2.0.x we have to add some shading, see 
 http://maven.apache.org/doxia/developers/maven-integration.html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-441) head generated at bad place in html (xdoc format)

2009-12-23 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203999#action_203999
 ] 

Lukas Theussl commented on MSITE-441:
-

True it's confusing, but the warning is harmless, it only tells you which title 
is being used actually.

I'd recommend to not use both properties and head, just put the author 
information into a meta tag and remove the properties.

 head generated at bad place in html (xdoc format)
 ---

 Key: MSITE-441
 URL: http://jira.codehaus.org/browse/MSITE-441
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: doxia integration
Affects Versions: 2.1
 Environment: Ubuntu, maven 2.2.1, Java 6
Reporter: Michenaud Laurent
Assignee: Lukas Theussl
 Attachments: msite-441.zip


 Here is a simple test.xml with a head tag.
 ?xml version=1.0 encoding=ISO-8859-1?
 document xmlns=http://maven.apache.org/XDOC/2.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://maven.apache.org/XDOC/2.0 
 http://maven.apache.org/xsd/xdoc-2.0.xsd;
   head
   link href=css/mysite.css type=text/css media=print /
   /head
   body
   section name=Test
   Hello
   /section
   /body
 /document
 In the generated html :
 div id=bodyColumn
   div id=contentBox
 headlink href=css/mysite.css type=text/css 
 media=print/head  = bad position 
   div class=sectionh2a name=Test/aTest/h2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MPDF-36) Cannot include extra images

2009-12-23 Thread Lukas Theussl (JIRA)

Cannot include extra images
---

 Key: MPDF-36
 URL: http://jira.codehaus.org/browse/MPDF-36
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Lukas Theussl


I have a use case where I want to include images in the pdf that are not part 
of the main site. I use the maven-resources-plugin to copy those images (from 
src/main/resources/) to target/pdf/images/ in the pre-site phase. However, 
those images are gone again when I run site (which triggers the pdf), because 
the pdf:pdf goal deletes the whole working directory before starting to work.

I don't know if my problem can be solved differently but I also don't see why 
we delete the workingDirectory at every run, is there a special reason for it?



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MPDF-36) Cannot include extra images

2009-12-23 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPDF-36.
-

   Resolution: Fixed
Fix Version/s: 1.2
 Assignee: Lukas Theussl

Fixed in [r893623|http://svn.apache.org/viewvc?view=revisionrevision=893623]

 Cannot include extra images
 ---

 Key: MPDF-36
 URL: http://jira.codehaus.org/browse/MPDF-36
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.2


 I have a use case where I want to include images in the pdf that are not part 
 of the main site. I use the maven-resources-plugin to copy those images (from 
 src/main/resources/) to target/pdf/images/ in the pre-site phase. However, 
 those images are gone again when I run site (which triggers the pdf), because 
 the pdf:pdf goal deletes the whole working directory before starting to work.
 I don't know if my problem can be solved differently but I also don't see why 
 we delete the workingDirectory at every run, is there a special reason for it?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MSITE-441) head generated at bad place in html (xdoc format)

2009-12-22 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MSITE-441:


Attachment: msite-441.zip

I cannot reproduce that, see attached test project. Are you sure you are using 
site plugin 2.1? Your xdoc above should actually give a validation error 
because a title is required within head.

 head generated at bad place in html (xdoc format)
 ---

 Key: MSITE-441
 URL: http://jira.codehaus.org/browse/MSITE-441
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: doxia integration
Affects Versions: 2.1
 Environment: Ubuntu, maven 2.2.1, Java 6
Reporter: Michenaud Laurent
 Attachments: msite-441.zip


 Here is a simple test.xml with a head tag.
 ?xml version=1.0 encoding=ISO-8859-1?
 document xmlns=http://maven.apache.org/XDOC/2.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://maven.apache.org/XDOC/2.0 
 http://maven.apache.org/xsd/xdoc-2.0.xsd;
   head
   link href=css/mysite.css type=text/css media=print /
   /head
   body
   section name=Test
   Hello
   /section
   /body
 /document
 In the generated html :
 div id=bodyColumn
   div id=contentBox
 headlink href=css/mysite.css type=text/css 
 media=print/head  = bad position 
   div class=sectionh2a name=Test/aTest/h2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MSITE-441) head generated at bad place in html (xdoc format)

2009-12-22 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSITE-441.
---

Resolution: Cannot Reproduce
  Assignee: Lukas Theussl

 head generated at bad place in html (xdoc format)
 ---

 Key: MSITE-441
 URL: http://jira.codehaus.org/browse/MSITE-441
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: doxia integration
Affects Versions: 2.1
 Environment: Ubuntu, maven 2.2.1, Java 6
Reporter: Michenaud Laurent
Assignee: Lukas Theussl
 Attachments: msite-441.zip


 Here is a simple test.xml with a head tag.
 ?xml version=1.0 encoding=ISO-8859-1?
 document xmlns=http://maven.apache.org/XDOC/2.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://maven.apache.org/XDOC/2.0 
 http://maven.apache.org/xsd/xdoc-2.0.xsd;
   head
   link href=css/mysite.css type=text/css media=print /
   /head
   body
   section name=Test
   Hello
   /section
   /body
 /document
 In the generated html :
 div id=bodyColumn
   div id=contentBox
 headlink href=css/mysite.css type=text/css 
 media=print/head  = bad position 
   div class=sectionh2a name=Test/aTest/h2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MSITE-440) Site document validation fails if unable to retrieve schema (in offline mode)

2009-12-22 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MSITE-440:


Fix Version/s: 2.1.1

 Site document validation fails if unable to retrieve schema (in offline mode)
 -

 Key: MSITE-440
 URL: http://jira.codehaus.org/browse/MSITE-440
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: doxia integration
Affects Versions: 2.1
 Environment: Maven 2.2.1
 Site Plugin 2.1-SNAPSHOT
 Doxia 1.1.2
Reporter: Dave Meibusch
Priority: Critical
 Fix For: 2.1.1


 The changes included DOXIA-263 to validate XML documents retrieves the 
 DTD/Schema to validate the document.
 For example, for FML, xsi:schemaLocation=http://maven.apache.org/FML/1.0.1 
 http://maven.apache.org/xsd/fml-1.0.1.xsd; the Doxia FML parser will retrieve 
 http://maven.apache.org/xsd/fml-1.0.1.xsd before validating the document.
 If in offline mode, or in an environment without connectivity to apache.org, 
 site generation will appear to hang until the HTTP client code times out 
 (which is many minutes for each retry) then fail.
 Workaround: remove the schema definition from the document (and lose 
 validation when online and IDE editing support).
 Perhaps each Doxia parser should have some embedded schemas (for FML, at 
 least http://maven.apache.org/FML/1.0.1) so the entities can be resolved 
 locally.
 Or at least a property for disabling document validation.
 I don't think v2.1 can be released with this issue unresolved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MCHANGES-190) HTML in changes.xml stopped working

2009-12-21 Thread Lukas Theussl (JIRA)

[
http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203728#action_203728
]

Lukas Theussl commented on MCHANGES-190:

According to the current changes.xsd schema, the action element in changes.xml
has text content only, ie no markup is allowed inside action. So I think the
current behavior is actually correct. However, wrt to backward compatibility
and functionality, this is not very satisfactory.

Note that in maven 1, the action element could contain arbitrary xdoc markup,
for the announcement only the text content was extracted.

I think the proper solution would be to mimic this behavior, ie generalize the
xsd schema and process the content of changes.xml according to where the output
goes. A configuration parameter seems unnecessary to me, at least you would
have to make it consistent with the xsd.

HTML in changes.xml stopped working
---

[jira] Closed: (DOXIA-374) Xdoc: tables without border attribute get a border

2009-12-20 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/DOXIA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed DOXIA-374.
---

   Resolution: Fixed
Fix Version/s: 1.1.3
 Assignee: Lukas Theussl

Fixed in [r892639|http://svn.apache.org/viewvc?view=revisionrevision=892639]

 Xdoc: tables without border attribute get a border
 

 Key: DOXIA-374
 URL: http://jira.codehaus.org/browse/DOXIA-374
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core, Module - Fml, Module - Xdoc, Module - Xhtml
Affects Versions: 1.1.2
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.1.3


 Xhtml tables without a border attribute render without border by default, - 
 the XhtmlParser inserts a border if no attribute is given.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DOXIA-374) Xdoc: tables without border attribute get a border

2009-12-19 Thread Lukas Theussl (JIRA)

Xdoc: tables without border attribute get a border


 Key: DOXIA-374
 URL: http://jira.codehaus.org/browse/DOXIA-374
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core, Module - Fml, Module - Xdoc, Module - Xhtml
Affects Versions: 1.1.2
Reporter: Lukas Theussl


Xhtml tables without a border attribute render without border by default, - the 
XhtmlParser inserts a border if no attribute is given.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MPDF-34) plugin fails with AbstractMethodError

2009-12-17 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPDF-34.
-

Resolution: Not A Bug
  Assignee: Lukas Theussl

Wendy: please check the reporting plugins you use in continuum against the list 
we have at 
http://maven.apache.org/plugins/maven-pdf-plugin/examples/configuring-reports.html#Maven_Reporting_Plugins_Issues.
 I didn't check in detail but I am sure that some of them are not compatible. 
The report generation works for the cases I checked, eg on the doxia site 
https://svn.apache.org/repos/asf/maven/doxia/site/. But I guess excluding the 
reports as above is what you want anyway.

 plugin fails with AbstractMethodError
 -

 Key: MPDF-34
 URL: http://jira.codehaus.org/browse/MPDF-34
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Maven 2.2.1
 Mac OS X
Reporter: Wendy Smoak
Assignee: Lukas Theussl

 To reproduce, change the pdf plugin version from 1.0 to 1.1 in 
 https://svn.apache.org/repos/asf/continuum/trunk/continuum-docs  
 With 1.0 it works fine.  With 1.1 it fails with:
 $ mvn site -X
 ...
 [FATAL ERROR] org.apache.maven.plugins.pdf.PdfMojo#execute() caused a linkage 
 error (java.lang.AbstractMethodError) and may be out-of-date. Check the 
 realms:
 [FATAL ERROR] Plugin realm = 
 app0.child-container[org.apache.maven.plugins:maven-pdf-plugin:1.1]
 ...
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] null
 [INFO] 
 
 [DEBUG] Trace
 java.lang.AbstractMethodError
   at 
 org.apache.maven.plugins.pdf.PdfMojo.generateMavenReport(PdfMojo.java:1211)
   at 
 org.apache.maven.plugins.pdf.PdfMojo.generateMavenReports(PdfMojo.java:1072)
   at org.apache.maven.plugins.pdf.PdfMojo.generatedPdf(PdfMojo.java:545)
   at org.apache.maven.plugins.pdf.PdfMojo.execute(PdfMojo.java:391)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
   at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
   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.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)
 [INFO] 
 
 [INFO] Total time: 26 seconds
 [INFO] Finished at: Wed Dec 16 14:25:53 MST 2009
 [INFO] Final Memory: 88M/204M
 [INFO] 
 
  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MPDF-32) PDF generation fails due to velocity template error

2009-12-17 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MPDF-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203185#action_203185
 ] 

Lukas Theussl commented on MPDF-32:
---

1.5.1 is too old? Guess what, I was using 1.3.6... :)

Anyway, MPDF-33 was a false alarm, I can reproduce your error.

 PDF generation fails due to velocity template error
 ---

 Key: MPDF-32
 URL: http://jira.codehaus.org/browse/MPDF-32
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Maven 2.0.10 JDK6, XP SP3
Reporter: Michael Osipov
 Attachments: pdf.log


 I was trying to run mvn pdf:pdf and it suddenly failed. See attached log. The 
 failing template works flawlessly with the site goal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MPDF-35) NPE when document descriptor has no meta information

2009-12-17 Thread Lukas Theussl (JIRA)

NPE when document descriptor has no meta information


 Key: MPDF-35
 URL: http://jira.codehaus.org/browse/MPDF-35
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Lukas Theussl


When there is no meta in pdf.xml the build fails with a NPE. The meta tag 
should be optional.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MPDF-35) NPE when document descriptor has no meta information

2009-12-17 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPDF-35.
-

   Resolution: Fixed
Fix Version/s: 1.2
 Assignee: Lukas Theussl

Fixed in [r891591|http://svn.apache.org/viewvc?view=revisionrevision=891591]

 NPE when document descriptor has no meta information
 

 Key: MPDF-35
 URL: http://jira.codehaus.org/browse/MPDF-35
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 1.2


 When there is no meta in pdf.xml the build fails with a NPE. The meta tag 
 should be optional.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MPDF-34) plugin fails with AbstractMethodError

2009-12-17 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MPDF-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203188#action_203188
 ] 

Lukas Theussl commented on MPDF-34:
---

Confirmed. MPDF-26 introduced report generation in the pdf, apparently there is 
a problem. Unfortunately the default was set to always generate reports (it 
should have been optional IMO). You can switch it off as a workaround:

{code:xml}
configuration
  includeReportsfalse/includeReports
/configuration
{code}

 plugin fails with AbstractMethodError
 -

 Key: MPDF-34
 URL: http://jira.codehaus.org/browse/MPDF-34
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Maven 2.2.1
 Mac OS X
Reporter: Wendy Smoak

 To reproduce, change the pdf plugin version from 1.0 to 1.1 in 
 https://svn.apache.org/repos/asf/continuum/trunk/continuum-docs  
 With 1.0 it works fine.  With 1.1 it fails with:
 $ mvn site -X
 ...
 [FATAL ERROR] org.apache.maven.plugins.pdf.PdfMojo#execute() caused a linkage 
 error (java.lang.AbstractMethodError) and may be out-of-date. Check the 
 realms:
 [FATAL ERROR] Plugin realm = 
 app0.child-container[org.apache.maven.plugins:maven-pdf-plugin:1.1]
 ...
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] null
 [INFO] 
 
 [DEBUG] Trace
 java.lang.AbstractMethodError
   at 
 org.apache.maven.plugins.pdf.PdfMojo.generateMavenReport(PdfMojo.java:1211)
   at 
 org.apache.maven.plugins.pdf.PdfMojo.generateMavenReports(PdfMojo.java:1072)
   at org.apache.maven.plugins.pdf.PdfMojo.generatedPdf(PdfMojo.java:545)
   at org.apache.maven.plugins.pdf.PdfMojo.execute(PdfMojo.java:391)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
   at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
   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.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)
 [INFO] 
 
 [INFO] Total time: 26 seconds
 [INFO] Finished at: Wed Dec 16 14:25:53 MST 2009
 [INFO] Final Memory: 88M/204M
 [INFO] 
 
  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MSITE-368) remove copy of reporting-api SinkFactory class

2009-12-16 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSITE-368.
---

Resolution: Fixed
  Assignee: Lukas Theussl

Done in [r890870|http://svn.apache.org/viewvc?view=revisionrevision=890870]. 
Grid seems happy...

 remove copy of reporting-api SinkFactory class
 --

 Key: MSITE-368
 URL: http://jira.codehaus.org/browse/MSITE-368
 Project: Maven 2.x Site Plugin
  Issue Type: Task
  Components: doxia integration
Affects Versions: 2.0-beta-7
Reporter: Herve Boutemy
Assignee: Lukas Theussl
 Fix For: 2.1


 this will force the plugin to have Maven 2.0.8 as a prerequisite, since this 
 interface was added in doxia-sink-api 1.0-alpha-9, in use in Maven 2.0.8

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MPDF-33) Velocity support broken

2009-12-16 Thread Lukas Theussl (JIRA)

Velocity support broken
---

 Key: MPDF-33
 URL: http://jira.codehaus.org/browse/MPDF-33
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Lukas Theussl


MPDF-24 introduced support for velocity files in pdf-plugin-1.1 and if I 
remember correctly this was working at one time. Unfortunately, it seems broken 
in the released final 1.1, see the pdf of the plugin itself: 
http://maven.apache.org/plugins/maven-pdf-plugin/maven-pdf-plugin.pdf

Note the items in the TOC: 'Usage' and 'Configuring Reports' for which no 
content is generated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MPDF-32) PDF generation fails due to velocity template error

2009-12-16 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MPDF-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203035#action_203035
 ] 

Lukas Theussl commented on MPDF-32:
---

First, I got an error checking out your project:

{noformat}
svn: Error parsing svn:externals property on 
'fckeditor/java-demo/src/main/webapp': '-r 4273 ^/FCKeditor/releases/stable/ 
fckeditor'
{noformat}

However, the code got checked out and I could reproduce your error. Then I 
copied your upgrade_notes.apt.vm into a project of mine and I didn't get the 
parsing error. I will check where the difference comes from, but for now I 
stumbled upon MPDF-33, which needs to be fixed first.

 PDF generation fails due to velocity template error
 ---

 Key: MPDF-32
 URL: http://jira.codehaus.org/browse/MPDF-32
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Maven 2.0.10 JDK6, XP SP3
Reporter: Michael Osipov
 Attachments: pdf.log


 I was trying to run mvn pdf:pdf and it suddenly failed. See attached log. The 
 failing template works flawlessly with the site goal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MPDF-33) Velocity support broken

2009-12-16 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MPDF-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MPDF-33.
-

Resolution: Not A Bug

I was too quick,... the published pdf was built with the old 1.0 version, vm 
macros work with the new pdf-plugin-1.1. The pdf on the site should be replaced 
though.

 Velocity support broken
 ---

 Key: MPDF-33
 URL: http://jira.codehaus.org/browse/MPDF-33
 Project: Maven 2.x PDF Plugin
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Lukas Theussl

 MPDF-24 introduced support for velocity files in pdf-plugin-1.1 and if I 
 remember correctly this was working at one time. Unfortunately, it seems 
 broken in the released final 1.1, see the pdf of the plugin itself: 
 http://maven.apache.org/plugins/maven-pdf-plugin/maven-pdf-plugin.pdf
 Note the items in the TOC: 'Usage' and 'Configuring Reports' for which no 
 content is generated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-368) remove copy of reporting-api SinkFactory class

2009-12-15 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=202671#action_202671
 ] 

Lukas Theussl commented on MSITE-368:
-

The only possible problem I see is that the SinkFactory in Doxia 1.1 is not 
identical anymore to the SinkFactory in Doxia 1.0 (which the site plugin has 
copied), some signatures where added for 1.1. However, the site plugin now has 
a prereq on maven 2.1 (using doxia-1.1), so I think at least binary 
compatibility should be ok. I'd remove the class already and see what happens 
on the grid...

 remove copy of reporting-api SinkFactory class
 --

 Key: MSITE-368
 URL: http://jira.codehaus.org/browse/MSITE-368
 Project: Maven 2.x Site Plugin
  Issue Type: Task
  Components: doxia integration
Affects Versions: 2.0-beta-7
Reporter: Herve Boutemy
 Fix For: 2.1


 this will force the plugin to have Maven 2.0.8 as a prerequisite, since this 
 interface was added in doxia-sink-api 1.0-alpha-9, in use in Maven 2.0.8

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MSITE-33) Add a sitemap

2009-12-13 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSITE-33.
--

   Resolution: Fixed
Fix Version/s: 2.1
 Assignee: Lukas Theussl

Done in [r890094|http://svn.apache.org/viewvc?view=revisionrevision=890094]. 
Added a {{generateSitemap}} configuration parameter.

 Add a sitemap
 -

 Key: MSITE-33
 URL: http://jira.codehaus.org/browse/MSITE-33
 Project: Maven 2.x Site Plugin
  Issue Type: New Feature
Reporter: Lukas Theussl
Assignee: Lukas Theussl
 Fix For: 2.1


 Feature implemented in m1 xdoc plugin 1.10 (currently in SVN).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-68) Adding twiki plugin as build extension makes goal site:site fail.

2009-12-10 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=202082#action_202082
 ] 

Lukas Theussl commented on DOXIA-68:


Doxia 1.1.x is not compatible with any (yet) published site/project-info 
plugin. Try the newest twiki module from the 1.0.x branch, it should work as 
per comments above.

 Adding twiki plugin as build extension makes goal site:site fail.
 -

 Key: DOXIA-68
 URL: http://jira.codehaus.org/browse/DOXIA-68
 Project: Maven Doxia
  Issue Type: Bug
  Components: Module - Twiki
Affects Versions: 1.0-alpha-8
 Environment: WinXp, Java5
Reporter: Martin Zeltner
Assignee: Lukas Theussl

 When I add the twiki module as an extension in my pom.xml the goal site:site 
 will fail.
 Extension config snippet:
 --
 build
 extensions
 !-- Site --
 extension
 artifactIddoxia-module-twiki/artifactId
 groupIdorg.apache.maven.doxia/groupId
 version1.0-alpha-9-SNAPSHOT/version
 /extension
 /extensions
 /build
 --
 Console output:
 --
 mvn site:site -X
 + Error stacktraces are turned on.
 Maven version: 2.1-SNAPSHOT
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'site'.
 [INFO] 
 
 [INFO] Building EL4J module core
 [INFO]task-segment: [site:site]
 [INFO] 
 
 [INFO] Setting property: classpath.resource.loader.class = 
 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
 [INFO] Setting property: velocimacro.messages.on = 'false'.
 [INFO] Setting property: resource.loader = 'classpath'.
 [INFO] Setting property: resource.manager.logwhenfound = 'false'.
 [INFO] **
 [INFO] Starting Jakarta Velocity v1.4
 [INFO] RuntimeInstance initializing.
 [INFO] Default Properties File: 
 org\apache\velocity\runtime\defaults\velocity.properties
 [INFO] Default ResourceManager initializing. (class 
 org.apache.velocity.runtime.resource.ResourceManagerImpl)
 [INFO] Resource Loader Instantiated: 
 org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
 [INFO] ClasspathResourceLoader : initialization starting.
 [INFO] ClasspathResourceLoader : initialization complete.
 [INFO] ResourceCache : initialized. (class 
 org.apache.velocity.runtime.resource.ResourceCacheImpl)
 [INFO] Default ResourceManager initialization complete.
 [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
 [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
 [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
 [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
 [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
 [INFO] Created: 20 parsers.
 [INFO] Velocimacro : initialization starting.
 [INFO] Velocimacro : adding VMs from VM library template : 
 VM_global_library.vm
 [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in 
 any resource loader.
 [INFO] Velocimacro : error using  VM library template VM_global_library.vm : 
 org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
 resource 'VM_global_library.vm'
 [INFO] Velocimacro :  VM library template macro registration complete.
 [INFO] Velocimacro : allowInline = true : VMs can be defined inline in 
 templates
 [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may 
 NOT replace previous VM definitions
 [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be  
 global in scope if allowed.
 [INFO] Velocimacro : initialization complete.
 [INFO] Velocity successfully started.
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error getting reports from the plugin 
 'org.apache.maven.plugins:maven-jxr-plugin': Unable to find the mojo 
 'org.apache.maven.plugins:maven-jxr-plugin:2.1-SNAPSHOT:jxr' in the plugin 
 'org.apache
 .maven.plugins:maven-jxr-plugin'
 [INFO] 
 
 [DEBUG] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Error getting reports 
 from the plugin 'org.apache.maven.plugins:maven-jxr-plugin': Unable to find 
 the mojo 'org.apache.maven.plugins:maven-jxr-p
 lugin:2.1-SNAPSHOT:jxr' in the plugin 
 'org.apache.maven.plugins:maven-jxr-plugin'
 at

[jira] Closed: (MSITE-424) Unable to perform release

2009-12-10 Thread Lukas Theussl (JIRA)


 [ 
http://jira.codehaus.org/browse/MSITE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSITE-424.
---

Resolution: Not A Bug

This is a bug tracking system. It is not a bug that a certain version is not 
released yet. If you want to speed things up, you can bug (!) devs on the 
mailing list or IRC, or check yourself what issues are left that prevent a 
release. The more time we spend checking out pointless tickets the less we have 
to work towards your desired release...

 Unable to perform release
 -

 Key: MSITE-424
 URL: http://jira.codehaus.org/browse/MSITE-424
 Project: Maven 2.x Site Plugin
  Issue Type: Task
  Components: doxia integration
Affects Versions: 2.1
Reporter: Malachi de AElfweald
Priority: Blocker

 I am unable to perform a release because I depend on doxia 1.1.1 for 
 DOXIA-309, DOXIA-310 and DOXIA-311
 The last tagged version of the site plugin is 2.0.1 which relies on doxia 1.0
 The current trunk version depends on doxia 1.1.2-SNAPSHOT
 I need a tagged version of the site plugin built against doxia 1.1.1 or later 
 so that I can perform a release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-372) Please add snapshot build for 1.1.3 to repository

2009-12-03 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=200458#action_200458
 ] 

Lukas Theussl commented on DOXIA-372:
-

I thought the official maven snapshot repo was this: 
http://repository.apache.org/snapshots/

The content is the same, ie the snapshots are there, but shouldn't we point 
people to this address?

 Please add snapshot build for 1.1.3 to repository
 -

 Key: DOXIA-372
 URL: http://jira.codehaus.org/browse/DOXIA-372
 Project: Maven Doxia
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.3
Reporter: Dave Syer
Assignee: Olivier Lamy

 Please add snapshot build for 1.1.3 to repository.  Or if this is not the 
 repository:
 {code}
 http://people.apache.org/repo/m2-snapshot-repository
 {code}
 then where is it?  (There are 1.1.2 snapshots there - with no source code.) 
 Please also make sure that the source jars are deployed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-436) regenerate every page when site.xml (direct or parent) is changed

2009-11-25 Thread Lukas Theussl (JIRA)


[ 
http://jira.codehaus.org/browse/MSITE-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199484#action_199484
 ] 

Lukas Theussl commented on MSITE-436:
-

Isn't this a duplicate of MSITE-177 ?

 regenerate every page when site.xml (direct or parent) is changed
 -

 Key: MSITE-436
 URL: http://jira.codehaus.org/browse/MSITE-436
 Project: Maven 2.x Site Plugin
  Issue Type: Improvement
Affects Versions: 2.0.1
Reporter: Herve Boutemy

 currently, if a source file is not modified (apt, xdoc, or any other format), 
 the target HTML page is not generated.
 But when site.xml is modified (or one of the parent site.xml), HTML pages 
 should be regenerated even if sources are not modified. We actually need to 
 mvn clean to get these pages generated again...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

< 2 3 4 5 6 7 8 9 10 11 >

601 - 700 of 1797 matches

Mail list logo