[jira] Commented: (MPXDOC-161) Tabbed browsing for multiprojects (this change involves both the multiproject plugin and xdoc)
[ http://jira.codehaus.org/browse/MPXDOC-161?page=comments#action_58327 ] Ignacio G. Mac Dowell commented on MPXDOC-161: -- Did you find any errors? Is there anything I can do to help out testing with this issue? Tabbed browsing for multiprojects (this change involves both the multiproject plugin and xdoc) -- Key: MPXDOC-161 URL: http://jira.codehaus.org/browse/MPXDOC-161 Project: maven-xdoc-plugin Type: New Feature Versions: 1.9.1 Reporter: Ignacio G. Mac Dowell Attachments: multiproject.patch, tabbed.jpg, xdoc.patch Currently only aggregate navigation is possible on the top level project. It would be nice to be able to generate tabbed browsing. I have successfully done this with only a few changes to both plugins. I have attached a screenshot to see the benefits. If this sounds interesting I'll send the patch. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONTINUUM-574) Checkout failure in Windows
[ http://jira.codehaus.org/browse/CONTINUUM-574?page=comments#action_57419 ] Ignacio G. Mac Dowell commented on CONTINUUM-574: - Hi, this is not a bug. Using cvsnt you need to prefix your root repository location. SCM tokenizes the scm url using ':' so your connection url is not correct as it has more tokens than expected. try to google prefix cvsnt repository best regards, nacho Checkout failure in Windows --- Key: CONTINUUM-574 URL: http://jira.codehaus.org/browse/CONTINUUM-574 Project: Continuum Type: Bug Reporter: clojinted Hello there, I've just set up Continuum but the following command fails to check out the project: mvn -e -DconnectionUrl=scm:cvs:pserver:username:[EMAIL PROTECTED]:f:/cvs-repository:itraxspring scm:checkout -DcheckoutDirectory=itraxspring This is part of the error message: [ERROR] BUILD ERROR [INFO] --- [INFO] Cannot run checkout command : Embedded error: Can't load the scm provider. For input string: f I'm using cvsnt so I logged in manually but the problem still arises. Any help would be greatly appreciated, Ger -- 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: (CONTINUUM-574) Checkout failure in Windows
[ http://jira.codehaus.org/browse/CONTINUUM-574?page=comments#action_57426 ] Ignacio G. Mac Dowell commented on CONTINUUM-574: - Hi, it will save you a lot of headaches to prefix your windows repository location. It's easy and your cvs server will be more unix-like. You'll find help on any other issues that may arise regarding cvs much easier as well. If you are using the latest cvsnt version, repositories are given a unix-like name (without f: in your case) by default. In other versions is simple as well. If you need further assistance don't hesitate to contact me privately. best regards nacho Checkout failure in Windows --- Key: CONTINUUM-574 URL: http://jira.codehaus.org/browse/CONTINUUM-574 Project: Continuum Type: Bug Reporter: clojinted Hello there, I've just set up Continuum but the following command fails to check out the project: mvn -e -DconnectionUrl=scm:cvs:pserver:username:[EMAIL PROTECTED]:f:/cvs-repository:itraxspring scm:checkout -DcheckoutDirectory=itraxspring This is part of the error message: [ERROR] BUILD ERROR [INFO] --- [INFO] Cannot run checkout command : Embedded error: Can't load the scm provider. For input string: f I'm using cvsnt so I logged in manually but the problem still arises. Any help would be greatly appreciated, Ger -- 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: (MPXDOC-161) Tabbed browsing for multiprojects (this change involves both the multiproject plugin and xdoc)
[ http://jira.codehaus.org/browse/MPXDOC-161?page=all ] Ignacio G. Mac Dowell updated MPXDOC-161: - Attachment: xdoc.patch multiproject.patch While it was easy to implement via maven.xml, it has been quite a bit of a headache to get it working with plugins due to problems with scope (I suppose this may sound familiar...). These changes have no side effects and should be unnoticeable if maven.multiproject.navigagion is set to tabs (as long as no other plugin defines a property called mpmultiprojects). I was thinking of having the following properties: #this would be the label shown in each tab maven.multiproject.navigation.tabs.label=artifactId | name #should we include the top-level project in the tabs? Currently it always is maven.multiproject.navigation.tabs.includeTop=true | false best regards nacho PD: The linkcheck report on each subproject is going to complain because the subprojects haven't been built where they should have, so all links from the tabs will fail until they are moved to their correct place. Tabbed browsing for multiprojects (this change involves both the multiproject plugin and xdoc) -- Key: MPXDOC-161 URL: http://jira.codehaus.org/browse/MPXDOC-161 Project: maven-xdoc-plugin Type: New Feature Versions: 1.9.1 Reporter: Ignacio G. Mac Dowell Attachments: multiproject.patch, tabbed.jpg, xdoc.patch Currently only aggregate navigation is possible on the top level project. It would be nice to be able to generate tabbed browsing. I have successfully done this with only a few changes to both plugins. I have attached a screenshot to see the benefits. If this sounds interesting I'll send the patch. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPMULTIPROJECT-57) When building the whole multiproject site, build each subproject in its correct directory instead of moving everything at the end (which may be very slow)
[ http://jira.codehaus.org/browse/MPMULTIPROJECT-57?page=all ]
Ignacio G. Mac Dowell closed MPMULTIPROJECT-57:
---
Resolution: Won't Fix
This seems to have quite unexpected side effects on some reports
When building the whole multiproject site, build each subproject in its
correct directory instead of moving everything at the end (which may be very
slow)
--
Key: MPMULTIPROJECT-57
URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-57
Project: maven-multiproject-plugin
Type: Improvement
Reporter: Ignacio G. Mac Dowell
Currently when building a multiproject site, each subproject's site is built
in its own target directory and moved at the end of this process. It'd be
nice to (at least) have the ability of generating each subsite in the
apropiate directory. IMHO this should be the default. Think of moving
thousands of xref, javadocs ...
The solution is really simple. On goal multiproject:site-init set a property:
j:set var=multiprojectBasedir value=${maven.docs.dest} scope=parent/
then on goal xdoc:init
j:if test=${multiprojectBasedir != null}
j:set var=maven.docs.dest
value=${multiprojectBasedir}/${maven.multiproject.aggregateDir}${pom.artifactId}
/
/j:if
then on goal multiproject:site stop moving all directories
If this sounds reasonable I'll send both patches.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-131) allow i18n links
[ http://jira.codehaus.org/browse/MPXDOC-131?page=comments#action_45627 ]
Ignacio G. Mac Dowell commented on MPXDOC-131:
--
If i run test03, test04 and the multiproject test against the patched plugin, I
do get the desired results.
Are you running the tests against the patched plugin? Another alternative to
test is to change maven.xdoc.jsl since it is the only important file that this
patch changes (a part from docs and tests).
allow i18n links
Key: MPXDOC-131
URL: http://jira.codehaus.org/browse/MPXDOC-131
Project: maven-xdoc-plugin
Type: Improvement
Reporter: Ignacio G. Mac Dowell
Attachments: hrefkey.patch, last.cumulative.patch, last.docs.patch,
last.main.patch, last.test.patch, plugin.jelly.patch, plugin.properties.patch
Currently, we can't directly use the pom or velocity in user-documentation.
JSL is applied to the user-docs as-is. I suggest having a property called
maven.docs.src.templates (defaults to false) that when set to true treats
user-docs as templates.
Then, slightly modify the goal xdoc:jelly-transform.
We need to var's:
j:set var=mergeUserDocs value=${maven.docs.src.templates}/
j:set var=hasUserDocs value=${maven.docs.src.available}/
If both evaluate to true then velocity:merge the user docs before doing jsl.
If they evaluate to false do as before.
It would probably be nice to be able to use jelly as well as user-supplied
docs.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPMULTIPROJECT-57) When building the whole multiproject site, build each subproject in its correct directory instead of moving everything at the end (which may be very slow)
When building the whole multiproject site, build each subproject in its correct
directory instead of moving everything at the end (which may be very slow)
--
Key: MPMULTIPROJECT-57
URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-57
Project: maven-multiproject-plugin
Type: Improvement
Reporter: Ignacio G. Mac Dowell
Currently when building a multiproject site, each subproject's site is built in
its own target directory and moved at the end of this process. It'd be nice to
(at least) have the ability of generating each subsite in the apropiate
directory. IMHO this should be the default. Think of moving thousands of xref,
javadocs ...
The solution is really simple. On goal multiproject:site-init set a property:
j:set var=multiprojectBasedir value=${maven.docs.dest} scope=parent/
then on goal xdoc:init
j:if test=${multiprojectBasedir != null}
j:set var=maven.docs.dest
value=${multiprojectBasedir}/${maven.multiproject.aggregateDir}${pom.artifactId}
/
/j:if
then on goal multiproject:site stop moving all directories
If this sounds reasonable I'll send both patches.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPLINKCHECK-23) Improve linkcheck performance (2x+) getting rid of jtidy dependency via regexps
Improve linkcheck performance (2x+) getting rid of jtidy dependency via regexps --- Key: MPLINKCHECK-23 URL: http://jira.codehaus.org/browse/MPLINKCHECK-23 Project: maven-linkcheck-plugin Type: Improvement Versions: 1.3.4 Reporter: Ignacio G. Mac Dowell Attachments: linkcheck.patch At the moment, the linkcheck plugin uses jtidy and xpath for retreiving all links. IMHO regexps would work much faster/better than jtidy-xpath combination. The following regexp would be a replacement for the xpath expressions: (?link|a|img|script)[^]*?(?href|src)\s*?=\s*?[\'](.*?)[\'][^]*? All tests pass with this regexp and in project ws-jaxme I am getting these results for maven-linkcheck-plugin:clearcache maven-linkcheck-plugin:report-real: with jtidy/xpath: Total time: 2 minutes 43 seconds with regexps: Total time: 1 minutes 10 seconds I am sure some regexp guru can improve the performance of this. I have a question, though. Are mailto links supposed to count as checkable? IMO no. PD: Also, IMO the createDocument method from LinkCheck should be on a try finally block. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPXDOC-161) Tabbed browsing for multiprojects (this change involves both the multiproject plugin and xdoc)
Tabbed browsing for multiprojects (this change involves both the multiproject plugin and xdoc) -- Key: MPXDOC-161 URL: http://jira.codehaus.org/browse/MPXDOC-161 Project: maven-xdoc-plugin Type: New Feature Versions: 1.9.1 Reporter: Ignacio G. Mac Dowell Attachments: tabbed.jpg Currently only aggregate navigation is possible on the top level project. It would be nice to be able to generate tabbed browsing. I have successfully done this with only a few changes to both plugins. I have attached a screenshot to see the benefits. If this sounds interesting I'll send the patch. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-108) setting maven.xdoc.jsl does not work with multiproject
[ http://jira.codehaus.org/browse/MPXDOC-108?page=comments#action_45102 ]
Ignacio G. Mac Dowell commented on MPXDOC-108:
--
Don't worry!
Maybe you could close it? ;-)
setting maven.xdoc.jsl does not work with multiproject
--
Key: MPXDOC-108
URL: http://jira.codehaus.org/browse/MPXDOC-108
Project: maven-xdoc-plugin
Type: Bug
Versions: 1.7.1
Environment: WinXP German, Cygwin, Maven 1.0 RC3
Reporter: Joerg Schaible
You cannot use a modified site.jsl for all projects in a multiproject
environment. The value of the property is always interpreted as relative file
name to the directory where the site goal was invoked. Example:
root
+- sub1/*
+- sub2/*
+- site.jsl
+- project.properties
You can set maven.xdoc.jsl=site.jsl in project.properties to build
multiproject:site, but calling site in one of the subprojects fails, because
site.jsl is not found (value inherited in RC3). Setting
maven.xdoc.jsl=${maven.multiproject.basedir}/site.jsl fails also, because the
plugin internally prepends ${basedir} resulting in an invalid filename:
BUILD FAILED
org.apache.commons.jelly.JellyException: null:-1:-1: null Could not parse
Jelly script
at
org.apache.commons.jelly.JellyContext.compileScript(JellyContext.java:491)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:608)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:584)
at
org.apache.commons.jelly.tags.core.IncludeTag.doTag(IncludeTag.java:143)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.FileTag.writeBody(FileTag.java:207)
at org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.java:110)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
[jira] Updated: (MPXDOC-150) maven.xdoc.date.format does not seem to have any effect?
[ http://jira.codehaus.org/browse/MPXDOC-150?page=all ] Ignacio G. Mac Dowell updated MPXDOC-150: - Attachment: MPXDOC-150.patch IMO this bug was introduced with i18n. This patch solves the issue. If a date pattern is specified then the date is formatted according to this pattern and the current locale being processed. If no date pattern (empty maven.xdoc.date.format) is specified it just does a long dateStyle formatting (as before the patch). In other words if we are generating 'en' docs we'd get: August 24, 2005 12:13:36 PM When generating 'fr' docs we'd get: 24 août 2005 12:13:36 This patch is against svn trunk PD: IMHO maven.xdoc.date.locale should be deprecated. The date locale should be the same than the whole xdoc locale. This property was introduced before i18n. maven.xdoc.date.format does not seem to have any effect? Key: MPXDOC-150 URL: http://jira.codehaus.org/browse/MPXDOC-150 Project: maven-xdoc-plugin Type: Bug Versions: 1.9 Environment: XP Reporter: Benoit Xhenseval Fix For: 1.9.2 Attachments: MPXDOC-150.patch Hello I believe that the maven.xdoc.date.format property put in my project.properties file has no effect. Regardless of what I put there, the date format seems to be: June 22, 2005 9:04:09 PM BST despite having: maven.xdoc.date.format=dd MMM HH:mm z The properties file is taken into account as I can change where the date is: maven.xdoc.date=left or maven.xdoc.date=right Thanks Benoit -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-23) Provide a way to exclude some XML files from xdoc transformation
[ http://jira.codehaus.org/browse/MPXDOC-23?page=comments#action_45106 ] Ignacio G. Mac Dowell commented on MPXDOC-23: - You can do that putting in your project.properties file the following: maven.xdoc.xml.copy=[COMMA SEPARATED ANT PATTERNS TO YOUR XML FILES] the files matching your patterns will be copied with no transformation. See: http://maven.apache.org/reference/plugins/xdoc/properties.html If you are happy with the explanation, please close the bug. Provide a way to exclude some XML files from xdoc transformation Key: MPXDOC-23 URL: http://jira.codehaus.org/browse/MPXDOC-23 Project: maven-xdoc-plugin Type: Improvement Reporter: Jeff French Priority: Minor Sometimes we have XML files that are used as examples in the documentation, but are not documents to be transformed themselves. It would help if we could specify files in a property or file set to exclude from transformation. Those files would just be copied over like non-XML files currently are. A workaround I found is to rename those XML files to *.xxml. Then they get copied over without transformation. You just need to make sure that other documents refer to the new name. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-108) setting maven.xdoc.jsl does not work with multiproject
[ http://jira.codehaus.org/browse/MPXDOC-108?page=comments#action_45008 ]
Ignacio G. Mac Dowell commented on MPXDOC-108:
--
It doesn't matter if you use one site.jsl or two. The main thing is that you
need to set the file path as a file url for maven to know you are expecting an
absolute path.
Considering your layout is:
root
+- sub1/
+-project.xml
+- sub2/*
+-project.xml
+- site.jsl
+- project.properties
You should have a project.properties in each subproject or if you create a
project.xml on the top level directory and let the subprojects inherit from
them you could have a single project.properties. In each case you need to have
a line like this:
maven.xdoc.jsl=file:${basedir}/../site.jsl
and it will work.
BTW, I'd suggest (as the docs do) that you have a common-build (or whatever)
directory to host your common pom and properties file.
setting maven.xdoc.jsl does not work with multiproject
--
Key: MPXDOC-108
URL: http://jira.codehaus.org/browse/MPXDOC-108
Project: maven-xdoc-plugin
Type: Bug
Versions: 1.7.1
Environment: WinXP German, Cygwin, Maven 1.0 RC3
Reporter: Joerg Schaible
You cannot use a modified site.jsl for all projects in a multiproject
environment. The value of the property is always interpreted as relative file
name to the directory where the site goal was invoked. Example:
root
+- sub1/*
+- sub2/*
+- site.jsl
+- project.properties
You can set maven.xdoc.jsl=site.jsl in project.properties to build
multiproject:site, but calling site in one of the subprojects fails, because
site.jsl is not found (value inherited in RC3). Setting
maven.xdoc.jsl=${maven.multiproject.basedir}/site.jsl fails also, because the
plugin internally prepends ${basedir} resulting in an invalid filename:
BUILD FAILED
org.apache.commons.jelly.JellyException: null:-1:-1: null Could not parse
Jelly script
at
org.apache.commons.jelly.JellyContext.compileScript(JellyContext.java:491)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:608)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:584)
at
org.apache.commons.jelly.tags.core.IncludeTag.doTag(IncludeTag.java:143)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.FileTag.writeBody(FileTag.java:207)
at org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.java:110)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
[jira] Updated: (MPJAVA-38) sourceModifications handled incorrectly when more than one clause present
[ http://jira.codehaus.org/browse/MPJAVA-38?page=all ]
Ignacio G. Mac Dowell updated MPJAVA-38:
Attachment: sourceModifications.patch
I came across this same problem...
Truly, ant:available is working as expected. Quoting
http://ant.apache.org/manual/CoreTasks/available.html
If the resource is present, the property value is set to true by default;
otherwise, the property is bnot set/b
I tried to reset the value through ant:property and it doesn't work. What does
work is using the jelly core tag:
j:set var=classPresent value=/
before each invocation of ant:available
Simple, but not very elegant... If someother way is proposed (via
j:invokeStatic or something like that) I can provide patches. IMHO this issue
is critical if you have more than one sourceModification.
Patch attached.
sourceModifications handled incorrectly when more than one clause present
-
Key: MPJAVA-38
URL: http://jira.codehaus.org/browse/MPJAVA-38
Project: maven-java-plugin
Type: Bug
Versions: 1.5
Reporter: Simon Kitching
Attachments: sourceModifications.patch
The loop
j:forEach var=sm items=${pom.build.sourceModifications}
ant:available property=classPresent classname=${sm.className}/
is flawed. When the class is not present, the available action does NOT
reset $classPresent to a false value; instead, its previous value is left
unaltered (ie is the value from the previous time around the loop).
So a sourceModified clause with a classname that is present will cause all
following sourceModified clauses to be skipped, regardless of whether their
test class is present or not.
The following ant file demonstrates this nicely:
project name=foo default=def basedir=.
target name=def
echoav: ${av}/echo
available property=av classname=dafasfas/
echoav: ${av}/echo
available property=av classname=java.lang.String/
echoav: ${av}/echo
available property=av classname=no.such.class/
echoav: ${av}/echo
/target
/project
perhaps simply inserting an assignment to reset the variable to false
immediately before the ant:available test will 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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-108) setting maven.xdoc.jsl does not work with multiproject
[ http://jira.codehaus.org/browse/MPXDOC-108?page=comments#action_44922 ]
Ignacio G. Mac Dowell commented on MPXDOC-108:
--
Trying using:
maven.xdoc.jsl=file:${basedir}/[YOUR PATH HERE]
see: http://maven.apache.org/reference/plugins/xdoc/properties.html
and jump to maven.xdoc.jsl
The problem is that if you don't use the file: it goes relative...
At least with maven 1.0.2 this works
setting maven.xdoc.jsl does not work with multiproject
--
Key: MPXDOC-108
URL: http://jira.codehaus.org/browse/MPXDOC-108
Project: maven-xdoc-plugin
Type: Bug
Versions: 1.7.1
Environment: WinXP German, Cygwin, Maven 1.0 RC3
Reporter: Joerg Schaible
You cannot use a modified site.jsl for all projects in a multiproject
environment. The value of the property is always interpreted as relative file
name to the directory where the site goal was invoked. Example:
root
+- sub1/*
+- sub2/*
+- site.jsl
+- project.properties
You can set maven.xdoc.jsl=site.jsl in project.properties to build
multiproject:site, but calling site in one of the subprojects fails, because
site.jsl is not found (value inherited in RC3). Setting
maven.xdoc.jsl=${maven.multiproject.basedir}/site.jsl fails also, because the
plugin internally prepends ${basedir} resulting in an invalid filename:
BUILD FAILED
org.apache.commons.jelly.JellyException: null:-1:-1: null Could not parse
Jelly script
at
org.apache.commons.jelly.JellyContext.compileScript(JellyContext.java:491)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:608)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:584)
at
org.apache.commons.jelly.tags.core.IncludeTag.doTag(IncludeTag.java:143)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.FileTag.writeBody(FileTag.java:207)
at org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.java:110)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at
[jira] Updated: (MPXDOC-131) Allow velocity in user-documentation and expose pom
[ http://jira.codehaus.org/browse/MPXDOC-131?page=all ]
Ignacio G. Mac Dowell updated MPXDOC-131:
-
Attachment: hrefkey.patch
Support for i18n links. Tests and docs included. It might be nice to have them
for the item elements in navigation.xml as well. If you think it's worth it
I'll send a patch as well.
Anyway, I've seen that you can use your own jsl so if there is not much
interest in this issue I can deal with it. That said, IMHO it is interesting to
have i18n links.
Thanks
nacho
Allow velocity in user-documentation and expose pom
---
Key: MPXDOC-131
URL: http://jira.codehaus.org/browse/MPXDOC-131
Project: maven-xdoc-plugin
Type: Improvement
Reporter: Ignacio G. Mac Dowell
Assignee: Arnaud Heritier
Attachments: hrefkey.patch, last.cumulative.patch, last.docs.patch,
last.main.patch, last.test.patch, plugin.jelly.patch, plugin.properties.patch
Currently, we can't directly use the pom or velocity in user-documentation.
JSL is applied to the user-docs as-is. I suggest having a property called
maven.docs.src.templates (defaults to false) that when set to true treats
user-docs as templates.
Then, slightly modify the goal xdoc:jelly-transform.
We need to var's:
j:set var=mergeUserDocs value=${maven.docs.src.templates}/
j:set var=hasUserDocs value=${maven.docs.src.available}/
If both evaluate to true then velocity:merge the user docs before doing jsl.
If they evaluate to false do as before.
It would probably be nice to be able to use jelly as well as user-supplied
docs.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
