[jira] Commented: (DOXIA-398) TOC for .confluence doesn't seem to work
[
http://jira.codehaus.org/browse/DOXIA-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231657#action_231657
]
Nathan Sowatskey commented on DOXIA-398:
http://jira.codehaus.org/browse/DOXIA-402 has been fixed.
So, I am just left with the lack of TOC, and the linkable sections that I hope
will derive from that.
I will hang fire on giving up entirely until someone with Confluence knowledge
can comment.
> TOC for .confluence doesn't seem to work
>
>
> Key: DOXIA-398
> URL: http://jira.codehaus.org/browse/DOXIA-398
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.1.3
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Nathan Sowatskey
> Attachments: toc_test_case.zip
>
>
> Please see attached test case.
> The {toc} macro in the index.confluence doesn't seem to work. There is no TOC
> produced, just the literal text of the toc macro itself.
--
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-402) Multi-module project with .confluence content does not work
[ http://jira.codehaus.org/browse/DOXIA-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231656#action_231656 ] Nathan Sowatskey commented on DOXIA-402: Many thanks for that. For my larger project that exhibited the original problem, I did have the additional dependency for the confluence extension in my module pom.xml, but *not* in the parent, so the results I was trying to generalise were badly configured. For the record, I now have this in the parent pom or my larger project: org.apache.maven.plugins maven-site-plugin 2.1.1 org.apache.maven.doxia doxia-core 1.1.3 org.apache.maven.doxia doxia-module-confluence 1.1.3 Hopefully this will help the next person who stumbles down this path :-) > Multi-module project with .confluence content does not work > --- > > Key: DOXIA-402 > URL: http://jira.codehaus.org/browse/DOXIA-402 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.1.3 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_20 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac" >Reporter: Nathan Sowatskey >Priority: Blocker > Attachments: apt-site-test.zip, confluence-site-test.zip > > > There are two projects attached. > The apt-site-test has the parent content in apt format. When building a > multi-module project the content in the apt-site-test appears as expected. > The confluence-site-test has the parent content in confluence format. That > content does not appear as expected. Instead a generic "about" page is > created. -- 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-481) Deploy site:deploy not working for maven 3 for DAV
[
http://jira.codehaus.org/browse/MSITE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231636#action_231636
]
Olivier Lamy commented on MSITE-481:
first patche committed in rev 984263.
Tested with dav without proxy and with scp
If someone has time to test scpexe and dav with proxy ?
> Deploy site:deploy not working for maven 3 for DAV
> --
>
> Key: MSITE-481
> URL: http://jira.codehaus.org/browse/MSITE-481
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0-beta-1
> Environment: Using 3.0.0-beta-1-SNAPSHOT of site plugin and maven
> 3.0.0-beta-1 (snapshot version from 5/3).
>Reporter: Eric Berry
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 3.0-beta-2
>
>
> Sorry if this is not where this goes.
> I include this in my pom
>
>
> org.apache.maven.wagon
> wagon-webdav-jackrabbit
> 1.0-beta-6
>
>
> There seems to be a conflict between this extension and
>
>
>
> org.apache.maven.plugins
>
> maven-project-info-reports-plugin
> 2.2
> I get an error saying that there are two versions of
> org.apache.commons.logging.LogFactory in the ClassLoader.
> I fixed this problem by modifying the wagon-webdav-jackrabbit pom to exlcude
> commons-logging from its dependencies and specified a dependency on
> commons-logging-1.1.1. So that is problem number 1.
> At that point when I tried to deploy my site, I get this error:
> Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer
> file: https://vmswdev1/product-sites/config/SNAPSHOT/./css/maven-base.css.
> Return code is: 401
> My site distribtion management setting is:
>
> sweng-projects
>
> dav+https://${webdavserver.hostname}/config/${product-sites.version}
>
> My server setting in settings.xml is (actual values replaced with ***):
>
> sweng-projects
>
>
>
> Problem number 2 is that site:deploy does not seem to using the
> username/password info from settings.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-481) Deploy site:deploy not working for maven 3 for DAV
[
http://jira.codehaus.org/browse/MSITE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231635#action_231635
]
Olivier Lamy commented on MSITE-481:
I don't follow you here ? you mean removing call of connect method ?
Could provide a patch with what works for you ?
Thanks
> Deploy site:deploy not working for maven 3 for DAV
> --
>
> Key: MSITE-481
> URL: http://jira.codehaus.org/browse/MSITE-481
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0-beta-1
> Environment: Using 3.0.0-beta-1-SNAPSHOT of site plugin and maven
> 3.0.0-beta-1 (snapshot version from 5/3).
>Reporter: Eric Berry
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 3.0-beta-2
>
>
> Sorry if this is not where this goes.
> I include this in my pom
>
>
> org.apache.maven.wagon
> wagon-webdav-jackrabbit
> 1.0-beta-6
>
>
> There seems to be a conflict between this extension and
>
>
>
> org.apache.maven.plugins
>
> maven-project-info-reports-plugin
> 2.2
> I get an error saying that there are two versions of
> org.apache.commons.logging.LogFactory in the ClassLoader.
> I fixed this problem by modifying the wagon-webdav-jackrabbit pom to exlcude
> commons-logging from its dependencies and specified a dependency on
> commons-logging-1.1.1. So that is problem number 1.
> At that point when I tried to deploy my site, I get this error:
> Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer
> file: https://vmswdev1/product-sites/config/SNAPSHOT/./css/maven-base.css.
> Return code is: 401
> My site distribtion management setting is:
>
> sweng-projects
>
> dav+https://${webdavserver.hostname}/config/${product-sites.version}
>
> My server setting in settings.xml is (actual values replaced with ***):
>
> sweng-projects
>
>
>
> Problem number 2 is that site:deploy does not seem to using the
> username/password info from settings.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] Closed: (MSITE-494) deploying with weddav doesn't work
[ http://jira.codehaus.org/browse/MSITE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSITE-494. -- Resolution: Duplicate Fix Version/s: (was: 3.0-beta-2) duplicate with MSITE-481 > deploying with weddav doesn't work > -- > > Key: MSITE-494 > URL: http://jira.codehaus.org/browse/MSITE-494 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 3.0-beta-1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > -- 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-494) deploying with weddav doesn't work
[ http://jira.codehaus.org/browse/MSITE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSITE-494: --- Fix Version/s: 3.0-beta-2 Assignee: Olivier Lamy > deploying with weddav doesn't work > -- > > Key: MSITE-494 > URL: http://jira.codehaus.org/browse/MSITE-494 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 3.0-beta-1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.0-beta-2 > > -- 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-481) Deploy site:deploy not working for maven 3 for DAV
[
http://jira.codehaus.org/browse/MSITE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MSITE-481:
---
Priority: Critical (was: Major)
Fix Version/s: 3.0-beta-2
Assignee: Olivier Lamy
> Deploy site:deploy not working for maven 3 for DAV
> --
>
> Key: MSITE-481
> URL: http://jira.codehaus.org/browse/MSITE-481
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0-beta-1
> Environment: Using 3.0.0-beta-1-SNAPSHOT of site plugin and maven
> 3.0.0-beta-1 (snapshot version from 5/3).
>Reporter: Eric Berry
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 3.0-beta-2
>
>
> Sorry if this is not where this goes.
> I include this in my pom
>
>
> org.apache.maven.wagon
> wagon-webdav-jackrabbit
> 1.0-beta-6
>
>
> There seems to be a conflict between this extension and
>
>
>
> org.apache.maven.plugins
>
> maven-project-info-reports-plugin
> 2.2
> I get an error saying that there are two versions of
> org.apache.commons.logging.LogFactory in the ClassLoader.
> I fixed this problem by modifying the wagon-webdav-jackrabbit pom to exlcude
> commons-logging from its dependencies and specified a dependency on
> commons-logging-1.1.1. So that is problem number 1.
> At that point when I tried to deploy my site, I get this error:
> Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer
> file: https://vmswdev1/product-sites/config/SNAPSHOT/./css/maven-base.css.
> Return code is: 401
> My site distribtion management setting is:
>
> sweng-projects
>
> dav+https://${webdavserver.hostname}/config/${product-sites.version}
>
> My server setting in settings.xml is (actual values replaced with ***):
>
> sweng-projects
>
>
>
> Problem number 2 is that site:deploy does not seem to using the
> username/password info from settings.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] Created: (MSITE-494) deploying with weddav doesn't work
deploying with weddav doesn't work -- Key: MSITE-494 URL: http://jira.codehaus.org/browse/MSITE-494 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 3.0-beta-1 Reporter: Olivier Lamy -- 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: (MNG-4759) Allow --global-settings target arbitrary resources, e.g. scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml
[ http://jira.codehaus.org/browse/MNG-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231617#action_231617 ] jieryn commented on MNG-4759: - This last proposal made by Oliver is a good compromise, especially in light of Benjamin's comment. > Allow --global-settings target arbitrary resources, e.g. > scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml > --- > > Key: MNG-4759 > URL: http://jira.codehaus.org/browse/MNG-4759 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Command Line >Reporter: jieryn > -- 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: (MNG-4759) Allow --global-settings target arbitrary resources, e.g. scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml
[
http://jira.codehaus.org/browse/MNG-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231616#action_231616
]
Olivier Lamy commented on MNG-4759:
---
something more appropriate/easy
{code}
mvn --global-settings http://repo.acme.com/infrastructure/maven/settings.xml
clean install
{code}
> Allow --global-settings target arbitrary resources, e.g.
> scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml
> ---
>
> Key: MNG-4759
> URL: http://jira.codehaus.org/browse/MNG-4759
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Command Line
>Reporter: jieryn
>
--
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] Reopened: (MNG-4759) Allow --global-settings target arbitrary resources, e.g. scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml
[ http://jira.codehaus.org/browse/MNG-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jieryn reopened MNG-4759: - For distributed builds which are utilizing clustered continuous integration (like Hudson), it is quite handy to have all slaves utilizing the same settings.xml file. The problem then becomes how to reliably get the settings.xml to slave node without requiring explicit configuration of those slaves. It would be far easier if I could store a Maven settings.xml file in some SCM and point to it via standard Maven URI of such a resource. An example command line invocation might look like: $ mvn --global-settings scm:svn:http://repo.acme.com/infrastructure/maven/settings.xml clean install This would cause Maven to fetch settings.xml from SCM and use it for subsequent clean and install goal execution. The main issue I'm facing presently is that dynamically provisioned slave resources do not automatically mirrOf * to our corporate MRM. Maven already supports a --global-settings configuration switch, I just would like it to be enhanced to be more robust in what it accepts. > Allow --global-settings target arbitrary resources, e.g. > scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml > --- > > Key: MNG-4759 > URL: http://jira.codehaus.org/browse/MNG-4759 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Command Line >Reporter: jieryn > -- 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: (MNG-4759) Allow --global-settings target arbitrary resources, e.g. scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml
[ http://jira.codehaus.org/browse/MNG-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231614#action_231614 ] Benjamin Bentmann commented on MNG-4759: This would require to shove Maven SCM into Maven core which doesn't look appealing. > Allow --global-settings target arbitrary resources, e.g. > scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml > --- > > Key: MNG-4759 > URL: http://jira.codehaus.org/browse/MNG-4759 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Command Line >Reporter: jieryn > -- 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: (MNG-4759) Allow --global-settings target arbitrary resources, e.g. scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml
[ http://jira.codehaus.org/browse/MNG-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-4759. -- Resolution: Incomplete I have no idea what you mean. Reopen the issue when you can provide an explanation. > Allow --global-settings target arbitrary resources, e.g. > scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml > --- > > Key: MNG-4759 > URL: http://jira.codehaus.org/browse/MNG-4759 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Command Line >Reporter: jieryn > -- 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: (MNG-4759) Allow --global-settings target arbitrary resources, e.g. scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml
Allow --global-settings target arbitrary resources, e.g. scm:svn:http://svn.acme.com/infra/trunk/maven/settings.xml --- Key: MNG-4759 URL: http://jira.codehaus.org/browse/MNG-4759 Project: Maven 2 & 3 Issue Type: New Feature Components: Command Line Reporter: jieryn -- 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] Reopened: (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[
http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen reopened MDEP-259:
--
Sorry Brian, but I have to reopen the issue because your analysis is incomplete:
1. It's not a problem in Maven Core. Maven Core works as designed and the
dependency plugin has to take into account how Maven works. The problem is that
the dependency plugin makes the assumption that Artifact#getFile() always
refers to a plain file and not to a directory. That assumption is wrong, and
the minimum would be to add a check and fail the build with a meaningful error
message if the artifact refers to a directory.
2. Your enumeration of the possible solutions/workarounds suggests that you
neither read the full description of the issue, nor did you have a look at the
patch. What I suggest is to "replace the original Artifact object by a new one
resolved from the repository (which would then refer to the artifact generated
by a previous build, exactly as in the mvn generate-resources case)" if the
original Artifact refers to a directory.
BTW, I used that approach successfully in a plugin I wrote specifically for
Axis2, which does something quite similar to the dependency plugin, but for a
highly specialized use case (namely generating an Axis2 repository based on the
project dependencies of type aar and mar). See [1].
[1]
https://svn.apache.org/repos/asf/axis/axis2/java/core/trunk/modules/tool/axis2-repo-maven-plugin/src/main/java/org/apache/axis2/maven2/repo/AbstractCreateRepositoryMojo.java
> copy-dependencies fails with "Error copying artifact from .../target/classes
> to .../classes"
>
>
> Key: MDEP-259
> URL: http://jira.codehaus.org/browse/MDEP-259
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies
>Affects Versions: 2.0, 2.1
> Environment: Maven 2.0.9
> maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
>Reporter: Andreas Veithen
>Assignee: Brian Fox
> Attachments: patch.txt, test-project.zip
>
>
> Scenario:
> * dependency:copy-dependencies is used to copy a dependency artifact that is
> part of the same multi-module build.
> * The compile phase is executed, but not the package phase.
> An example of this scenario is using maven-eclipse-plugin to import a Maven
> project with generated test (re)sources. In this case, one would execute "mvn
> generate-test-resources eclipse:eclipse" to make sure that the generated
> (re)sources are imported into the workspace (by default, maven-eclipse-plugin
> executes generate-sources and generate-resources, but not
> generate-test-sources and generate-test-resources).
> Result: The build fails with the following error:
> [INFO] [dependency:copy-dependencies {execution: default}]
> [INFO] Copying classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error copying artifact from
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> Embedded error:
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No
> such file or directory)
> Steps to reproduce:
> * Unpack the attached test project and build the entire project once with
> "mvn install".
> * Execute "mvn generate-resources" from the root project -> success (because
> the compile phase is not executed)
> * Execute "mvn package" from the root project -> success (because the package
> phase is executed)
> * Execute "mvn generate-test-resources" from the root project -> fails
> (because the compile phase is executed, but not the package phase)
> * Execute "mvn generate-test-resources" in project2 -> success (because the
> dependency is not part of the same build)
> Root cause analysis: In the scenario described above (compile phase executed,
> package phase not executed), Artifact#getFile() points to the target/classes
> directory instead of the output artifact. dependency:copy-dependencies
> doesn't detect this situation and blindly attempts to execute the copy
> operation. This fails with the error message shown above. Note that even if
> the operation didn't fail, it would produce an unexpected result.
> Proposed fix (see attached patch): Change maven-dependency-plugin to detect
> this situation and let it replace the original Artifact object by a new one
> resolved from the repository (which would then refer to the artifact
> generated by a previous build, exactly as in the mvn generate
[jira] Commented: (MASSEMBLY-469) Version for artifacts in dependencies section are resolved wrong
[
http://jira.codehaus.org/browse/MASSEMBLY-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231609#action_231609
]
Jon Osborn commented on MASSEMBLY-469:
--
I see this problem also. 2.2-beta-2 works.
> Version for artifacts in dependencies section are resolved wrong
>
>
> Key: MASSEMBLY-469
> URL: http://jira.codehaus.org/browse/MASSEMBLY-469
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Windows, Java6, maven-2.2.1
>Reporter: Christoph Panwinkler
>
> Dependencies to artifacts are resolved wrongly when using
> maven-assembly-plugin > 2.2-beta-2 (this still exists in Version 2.2-beta-5):
> a) Goal mvn assembly:assembly
> b) Descriptor
>
> service-wrapper
>
> zip
>
> ${project.name}
> true
>
>
> false
> compile
> lib
>
>
> ...
>
> e.g.
> We have version test-1.0.jar in parent pom.
> We overwrite this version with test-1.1.jar in current pom
> 1) 2.2-beta-3 >= maven-assembly-plugin <= 2.2-beta-5
> test-1.0.jar is packaged in zip-File
> 2) maven-assembly-plugin < 2.2-beta-2
> test-1.1.jar is packaged in zip-File
> => Artifact test in this case should always be resolved to test-1.1.jar
--
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: (SCM-559) support readSettings for clearcase, starteam and vss
[ http://jira.codehaus.org/browse/SCM-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-559: - Fix Version/s: 1.5 > support readSettings for clearcase, starteam and vss > > > Key: SCM-559 > URL: http://jira.codehaus.org/browse/SCM-559 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-clearcase, > maven-scm-provider-starteam, maven-scm-provider-vss >Affects Versions: 1.3 >Reporter: Robert Scholte > Fix For: 1.5 > > Attachments: SettingsUtil-readSettings.patch > > > SCM-535 broke a couple of my tests, but it's indeed an improvement. Although > not all the settings which can be read have been improved with this feature. > With the attached patch you can use both getSettings and readSettings for > clearcase, starteam and vss 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] Moved: (SCM-569) CVS checkout giving error
[ http://jira.codehaus.org/browse/SCM-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MSCMCHGLOG-29 to SCM-569: -- Complexity: Intermediate Key: SCM-569 (was: MSCMCHGLOG-29) Project: Maven SCM (was: Maven 2.x SCM Changelog Plugin) > CVS checkout giving error > - > > Key: SCM-569 > URL: http://jira.codehaus.org/browse/SCM-569 > Project: Maven SCM > Issue Type: Bug >Reporter: Monica Dube > > I am getting following error when do CVS checkout using maven. Please help me > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Command failed.The > cvs command failed. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:55 > 6) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a: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) > Caused by: org.apache.maven.plugin.MojoExecutionException: Command failed.The > cvs command failed. > at > org.apache.maven.scm.plugin.AbstractScmMojo.checkResult(AbstractScmMojo.java:398) > at > org.apache.maven.scm.plugin.CheckoutMojo.checkout(CheckoutMojo.java:128) > at > org.apache.maven.scm.plugin.CheckoutMojo.execute(CheckoutMojo.java:93) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > ... 17 more -- 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: (MSITE-432) Incorrect classpath is used when site plugin/phase launches javadoc command
[
http://jira.codehaus.org/browse/MSITE-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231600#action_231600
]
James Ravn edited comment on MSITE-432 at 8/10/10 9:51 AM:
---
Using test-jar exhibits the same exact issue in 2.2.1. The only
workaround I can find is to place the test-jar dependency first - this causes
the test javadoc to fail instead of the main javadoc.
was (Author: jsravn):
Using test-jar exhibits the same exact issue in 2.2.1. The
only workaround I can find is to place the test-jar dependency first - this
causes the test javadoc to fail instead of the main javadoc (which maven
happily ignores).
> Incorrect classpath is used when site plugin/phase launches javadoc command
> ---
>
> Key: MSITE-432
> URL: http://jira.codehaus.org/browse/MSITE-432
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-7, 2.0.1
> Environment: Maven 2.2.1
>Reporter: Chris Tait
>Priority: Minor
> Attachments: maven-projects.zip
>
>
> When invoking the site plugin (with javadoc reporting enabled) for a project
> that depends on both the main artifact and the tests artifact of another
> project, the classpath passed to the javadoc command is incorrect.
> For example:
> Project A produces the following artifacts:
> - ProjectA-version.jar (main artifact)
> - ProjectA-version-tests.jar (test classes)
> And project B has dependencies similar to this:
> {code}
> ...
> Project1
> ...
>
>
> ...
> Project1
> ...
> tests
> test
> {code}
> Then only one of the jars is included in the classpath passed to the javadoc
> command. (Normally it seems to be the main artifact, although on one of my
> projects it was the tests artifact instead.) This causes lots of warnings,
> or for some projects causes the build to fail.
> Note that if I explicitly run the javadoc goals (i.e. "mvn javadoc:javadoc"
> or "mvn javadoc:test-javadoc") then the classpath is populated correctly and
> no errors are shown. It's only when the site plugin/phase launches it that
> the classpath is wrong. I've also found that the order of the dependencies
> within the POM file seems to make a difference in some cases.
> I've attached a zip file containing two projects to reproduce this. To run
> it:
> # run {{mvn install}} on project1
> # run {{mvn site}} on project2 (to see the warnings) or {{mvn
> javadoc:test-javadoc}}
> The warning looks like this:
> {code}[WARNING] Javadoc Warnings
> [WARNING]
> D:\code\EclipseWorkspaces_chris\PaymentCard\project3\src\main\java\repro3\MyClass3.java:3:
> cannot find symbol
> [WARNING] symbol : class MyClass1
> [WARNING] location: package repro1
> [WARNING] import repro1.MyClass1;
> [WARNING] ^{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: (MSITE-432) Incorrect classpath is used when site plugin/phase launches javadoc command
[
http://jira.codehaus.org/browse/MSITE-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231600#action_231600
]
James Ravn commented on MSITE-432:
--
Using test-jar exhibits the same exact issue in 2.2.1. The only
workaround I can find is to place the test-jar dependency first - the test
javadoc fails instead of the main javadoc, but maven ignores it.
> Incorrect classpath is used when site plugin/phase launches javadoc command
> ---
>
> Key: MSITE-432
> URL: http://jira.codehaus.org/browse/MSITE-432
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-7, 2.0.1
> Environment: Maven 2.2.1
>Reporter: Chris Tait
>Priority: Minor
> Attachments: maven-projects.zip
>
>
> When invoking the site plugin (with javadoc reporting enabled) for a project
> that depends on both the main artifact and the tests artifact of another
> project, the classpath passed to the javadoc command is incorrect.
> For example:
> Project A produces the following artifacts:
> - ProjectA-version.jar (main artifact)
> - ProjectA-version-tests.jar (test classes)
> And project B has dependencies similar to this:
> {code}
> ...
> Project1
> ...
>
>
> ...
> Project1
> ...
> tests
> test
> {code}
> Then only one of the jars is included in the classpath passed to the javadoc
> command. (Normally it seems to be the main artifact, although on one of my
> projects it was the tests artifact instead.) This causes lots of warnings,
> or for some projects causes the build to fail.
> Note that if I explicitly run the javadoc goals (i.e. "mvn javadoc:javadoc"
> or "mvn javadoc:test-javadoc") then the classpath is populated correctly and
> no errors are shown. It's only when the site plugin/phase launches it that
> the classpath is wrong. I've also found that the order of the dependencies
> within the POM file seems to make a difference in some cases.
> I've attached a zip file containing two projects to reproduce this. To run
> it:
> # run {{mvn install}} on project1
> # run {{mvn site}} on project2 (to see the warnings) or {{mvn
> javadoc:test-javadoc}}
> The warning looks like this:
> {code}[WARNING] Javadoc Warnings
> [WARNING]
> D:\code\EclipseWorkspaces_chris\PaymentCard\project3\src\main\java\repro3\MyClass3.java:3:
> cannot find symbol
> [WARNING] symbol : class MyClass1
> [WARNING] location: package repro1
> [WARNING] import repro1.MyClass1;
> [WARNING] ^{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] Issue Comment Edited: (MSITE-432) Incorrect classpath is used when site plugin/phase launches javadoc command
[
http://jira.codehaus.org/browse/MSITE-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231600#action_231600
]
James Ravn edited comment on MSITE-432 at 8/10/10 9:50 AM:
---
Using test-jar exhibits the same exact issue in 2.2.1. The only
workaround I can find is to place the test-jar dependency first - this causes
the test javadoc to fail instead of the main javadoc (which maven happily
ignores).
was (Author: jsravn):
Using test-jar exhibits the same exact issue in 2.2.1. The
only workaround I can find is to place the test-jar dependency first - the test
javadoc fails instead of the main javadoc, but maven ignores it.
> Incorrect classpath is used when site plugin/phase launches javadoc command
> ---
>
> Key: MSITE-432
> URL: http://jira.codehaus.org/browse/MSITE-432
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-7, 2.0.1
> Environment: Maven 2.2.1
>Reporter: Chris Tait
>Priority: Minor
> Attachments: maven-projects.zip
>
>
> When invoking the site plugin (with javadoc reporting enabled) for a project
> that depends on both the main artifact and the tests artifact of another
> project, the classpath passed to the javadoc command is incorrect.
> For example:
> Project A produces the following artifacts:
> - ProjectA-version.jar (main artifact)
> - ProjectA-version-tests.jar (test classes)
> And project B has dependencies similar to this:
> {code}
> ...
> Project1
> ...
>
>
> ...
> Project1
> ...
> tests
> test
> {code}
> Then only one of the jars is included in the classpath passed to the javadoc
> command. (Normally it seems to be the main artifact, although on one of my
> projects it was the tests artifact instead.) This causes lots of warnings,
> or for some projects causes the build to fail.
> Note that if I explicitly run the javadoc goals (i.e. "mvn javadoc:javadoc"
> or "mvn javadoc:test-javadoc") then the classpath is populated correctly and
> no errors are shown. It's only when the site plugin/phase launches it that
> the classpath is wrong. I've also found that the order of the dependencies
> within the POM file seems to make a difference in some cases.
> I've attached a zip file containing two projects to reproduce this. To run
> it:
> # run {{mvn install}} on project1
> # run {{mvn site}} on project2 (to see the warnings) or {{mvn
> javadoc:test-javadoc}}
> The warning looks like this:
> {code}[WARNING] Javadoc Warnings
> [WARNING]
> D:\code\EclipseWorkspaces_chris\PaymentCard\project3\src\main\java\repro3\MyClass3.java:3:
> cannot find symbol
> [WARNING] symbol : class MyClass1
> [WARNING] location: package repro1
> [WARNING] import repro1.MyClass1;
> [WARNING] ^{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] Closed: (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[
http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-259.
--
Resolution: Won't Fix
This is a problem with Maven Core, not the dependency plugin. It will only
happen if you are doing just mvn compile or maybe mvn test on the multimodule
build, because those modules haven't been packaged yet. When this happens, the
core hands the plugin a reference to the classes folder, but we expect a jar.
Instead of running mvn compile/test just always use mvn install and you'll be
fine. Alternatively, bind the dependency plugin to the package phase and it
won't run unless you do at least mvn package in which case all of the modules
will be jar'd already.
The _only_ workaround we could do in the plugin is to cause the dependency
plugin to detect that it has a folder and either:
1) ignore this dependency
2) go and attempt to create a jar from the classes
Neither of these is a correct fix because in 1, the resulting folder/archive
would be incomplete and 2 we have no way of reliably constructing the jar
exactly as it would be done in its own pom.
> copy-dependencies fails with "Error copying artifact from .../target/classes
> to .../classes"
>
>
> Key: MDEP-259
> URL: http://jira.codehaus.org/browse/MDEP-259
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies
>Affects Versions: 2.0, 2.1
> Environment: Maven 2.0.9
> maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
>Reporter: Andreas Veithen
>Assignee: Brian Fox
> Attachments: patch.txt, test-project.zip
>
>
> Scenario:
> * dependency:copy-dependencies is used to copy a dependency artifact that is
> part of the same multi-module build.
> * The compile phase is executed, but not the package phase.
> An example of this scenario is using maven-eclipse-plugin to import a Maven
> project with generated test (re)sources. In this case, one would execute "mvn
> generate-test-resources eclipse:eclipse" to make sure that the generated
> (re)sources are imported into the workspace (by default, maven-eclipse-plugin
> executes generate-sources and generate-resources, but not
> generate-test-sources and generate-test-resources).
> Result: The build fails with the following error:
> [INFO] [dependency:copy-dependencies {execution: default}]
> [INFO] Copying classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error copying artifact from
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> Embedded error:
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No
> such file or directory)
> Steps to reproduce:
> * Unpack the attached test project and build the entire project once with
> "mvn install".
> * Execute "mvn generate-resources" from the root project -> success (because
> the compile phase is not executed)
> * Execute "mvn package" from the root project -> success (because the package
> phase is executed)
> * Execute "mvn generate-test-resources" from the root project -> fails
> (because the compile phase is executed, but not the package phase)
> * Execute "mvn generate-test-resources" in project2 -> success (because the
> dependency is not part of the same build)
> Root cause analysis: In the scenario described above (compile phase executed,
> package phase not executed), Artifact#getFile() points to the target/classes
> directory instead of the output artifact. dependency:copy-dependencies
> doesn't detect this situation and blindly attempts to execute the copy
> operation. This fails with the error message shown above. Note that even if
> the operation didn't fail, it would produce an unexpected result.
> Proposed fix (see attached patch): Change maven-dependency-plugin to detect
> this situation and let it replace the original Artifact object by a new one
> resolved from the repository (which would then refer to the artifact
> generated by a previous build, exactly as in the mvn generate-resources case).
--
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-402) Multi-module project with .confluence content does not work
[ http://jira.codehaus.org/browse/DOXIA-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231596#action_231596 ] Lukas Theussl commented on DOXIA-402: - Did you read http://maven.apache.org/plugins/maven-site-plugin/faq.html#How_to_include_a_custom_Doxia_module_like_Twiki ? > Multi-module project with .confluence content does not work > --- > > Key: DOXIA-402 > URL: http://jira.codehaus.org/browse/DOXIA-402 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.1.3 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_20 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac" >Reporter: Nathan Sowatskey >Priority: Blocker > Attachments: apt-site-test.zip, confluence-site-test.zip > > > There are two projects attached. > The apt-site-test has the parent content in apt format. When building a > multi-module project the content in the apt-site-test appears as expected. > The confluence-site-test has the parent content in confluence format. That > content does not appear as expected. Instead a generic "about" page is > created. -- 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: (DOXIASITETOOLS-39) Velocity > 1.5 can't parse default-site.vm
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231595#action_231595 ] Lukas Theussl commented on DOXIASITETOOLS-39: - I have fixed the script in [r984014|http://svn.apache.org/viewvc?view=revision&revision=984014]. However, I have not actually upgraded the velocity version, the reason being that the script shipped with the published stylus-skin is also not compatible (see [r984016|http://svn.apache.org/viewvc?view=revision&revision=984016]), so people wouldn't be able to use the old skin. Let me know if this helps anything. > Velocity > 1.5 can't parse default-site.vm > -- > > Key: DOXIASITETOOLS-39 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Doc renderer, Site renderer >Affects Versions: 1.0, 1.1 >Reporter: Stefan Bodewig >Priority: Minor > > This is an issue detected by Gump which runs Maven builds but replaces > dependencies with the trunk versions of things built by Gump rather than the > version a project asks for. > The Cargo build - see > http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html > - fails because Velocity doesn't like the line > #set ( $documentHeader = "" ) > because \" is not an escape sequence for Velocity (anymore?). > I've taken this to the velocity list - > http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e > - and received the feedback that backslash > escaping was not supported - and likely never has been - and you should > either use single > quotes inside the double quotes or use something like > #set( $Q = '"' ) > #set ( $documentHeader = " I realize that it probably works for you right now using Velocity 1.5, that's > why I used Improvement rather than bug as category. Still it may be worth to > find a solution that works for the version of Velocity you want to use as > well as future versions. -- 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: (MDEP-279) an patterns do not work with .tar.gz packaging
an patterns do not work with .tar.gz packaging
Key: MDEP-279
URL: http://jira.codehaus.org/browse/MDEP-279
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.1, 2.0
Reporter: Torben Knerr
Assignee: Brian Fox
I have created a {{myapp-1.0-jar-with-dependencies.tar.gz}} file using the
maven-assembly-plugin:
{code}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
jar-with-dependencies
tar.gz
false
true
runtime
*:jar:*
{code}
Now I want to unpack {{myapp-1.0-jar-with-dependencies.tar.gz}} to another
maven project's target directory, but exclude some of the files in the .tar.gz
file:
{code}
maven-dependency-plugin
copy-to-shared-folder
generate-sources
unpack
my.group.id
myapp
1.0
jar-with-dependencies
tar.gz
**/*.*
**/bad-file.jar,**/some-stuff.log
${project.build.directory}/myapp-libs
true
true
{code}
*However, the {{}} and {{}} sections are completely
ignored here.*
I have noticed that for {{zip}} dependencies the include/exclude
filters are working as expected, but I would assume that it should for for
{{.tar.gz}} 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: (DOXIASITETOOLS-39) Velocity > 1.5 can't parse default-site.vm
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231587#action_231587 ] Stefan Bodewig commented on DOXIASITETOOLS-39: -- I agree single quotes are a natural solution. Whether it is worth upgrading, I don't know. It's not as if upgrading from Doxia 1.0 to 1.1 would be painless ;-) More seriously,the reason I went to the Velocity developer list first was that I intended to get a backwards incompatibility fixed before the final release. In this case I think the Velocity devs have a point, though, in that the current template simply isn't really correct. Gump is intended to be there to catch this type of changes before they become final, it is just that not enough projects are actively participating to make it a success. > Velocity > 1.5 can't parse default-site.vm > -- > > Key: DOXIASITETOOLS-39 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Doc renderer, Site renderer >Affects Versions: 1.0, 1.1 >Reporter: Stefan Bodewig >Priority: Minor > > This is an issue detected by Gump which runs Maven builds but replaces > dependencies with the trunk versions of things built by Gump rather than the > version a project asks for. > The Cargo build - see > http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html > - fails because Velocity doesn't like the line > #set ( $documentHeader = "" ) > because \" is not an escape sequence for Velocity (anymore?). > I've taken this to the velocity list - > http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e > - and received the feedback that backslash > escaping was not supported - and likely never has been - and you should > either use single > quotes inside the double quotes or use something like > #set( $Q = '"' ) > #set ( $documentHeader = " I realize that it probably works for you right now using Velocity 1.5, that's > why I used Improvement rather than bug as category. Still it may be worth to > find a solution that works for the version of Velocity you want to use as > well as future versions. -- 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-398) TOC for .confluence doesn't seem to work
[
http://jira.codehaus.org/browse/DOXIA-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231585#action_231585
]
Nathan Sowatskey commented on DOXIA-398:
Thanks for looking.
I also raised:
http://jira.codehaus.org/browse/DOXIA-402
It looks like the .confluence option for Maven sites is not really ready yet.
> TOC for .confluence doesn't seem to work
>
>
> Key: DOXIA-398
> URL: http://jira.codehaus.org/browse/DOXIA-398
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.1.3
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Nathan Sowatskey
> Attachments: toc_test_case.zip
>
>
> Please see attached test case.
> The {toc} macro in the index.confluence doesn't seem to work. There is no TOC
> produced, just the literal text of the toc macro itself.
--
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-402) Multi-module project with .confluence content does not work
Multi-module project with .confluence content does not work --- Key: DOXIA-402 URL: http://jira.codehaus.org/browse/DOXIA-402 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.1.3 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac" Reporter: Nathan Sowatskey Priority: Blocker Attachments: apt-site-test.zip, confluence-site-test.zip There are two projects attached. The apt-site-test has the parent content in apt format. When building a multi-module project the content in the apt-site-test appears as expected. The confluence-site-test has the parent content in confluence format. That content does not appear as expected. Instead a generic "about" page is created. -- 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-398) TOC for .confluence doesn't seem to work
[
http://jira.codehaus.org/browse/DOXIA-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231584#action_231584
]
Lukas Theussl commented on DOXIA-398:
-
I have had a quick look at the source code (I am not familiar with confluence
at all), and I don't see anything there, so I don't think it's implemented.
> TOC for .confluence doesn't seem to work
>
>
> Key: DOXIA-398
> URL: http://jira.codehaus.org/browse/DOXIA-398
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.1.3
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Nathan Sowatskey
> Attachments: toc_test_case.zip
>
>
> Please see attached test case.
> The {toc} macro in the index.confluence doesn't seem to work. There is no TOC
> produced, just the literal text of the toc macro itself.
--
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: (DOXIASITETOOLS-39) Velocity > 1.5 can't parse default-site.vm
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231583#action_231583
]
Lukas Theussl commented on DOXIASITETOOLS-39:
-
Stefan, I appreciate your efforts and feedback in spite the fact you are not
even affected by the problem :) I am just trying to figure out whether we
should be concerned at all. It obviously works with the velocity version we are
using (1.5), so the question is whether it's worth upgrading? I can confirm
that with Velocity 1.7-beta1 I get your error message, but not with any other
version. I also noted that the following works with any version:
{noformat}
#set ( $documentHeader = '' )
{noformat}
ie single quotes outside and no escaping of double quotes. That seems like the
most logical alternative for me. But then again, if things change with every
new version of velocity, then I am reluctant to upgrade anyway if there is no
other good reason...
> Velocity > 1.5 can't parse default-site.vm
> --
>
> Key: DOXIASITETOOLS-39
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-39
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Doc renderer, Site renderer
>Affects Versions: 1.0, 1.1
>Reporter: Stefan Bodewig
>Priority: Minor
>
> This is an issue detected by Gump which runs Maven builds but replaces
> dependencies with the trunk versions of things built by Gump rather than the
> version a project asks for.
> The Cargo build - see
> http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html
> - fails because Velocity doesn't like the line
> #set ( $documentHeader = "" )
> because \" is not an escape sequence for Velocity (anymore?).
> I've taken this to the velocity list -
> http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e
> - and received the feedback that backslash
> escaping was not supported - and likely never has been - and you should
> either use single
> quotes inside the double quotes or use something like
> #set( $Q = '"' )
> #set ( $documentHeader = " I realize that it probably works for you right now using Velocity 1.5, that's
> why I used Improvement rather than bug as category. Still it may be worth to
> find a solution that works for the version of Velocity you want to use as
> well as future versions.
--
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-398) TOC for .confluence doesn't seem to work
[
http://jira.codehaus.org/browse/DOXIA-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231581#action_231581
]
Nathan Sowatskey commented on DOXIA-398:
Thanks for the update.
I have seen that the macros won't work.
It isn't clear that this also implies that the Confluence syntax for generating
a TOC won't work though.
So, just to be clear, is there any way to create a TOC for .confluence content
in a Maven site?
> TOC for .confluence doesn't seem to work
>
>
> Key: DOXIA-398
> URL: http://jira.codehaus.org/browse/DOXIA-398
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.1.3
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Nathan Sowatskey
> Attachments: toc_test_case.zip
>
>
> Please see attached test case.
> The {toc} macro in the index.confluence doesn't seem to work. There is no TOC
> produced, just the literal text of the toc macro itself.
--
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-398) TOC for .confluence doesn't seem to work
[
http://jira.codehaus.org/browse/DOXIA-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231580#action_231580
]
Lukas Theussl commented on DOXIA-398:
-
As noted in the Macros Guide [1], macros are only supported for APT, Xdoc and
FML (latter has been added by now, DOXIA-281).
[1] http://maven.apache.org/doxia/macros/index.html
> TOC for .confluence doesn't seem to work
>
>
> Key: DOXIA-398
> URL: http://jira.codehaus.org/browse/DOXIA-398
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.1.3
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Nathan Sowatskey
> Attachments: toc_test_case.zip
>
>
> Please see attached test case.
> The {toc} macro in the index.confluence doesn't seem to work. There is no TOC
> produced, just the literal text of the toc macro itself.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-443) Provide option to merge test classpath into one directory
[
http://jira.codehaus.org/browse/SUREFIRE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231579#action_231579
]
Stephen Connolly commented on SUREFIRE-443:
---
I am proposing that we mark this as "Will not fix" given that there is a
workaround and I do not think this should be the responsibility of surefire.
> Provide option to merge test classpath into one directory
> -
>
> Key: SUREFIRE-443
> URL: http://jira.codehaus.org/browse/SUREFIRE-443
> Project: Maven Surefire
> Issue Type: New Feature
> Components: classloading
>Affects Versions: 2.4
> Environment: Maven 2.0.8
>Reporter: Cory Prowse
>Priority: Minor
> Fix For: Backlog
>
>
> Please provide an option for the test classpath to be merged into one
> directory.
> Maven sets up the class files as follows:
> {noformat}
> |-- target/test-classes
> | `-- Unit Test classes
> |-- target/classes
> `-- Classes to be tested
> {noformat}
> When running unit tests, the desired outcome is for any file in the
> "target/test-classes" tree to override those in the "target/classes".
> Specifically that any file in classes is ignored and overridden by the file
> in test-classes for the tests to work as expected.
> (In a sense a union on these two file trees in the order specified)
> The problem arises when using a container such as Embedded JBoss to test
> which treats each directory as a separate scope for classloading.
> Reading the ejb-3_0-fr-spec-persistence.pdf section "6.2.2 Persistence Unit
> Scope" spells it out quite clearly (a very short one page read) that if the
> "target/test-classes" and "target/classes" are each treated as a separate
> ejb-jar, then the runtime environment is not going to work due to these
> scoping rules.
> I have an ugly hack in place as follows which has the desired effect, but it
> would be more preferable if instead Maven Surefire provided an option to
> merge the directories together and have just one directory in the test
> classpath.
> {noformat}
>
>
> ...
>
>
> maven-antrun-plugin
>
>
> setupTestClasspath
> test-compile
>
>
>
>
>
> todir="${basedir}/target/tmp" />
> todir="${basedir}/target/tmp" />
>
> overwrite="true">
> dir="${basedir}/target/tmp/test-classes" />
>
> overwrite="false">
> dir="${basedir}/target/tmp/classes" />
>
>
>
>
>
> run
>
>
>
> restoreTestClasspath
> test
>
>
>
>
> tofile="${basedir}/target/test-classes-MERGED" />
> todir="${basedir}/target" />
> file="${basedir}/target/tmp/test-classes" todir="${basedir}/target" />
>
>
>
> run
>
>
>
>
> ...
> {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] Issue Comment Edited: (SUREFIRE-174) Various information is written to stdout instead of log which is not embedder-friendly
[ http://jira.codehaus.org/browse/SUREFIRE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231577#action_231577 ] Stephen Connolly edited comment on SUREFIRE-174 at 8/10/10 6:01 AM: Marking as closed given the the reporter has not commented and it is claimed to be fixed in 2.4 was (Author: stephenconnolly): Marking as closed given the the raiser has not commented and it is claimed to be fixed in 2.4 > Various information is written to stdout instead of log which is not > embedder-friendly > -- > > Key: SUREFIRE-174 > URL: http://jira.codehaus.org/browse/SUREFIRE-174 > Project: Maven Surefire > Issue Type: Bug >Reporter: Stepan Roh > Fix For: 2.4 > > > The information (known to me) written to stdout in maven-surefire-plugin-2.2 > and surefire-booter-2.0 is: > - SurefireBooter writes "Forking command line..." if debug is enabled > - SurefireBooter redirects stdout and stderr of forked process to stdout > (this one is most serious, I think) > - SurefirePlugin outputs summary and/or text report to console (I know it can > be switched off and/or written to file, but I would like to have it written > to log) > It is important to have all this information written to log instead of > stdout, because information is "lost" if written to console and embedder is > used (two or more embedders may run and confuse their output) and it is also > important to be able to align such information with information already > logged. -- 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: (SUREFIRE-174) Various information is written to stdout instead of log which is not embedder-friendly
[ http://jira.codehaus.org/browse/SUREFIRE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-174. - Resolution: Fixed Fix Version/s: (was: Backlog) 2.4 Marking as closed given the the raiser has not commented and it is claimed to be fixed in 2.4 > Various information is written to stdout instead of log which is not > embedder-friendly > -- > > Key: SUREFIRE-174 > URL: http://jira.codehaus.org/browse/SUREFIRE-174 > Project: Maven Surefire > Issue Type: Bug >Reporter: Stepan Roh > Fix For: 2.4 > > > The information (known to me) written to stdout in maven-surefire-plugin-2.2 > and surefire-booter-2.0 is: > - SurefireBooter writes "Forking command line..." if debug is enabled > - SurefireBooter redirects stdout and stderr of forked process to stdout > (this one is most serious, I think) > - SurefirePlugin outputs summary and/or text report to console (I know it can > be switched off and/or written to file, but I would like to have it written > to log) > It is important to have all this information written to log instead of > stdout, because information is "lost" if written to console and embedder is > used (two or more embedders may run and confuse their output) and it is also > important to be able to align such information with information already > logged. -- 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: (SUREFIRE-141) Surefire should provide a pluggable means to specify a custom provider
[ http://jira.codehaus.org/browse/SUREFIRE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-141: -- Fix Version/s: (was: Backlog) 2.7 Putting in the bucket for 2.7 > Surefire should provide a pluggable means to specify a custom provider > -- > > Key: SUREFIRE-141 > URL: http://jira.codehaus.org/browse/SUREFIRE-141 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Micah Whitacre >Priority: Critical > Fix For: 2.7 > > > The current way that surefire determines which provider to use is hard coded > and based on a project's dependencies. I would like to write a custom > surefire-provider and be able to specify to use that provider without having > to patch the surefire plugin. In my case I want to write a surefire-provider > that will run Eclipse PDE Junits which wouldn't neccessarily have a specific > dependency listed -- 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: (SUREFIRE-292) Documentation for surefire API and providers
[ http://jira.codehaus.org/browse/SUREFIRE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-292: -- Fix Version/s: (was: Backlog) 2.7 > Documentation for surefire API and providers > > > Key: SUREFIRE-292 > URL: http://jira.codehaus.org/browse/SUREFIRE-292 > Project: Maven Surefire > Issue Type: Task >Affects Versions: 2.3 >Reporter: Brett Porter >Priority: Blocker > Fix For: 2.7 > > > While the docs for the plugins are reasonable, the surefire mini-site is > barebones. -- 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: (SUREFIRE-141) Surefire should provide a pluggable means to specify a custom provider
[ http://jira.codehaus.org/browse/SUREFIRE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-141: -- Priority: Blocker (was: Critical) this should be a must fix for 2.7 > Surefire should provide a pluggable means to specify a custom provider > -- > > Key: SUREFIRE-141 > URL: http://jira.codehaus.org/browse/SUREFIRE-141 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Micah Whitacre >Priority: Blocker > Fix For: 2.7 > > > The current way that surefire determines which provider to use is hard coded > and based on a project's dependencies. I would like to write a custom > surefire-provider and be able to specify to use that provider without having > to patch the surefire plugin. In my case I want to write a surefire-provider > that will run Eclipse PDE Junits which wouldn't neccessarily have a specific > dependency listed -- 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: (MRELEASE-587) release:prepare ends up with FATAL ERROR (java.lang.OutOfMemoryError: Java heap space)
release:prepare ends up with FATAL ERROR (java.lang.OutOfMemoryError: Java heap space) -- Key: MRELEASE-587 URL: http://jira.codehaus.org/browse/MRELEASE-587 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0 Environment: Windows XP Reporter: Teemu Lehto Priority: Minor OutOfMemoryError occurs if unit tests (for example) write a lot of debug messages to console. prepare works fine when logging level is something else than DEBUG Is it possible to somehow get better error message??? Here is a stack trace: [INFO] Trace java.lang.OutOfMemoryError: Java heap space at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393) at java.lang.StringBuffer.append(StringBuffer.java:225) at org.apache.maven.shared.release.ReleaseResult.appendOutput(ReleaseResult.java:85) at org.apache.maven.shared.release.exec.ForkedMavenExecutor.executeGoals(ForkedMavenExecutor.java:118) at org.apache.maven.shared.release.exec.ForkedMavenExecutor.executeGoals(ForkedMavenExecutor.java:126) at org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:59) at org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:42) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:136) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:585) 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: 4 minutes 2 seconds [INFO] Finished at: Mon Aug 09 15:49:17 EEST 2010 [INFO] Final Memory: 16M/1016M [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: (DOXIA-398) TOC for .confluence doesn't seem to work
[
http://jira.codehaus.org/browse/DOXIA-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231570#action_231570
]
Nathan Sowatskey commented on DOXIA-398:
Hi
This is a major problem, so I am trying to figure out whether I should give up
on the Confluence markup and just use the apt.
Any input would help.
Many thanks
Nathan
> TOC for .confluence doesn't seem to work
>
>
> Key: DOXIA-398
> URL: http://jira.codehaus.org/browse/DOXIA-398
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.1.3
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Nathan Sowatskey
> Attachments: toc_test_case.zip
>
>
> Please see attached test case.
> The {toc} macro in the index.confluence doesn't seem to work. There is no TOC
> produced, just the literal text of the toc macro itself.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-634) setting "java.library.path" via systemPropertyVariables or systemProperties is not working
[
http://jira.codehaus.org/browse/SUREFIRE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231569#action_231569
]
Daniel Rothmaler commented on SUREFIRE-634:
---
It seems that "java.library.path" can't be changed, using the
System.setProperty method (see:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4280189), as it is done by
the SurefireBooter. So there should be a special handling for such read-only
properties (conversion to "-D" commandline arguments) or at least it would be
nice, if the "systemPropertyVariables" documentation would contain an hint,
that they are configured using "System.setProperty" and that this may not work
for some properties like "java.library.path".
> setting "java.library.path" via systemPropertyVariables or systemProperties
> is not working
> --
>
> Key: SUREFIRE-634
> URL: http://jira.codehaus.org/browse/SUREFIRE-634
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.5
> Environment: Windows 7 (x64)
>Reporter: Daniel Rothmaler
>Priority: Minor
>
> I tried to set "java.library.path" for my tests, to use an native windows dll
> (in my case jawin.dll).
> Id tried to do this the following way:
>
> ${basedir}/src/main/runtime/lib/
>
> I also tried to use the older , with
> "${project.build.directory}/lib/" as base (with copied libs of cause), with
> an absolute path and with different fork modes; but nothing worked.
> The only way to get it going was to use "":
> -Djava.library.path=${basedir}/src/main/runtime/lib/
--
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: (DOXIASITETOOLS-39) Velocity > 1.5 can't parse default-site.vm
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231568#action_231568
]
Stefan Bodewig commented on DOXIASITETOOLS-39:
--
Lukas, I fully understand your sentiment and in fact this is what I'd ask if
anybody reported a bug that I cannot reproduce in my projects as well. The
problem here is, I am not a Doxia user, nor a Maven user - I wouldn't even know
where to start if I tried to provide a test.
Let's take this a few steps backwards.
First, this is what the template reads:
{noformat}
#set ( $documentHeader = "" )
#set ( $documentHeader = $documentHeader.replaceAll( "\\", "" ) )
{noformat}
The first line tries to create an XML declaration with double-quotes and tries
to escape the double-quotes with a backslash. The Velocity developers say
backslashes have never worked as escape character for double-quotes in string
literals and I trust them. At least they don't work in Velocity 1.7.
The second line strips backslashes. If the backslash escaping of the first
line worked, there wouldn't be any backslash in $documentHeader and the line
was unneeded. I take this as a hint that the first line really doesn't work as
expected and the second line is a workaround to get what you really wanted.
The first approach suggested to me (in the initial description) using $Q is
supposed to work with any version of Velocity, doubling the double-quotes may
require a newer version of Velocity. Either approach should make the second
line unnessary,
The current template doesn't work with Velocity 1.7 since they now use an
explicit grammer and ANTLR and the template violates the grammar - see
http://vmgump.apache.org/gump/public/doxia/doxia-site-renderer-test/gump_work/build_doxia_doxia-site-renderer-test.html
for a more isolated test.
I don't know how else I could help, in particular since I'm not affected by the
problem myself at all.
> Velocity > 1.5 can't parse default-site.vm
> --
>
> Key: DOXIASITETOOLS-39
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-39
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Doc renderer, Site renderer
>Affects Versions: 1.0, 1.1
>Reporter: Stefan Bodewig
>Priority: Minor
>
> This is an issue detected by Gump which runs Maven builds but replaces
> dependencies with the trunk versions of things built by Gump rather than the
> version a project asks for.
> The Cargo build - see
> http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html
> - fails because Velocity doesn't like the line
> #set ( $documentHeader = "" )
> because \" is not an escape sequence for Velocity (anymore?).
> I've taken this to the velocity list -
> http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e
> - and received the feedback that backslash
> escaping was not supported - and likely never has been - and you should
> either use single
> quotes inside the double quotes or use something like
> #set( $Q = '"' )
> #set ( $documentHeader = " I realize that it probably works for you right now using Velocity 1.5, that's
> why I used Improvement rather than bug as category. Still it may be worth to
> find a solution that works for the version of Velocity you want to use as
> well as future versions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-634) setting "java.library.path" via systemPropertyVariables or systemProperties is not working
setting "java.library.path" via systemPropertyVariables or systemProperties is
not working
--
Key: SUREFIRE-634
URL: http://jira.codehaus.org/browse/SUREFIRE-634
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.5
Environment: Windows 7 (x64)
Reporter: Daniel Rothmaler
Priority: Minor
I tried to set "java.library.path" for my tests, to use an native windows dll
(in my case jawin.dll).
Id tried to do this the following way:
${basedir}/src/main/runtime/lib/
I also tried to use the older , with
"${project.build.directory}/lib/" as base (with copied libs of cause), with an
absolute path and with different fork modes; but nothing worked.
The only way to get it going was to use "":
-Djava.library.path=${basedir}/src/main/runtime/lib/
--
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: (DOXIASITETOOLS-39) Velocity > 1.5 can't parse default-site.vm
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231563#action_231563 ] Lukas Theussl commented on DOXIASITETOOLS-39: - bq. it likely never has done what you intended it to do. Please substantiate this statement with a test case that demonstrates the difference, otherwise I don't know what we are talking about. The current default-site.vm has been used by every single maven user that has ever run the 'site' goal. And there are many maven-generated sites out there... > Velocity > 1.5 can't parse default-site.vm > -- > > Key: DOXIASITETOOLS-39 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Doc renderer, Site renderer >Affects Versions: 1.0, 1.1 >Reporter: Stefan Bodewig >Priority: Minor > > This is an issue detected by Gump which runs Maven builds but replaces > dependencies with the trunk versions of things built by Gump rather than the > version a project asks for. > The Cargo build - see > http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html > - fails because Velocity doesn't like the line > #set ( $documentHeader = "" ) > because \" is not an escape sequence for Velocity (anymore?). > I've taken this to the velocity list - > http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e > - and received the feedback that backslash > escaping was not supported - and likely never has been - and you should > either use single > quotes inside the double quotes or use something like > #set( $Q = '"' ) > #set ( $documentHeader = " I realize that it probably works for you right now using Velocity 1.5, that's > why I used Improvement rather than bug as category. Still it may be worth to > find a solution that works for the version of Velocity you want to use as > well as future versions. -- 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
