[jira] Commented: (MRELEASE-692) xxx-SNAPSHOT version tag created in Subversion when executing "release:prepare release:perform" in one call
[ https://jira.codehaus.org/browse/MRELEASE-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272872#comment-272872 ] Dominique Jean-Prost commented on MRELEASE-692: --- Same problem for me using the classic command line mvn release:prepare. The tag name that the plugin suggest now contains "-SNAPSHOT". Didn't happen in 2.1. > xxx-SNAPSHOT version tag created in Subversion when executing > "release:prepare release:perform" in one call > > > Key: MRELEASE-692 > URL: https://jira.codehaus.org/browse/MRELEASE-692 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.2 > Environment: Maven 2.2.1, Windows 7, Jenkins 1.411 >Reporter: Michael Hinterseher > > Tags created by Jenkins maven release plugin are no longer working correct > after upgrading the release plugin version from 2.1 to 2.2. > The created tag in subversion and the scm information now contains > "-SNAPSHOT". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-692) xxx-SNAPSHOT version tag created in Subversion when executing "release:prepare release:perform" in one call
[ https://jira.codehaus.org/browse/MRELEASE-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272878#comment-272878 ] Guillaume Husta commented on MRELEASE-692: -- This bug seems to be related to : [MRELEASE-691|http://jira.codehaus.org/browse/MRELEASE-691] (_tagNameFormat property interpolation does not use the release values but the project ones_) > xxx-SNAPSHOT version tag created in Subversion when executing > "release:prepare release:perform" in one call > > > Key: MRELEASE-692 > URL: https://jira.codehaus.org/browse/MRELEASE-692 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.2 > Environment: Maven 2.2.1, Windows 7, Jenkins 1.411 >Reporter: Michael Hinterseher > > Tags created by Jenkins maven release plugin are no longer working correct > after upgrading the release plugin version from 2.1 to 2.2. > The created tag in subversion and the scm information now contains > "-SNAPSHOT". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-563) JAR entry not found when including jar dependencies with "#" in classname
JAR entry not found when including jar dependencies with "#" in classname
-
Key: MASSEMBLY-563
URL: https://jira.codehaus.org/browse/MASSEMBLY-563
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Environment: Linux
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
2.6.32-32-generic #62-Ubuntu SMP Wed Apr 20 21:52:38 UTC 2011 x86_64 GNU/Linux
Reporter: Youri Bonnaffé
I'm building an assembly using a dependencySet. Every jar is included.
I get an error message Failed to create assembly: Error creating assembly
archive jars-with-dependencies: Problem creating jar: JAR entry
com/extjs/gxt/ui/client/widget/grid/GridTemplates not found in
/home/ybonnaffemoity/mavenRepository/com/extjs/gxt/2.2.1-custo-1/gxt-2.2.1-custo-1.jar.
It turns out that the incriminated class has also HTML files in the same folder
(GridTemplates#startGroup.html for instance). If I remove theses files, the
assembly will be created. I suspect the "#" character to be responsible of this.
Assembly descriptor:
jars-with-dependencies
jar
false
${project.build.outputDirectory}
/
/
true
*:jar:*
jar -tf gxt-2.2.1-custo-1.jar | grep "GridTemplates"
com/extjs/gxt/ui/client/widget/grid/GridTemplates#body.html
com/extjs/gxt/ui/client/widget/grid/GridTemplates#endGroup.html
com/extjs/gxt/ui/client/widget/grid/GridTemplates#master.html
com/extjs/gxt/ui/client/widget/grid/GridTemplates#startGroup.html
com/extjs/gxt/ui/client/widget/grid/GridTemplates.class
com/extjs/gxt/ui/client/widget/grid/GridTemplates.java
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JXR-90) No distinction between javadoc and test-javadoc
No distinction between javadoc and test-javadoc --- Key: JXR-90 URL: https://jira.codehaus.org/browse/JXR-90 Project: Maven JXR Issue Type: Bug Components: maven2 jxr plugin Affects Versions: 2.3 Reporter: Benson Margulies Priority: Minor The code in the maven-jxr-plugin looks to set if javadoc is aggregated. It is not careful to match the javadoc goal to the jxr goal; if for some reason the project sets aggregation differently for javadoc and test-javadoc, the results will be confused. It is not at all clear to me how important this is. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JXR-88) create jxr:aggregate and jxr:test-aggregate
[ https://jira.codehaus.org/browse/JXR-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272892#comment-272892 ] Benson Margulies commented on JXR-88: - JXR-88: jxr:aggregate and jxr:test-aggregate o add code, and test coverage, for test-aggregate o repair NPE in test report; someone seemed to have left two copies of something in there, and one of the two lacked protection from an NPE case. I'm puzzled as to why this bit me, but the fix seems clear enough. > create jxr:aggregate and jxr:test-aggregate > --- > > Key: JXR-88 > URL: https://jira.codehaus.org/browse/JXR-88 > Project: Maven JXR > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Herve Boutemy >Assignee: Benson Margulies > Fix For: 2.3 > > > in MJAVADOC-212, aggregate parameter of javadoc:javadoc was replaced by > javadoc:aggregate, which is more flexible > JXR should do the same change -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JXR-88) create jxr:aggregate and jxr:test-aggregate
[ https://jira.codehaus.org/browse/JXR-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed JXR-88. --- Resolution: Fixed Fix Version/s: 2.3 Looks done to me. > create jxr:aggregate and jxr:test-aggregate > --- > > Key: JXR-88 > URL: https://jira.codehaus.org/browse/JXR-88 > Project: Maven JXR > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Herve Boutemy >Assignee: Benson Margulies > Fix For: 2.3 > > > in MJAVADOC-212, aggregate parameter of javadoc:javadoc was replaced by > javadoc:aggregate, which is more flexible > JXR should do the same change -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
maven-shade-plugin does not resolve from user-defined repositories -- Key: MSHADE-103 URL: https://jira.codehaus.org/browse/MSHADE-103 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.4, 1.3.3 Environment: Maven 3.0.3 (works with 2.2.1) Reporter: Lukas Fryc maven-shade-plugin doesn't consult repositories defined in settings.xml when trying to resolve parents of given pom. It contacts only central repo: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project richfaces-components-api: Error creating shaded jar: 1 problem was encountered while building the effective model for org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT [ERROR] [FATAL] Non-resolvable parent POM for org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact org.richfaces:richfaces-parent:pom:10 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT, /home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10 [ERROR] for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml [ERROR] -> [Help 1] There is affected project (it references version 1.3.3, but the behavior is same with 1.4) if you would like to try at own: https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEJB-53) Class path entry missing in assemblies since maven 3
Class path entry missing in assemblies since maven 3 Key: MEJB-53 URL: https://jira.codehaus.org/browse/MEJB-53 Project: Maven 2.x EJB Plugin Issue Type: Bug Affects Versions: 2.2.1 Environment: Windows XP, Linux Reporter: Koen Verrecken We have an EJB project along with some custom assemblies: ... test ejb ... org.apache.maven.plugins maven-assembly-plugin true sender package single src/main/assembly/custom.xml This creates a test.jar and a test-custom.jar. The first jar has its Class-Path entry filled in correctly in the manifest file, but the 2nd jar has no Class-Path entry. The true was added for the maven assembly plugin, the maven-ejb-plugin in the parent pom also has this property set to true. This only happens with maven 3.0.3. With maven 2.2.1 both jars have their Class-Path filled in properly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JXR-84) Spurious error message fixed in Velocity 1.5 still exists in JXR
[ https://jira.codehaus.org/browse/JXR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272910#comment-272910 ] Benson Margulies commented on JXR-84: - I'm having some sort of classpath heck with this fix; I've attached a patch in case anyone else cares to have a look. > Spurious error message fixed in Velocity 1.5 still exists in JXR > > > Key: JXR-84 > URL: https://jira.codehaus.org/browse/JXR-84 > Project: Maven JXR > Issue Type: Bug > Components: jxr > Environment: Mac OS X 10.6.4, Java 1.6.0_20, Maven 2.2.1 >Reporter: Trevor Harmon >Assignee: Benson Margulies >Priority: Minor > Attachments: example.zip, JXR-84.patch, log.txt > > > There was a bug in Velocity 1.4 that was causing a spurious error message to > be printed: > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > This affects many Maven users who include JXR reports with their site > generation. That is because JXR uses Velocity, and thus the innocuous error > would be displayed on every "mvn site". > With the release of Velocity 1.5 in 2007, the bug was fixed: > https://issues.apache.org/jira/browse/VELOCITY-86 > But even when using the latest versions of JXR (2.2) and the Site plugin > (2.1.1), the error message still appears. This is because in the dependency > tree, the old Velocity 1.4 release is being pulled in (see attached build > log). > The component with a direct dependency on Velocity 1.4 is maven-jxr (not the > plugin but the library). Updating it to use Velocity 1.5 would presumably > cause the error message to go away. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JXR-84) Spurious error message fixed in Velocity 1.5 still exists in JXR
[ https://jira.codehaus.org/browse/JXR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated JXR-84: Attachment: JXR-84.patch > Spurious error message fixed in Velocity 1.5 still exists in JXR > > > Key: JXR-84 > URL: https://jira.codehaus.org/browse/JXR-84 > Project: Maven JXR > Issue Type: Bug > Components: jxr > Environment: Mac OS X 10.6.4, Java 1.6.0_20, Maven 2.2.1 >Reporter: Trevor Harmon >Assignee: Benson Margulies >Priority: Minor > Attachments: example.zip, JXR-84.patch, log.txt > > > There was a bug in Velocity 1.4 that was causing a spurious error message to > be printed: > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > This affects many Maven users who include JXR reports with their site > generation. That is because JXR uses Velocity, and thus the innocuous error > would be displayed on every "mvn site". > With the release of Velocity 1.5 in 2007, the bug was fixed: > https://issues.apache.org/jira/browse/VELOCITY-86 > But even when using the latest versions of JXR (2.2) and the Site plugin > (2.1.1), the error message still appears. This is because in the dependency > tree, the old Velocity 1.4 release is being pulled in (see attached build > log). > The component with a direct dependency on Velocity 1.4 is maven-jxr (not the > plugin but the library). Updating it to use Velocity 1.5 would presumably > cause the error message to go away. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4394) Configure same proxy for multiple protocols
[ https://jira.codehaus.org/browse/MNG-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272914#comment-272914 ] Carlos Saltos commented on MNG-4394: Why this bug is closed ? ... It's NOT working for Maven 2. I know that I just may update to Maven 3, but Maven 3 is broken for other issues in our projects. It's a pitty this patch cannot be applied for Maven 2. > Configure same proxy for multiple protocols > --- > > Key: MNG-4394 > URL: https://jira.codehaus.org/browse/MNG-4394 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.2.1 >Reporter: Hugo Palma >Assignee: Benjamin Bentmann > Attachments: MNG-4394.patch, MNG-4394.patch > > > It seems that it's not possible to configure a proxy for more than one > protocol. > I would think that it's a very common requirement to use a proxy for both > http and https. > It would be great if this was possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRESOURCES-140) Plugin shows always '[debug] execute contextualize' despite the logging level
[
https://jira.codehaus.org/browse/MRESOURCES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRESOURCES-140.
-
Resolution: Fixed
Fix Version/s: 2.6
Fixed in [rev. 1145244|http://svn.apache.org/viewvc?rev=1145244&view=rev]
> Plugin shows always '[debug] execute contextualize' despite the logging level
> -
>
> Key: MRESOURCES-140
> URL: https://jira.codehaus.org/browse/MRESOURCES-140
> Project: Maven 2.x Resources Plugin
> Issue Type: Improvement
>Affects Versions: 2.5
> Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
> Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_23\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 2.6
>
>
> While running Maven with the default logging level, it shows the following
> text in my console.
> {noformat}
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ project
> ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> {noformat}
> Reason seems to be, that the {{contextualize()}} is called before the plugin
> is fully setup, so there's no proper logger yet.
> Please remove this debug-line.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-82) go-offline / resolve-plugins does not resolve all plugin dependencies
[ https://jira.codehaus.org/browse/MDEP-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272920#comment-272920 ] Derek Lewis commented on MDEP-82: - Devin, I've used a similar situation to work around the problem. However, it means having to build everything, which is time consuming, and also means that commands you haven't run (like mvn deploy) won't work, because the deploy plugin wasn't downloaded. > go-offline / resolve-plugins does not resolve all plugin dependencies > - > > Key: MDEP-82 > URL: https://jira.codehaus.org/browse/MDEP-82 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: go-offline, resolve-plugins >Affects Versions: 2.0-alpha-4 > Environment: Maven 2.0.6 >Reporter: Arne Degenring >Assignee: Brian Fox > Attachments: pom.xml > > > The attached pom.xml is a very simple JAR project, without any direct > dependencies or plugin dependencies. > Start with an empty local repository, and run mvn dependency:go-offline on > it. Some files get downloaded, but not everything that is needed for the > build. If you run "mvn -o package" afterwards, you end up with the following > error: > [ERROR] BUILD ERROR > [INFO] > > [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not > exist or no valid version could be found > Afterwards, even "mvn package" without the "-o" parameter does not work any > longer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-692) xxx-SNAPSHOT version tag created in Subversion when executing "release:prepare release:perform" in one call
[ https://jira.codehaus.org/browse/MRELEASE-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272946#comment-272946 ] Tomasz Szpinda commented on MRELEASE-692: - Problem seems to be in InputVariablesPhase.execute(), this: values.setProperty( "version", project.getVersion() ); should read: values.setProperty( "version", releaseVersion ); > xxx-SNAPSHOT version tag created in Subversion when executing > "release:prepare release:perform" in one call > > > Key: MRELEASE-692 > URL: https://jira.codehaus.org/browse/MRELEASE-692 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.2 > Environment: Maven 2.2.1, Windows 7, Jenkins 1.411 >Reporter: Michael Hinterseher > > Tags created by Jenkins maven release plugin are no longer working correct > after upgrading the release plugin version from 2.1 to 2.2. > The created tag in subversion and the scm information now contains > "-SNAPSHOT". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPA-100) resolve integration test problems
[ https://jira.codehaus.org/browse/MPA-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272949#comment-272949 ] Herve Boutemy commented on MPA-100: --- moved to https://cwiki.apache.org/confluence/display/MAVENOLD/IT+Problems > resolve integration test problems > - > > Key: MPA-100 > URL: https://jira.codehaus.org/browse/MPA-100 > Project: Maven Project Administration > Issue Type: Task >Reporter: Brett Porter >Assignee: John Casey > > http://docs.codehaus.org/display/MAVEN/IT+Problems > Inidividual tasks for this should be created in the MNG JIRA itself. Issues > should be linked here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-692) xxx-SNAPSHOT version tag created in Subversion when executing "release:prepare release:perform" in one call
[ https://jira.codehaus.org/browse/MRELEASE-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Szpinda updated MRELEASE-692: Attachment: MRELEASE-692.patch mrelease-692 patch > xxx-SNAPSHOT version tag created in Subversion when executing > "release:prepare release:perform" in one call > > > Key: MRELEASE-692 > URL: https://jira.codehaus.org/browse/MRELEASE-692 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.2 > Environment: Maven 2.2.1, Windows 7, Jenkins 1.411 >Reporter: Michael Hinterseher > Attachments: MRELEASE-692.patch > > > Tags created by Jenkins maven release plugin are no longer working correct > after upgrading the release plugin version from 2.1 to 2.2. > The created tag in subversion and the scm information now contains > "-SNAPSHOT". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JXR-84) Spurious error message fixed in Velocity 1.5 still exists in JXR
[ https://jira.codehaus.org/browse/JXR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272965#comment-272965 ] Benson Margulies commented on JXR-84: - r1145408 | bimargulies | 2011-07-11 20:38:49 -0400 (Mon, 11 Jul 2011) | 4 lines [JXR-84] Spurious error message fixed in Velocity 1.5 still exists in JXR o update the whole business to velocity 1.5, which, to match up with plexus and doxia, also required updating to doxia 1.2 and making related tweaks. While here, move a few easy things from plexus-utils to commons. > Spurious error message fixed in Velocity 1.5 still exists in JXR > > > Key: JXR-84 > URL: https://jira.codehaus.org/browse/JXR-84 > Project: Maven JXR > Issue Type: Bug > Components: jxr > Environment: Mac OS X 10.6.4, Java 1.6.0_20, Maven 2.2.1 >Reporter: Trevor Harmon >Assignee: Benson Margulies >Priority: Minor > Attachments: example.zip, JXR-84.patch, log.txt > > > There was a bug in Velocity 1.4 that was causing a spurious error message to > be printed: > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > This affects many Maven users who include JXR reports with their site > generation. That is because JXR uses Velocity, and thus the innocuous error > would be displayed on every "mvn site". > With the release of Velocity 1.5 in 2007, the bug was fixed: > https://issues.apache.org/jira/browse/VELOCITY-86 > But even when using the latest versions of JXR (2.2) and the Site plugin > (2.1.1), the error message still appears. This is because in the dependency > tree, the old Velocity 1.4 release is being pulled in (see attached build > log). > The component with a direct dependency on Velocity 1.4 is maven-jxr (not the > plugin but the library). Updating it to use Velocity 1.5 would presumably > cause the error message to go away. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JXR-84) Spurious error message fixed in Velocity 1.5 still exists in JXR
[ https://jira.codehaus.org/browse/JXR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed JXR-84. --- Resolution: Fixed Fix Version/s: 2.3 Note fiddly code to manage the thread context class loader. > Spurious error message fixed in Velocity 1.5 still exists in JXR > > > Key: JXR-84 > URL: https://jira.codehaus.org/browse/JXR-84 > Project: Maven JXR > Issue Type: Bug > Components: jxr > Environment: Mac OS X 10.6.4, Java 1.6.0_20, Maven 2.2.1 >Reporter: Trevor Harmon >Assignee: Benson Margulies >Priority: Minor > Fix For: 2.3 > > Attachments: example.zip, JXR-84.patch, log.txt > > > There was a bug in Velocity 1.4 that was causing a spurious error message to > be printed: > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > This affects many Maven users who include JXR reports with their site > generation. That is because JXR uses Velocity, and thus the innocuous error > would be displayed on every "mvn site". > With the release of Velocity 1.5 in 2007, the bug was fixed: > https://issues.apache.org/jira/browse/VELOCITY-86 > But even when using the latest versions of JXR (2.2) and the Site plugin > (2.1.1), the error message still appears. This is because in the dependency > tree, the old Velocity 1.4 release is being pulled in (see attached build > log). > The component with a direct dependency on Velocity 1.4 is maven-jxr (not the > plugin but the library). Updating it to use Velocity 1.5 would presumably > cause the error message to go away. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JXR-79) NPE on source XREF
[
https://jira.codehaus.org/browse/JXR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272968#comment-272968
]
Benson Margulies commented on JXR-79:
-
It's been a long time and no test case, so I plan to close this.
> NPE on source XREF
> --
>
> Key: JXR-79
> URL: https://jira.codehaus.org/browse/JXR-79
> Project: Maven JXR
> Issue Type: Bug
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_16
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family: "unix"
>Reporter: Johannes Schneider
>
> {noformat}[INFO] Generating "Source Xref" report.
> [DEBUG] Scanning
> /home/johannes/projects/com.cedarsoft.commons/version/src/main/java
> [DEBUG] parsing... com/cedarsoft/VersionRange.java
> [DEBUG] parsing... com/cedarsoft/Version.java
> [DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java
> [DEBUG] parsing... com/cedarsoft/VersionMismatchException.java
> [DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java
> [DEBUG] parsing... com/cedarsoft/VersionException.java
> [DEBUG]
> /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java
> ->
> /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html
> [DEBUG]
> /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java
> ->
> /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html
> [DEBUG]
> /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java
> ->
> /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html
> [DEBUG]
> /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java
> ->
> /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html
> [DEBUG]
> /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java
> ->
> /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html
> [DEBUG]
> /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java
> ->
> /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html
> [DEBUG] **
> [DEBUG] Starting Jakarta Velocity v1.4
> [DEBUG] RuntimeInstance initializing.
> [DEBUG] Default Properties File:
> org/apache/velocity/runtime/defaults/velocity.properties
> [DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger
> [DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger
> [DEBUG] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [DEBUG] Resource Loader Instantiated:
> org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
> [DEBUG] ClasspathResourceLoader : initialization starting.
> [DEBUG] ClasspathResourceLoader : initialization complete.
> [DEBUG] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> [DEBUG] Default ResourceManager initialization complete.
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [DEBUG] Created: 20 parsers.
> [DEBUG] Velocimacro : initialization starting.
> [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT replace previous VM definitions
> [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> global in scope if allowed.
> [DEBUG] Velocimacro : messages on : VM system will output logging messages
> [DEBUG] Velocimacro : autoload off : VM system will not automatically reload
> global library macros
> [DEBUG] Velocimacro : initialization complete.
> [DEBUG] Velocity successfully started.
> [DEBUG] ResourceManager : found templates/index.vm with loader
> org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
> [DEBUG] ResourceManager : found templates/overview-frame.vm with loader
> org.apache.velocity.runtime.resour
[jira] Commented: (JXR-78) Plugin doesn't pick up additional source folders
[
https://jira.codehaus.org/browse/JXR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272969#comment-272969
]
Benson Margulies commented on JXR-78:
-
There's no test case here, and there's certainly code that picks up additional
folders.
> Plugin doesn't pick up additional source folders
> -
>
> Key: JXR-78
> URL: https://jira.codehaus.org/browse/JXR-78
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 2.1
> Environment: Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
> Java version: 1.6.0_17
>Reporter: Andreas Sewe
>
> I commented about this earlier on the maven-users mailing list:
> [http://www.mail-archive.com/users@maven.apache.org/msg105586.html].
> {quote}
> I am currently having trouble getting the jxr-maven-plugin to pick up
> additional (test) source folders, regardless of whether the are added by the
> build-helper-maven-plugin or the sourceRoot/testSourceRoot configuration
> elements of the exec-maven-plugin.
> {quote}
> This issue may be related to [http://jira.codehaus.org/browse/JXR-42].
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JXR-64) System ID of XHTML frameset incorrect in HTML source
[
https://jira.codehaus.org/browse/JXR-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed JXR-64.
---
Resolution: Fixed
Fix Version/s: 2.3
r1145412 | bimargulies | 2011-07-11 20:48:59 -0400 (Mon, 11 Jul 2011) | 2 lines
[JXR-64] System ID of XHTML frameset incorrect in HTML source
> System ID of XHTML frameset incorrect in HTML source
>
>
> Key: JXR-64
> URL: https://jira.codehaus.org/browse/JXR-64
> Project: Maven JXR
> Issue Type: Bug
> Components: jxr
>Affects Versions: 2.1
>Reporter: Michael Osipov
>Assignee: Benson Margulies
> Fix For: 2.3
>
>
> The generated JXR report creates this DOCTYPE in the html files:
> {code}
> "DTD/xhtml1-frameset.dtd">
> {code}
> well, the local DTD does not exist and the correct doctype declaration has to
> be:
> {code}
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd";>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JXR-69) fails to create cross links in multi-module project
[ https://jira.codehaus.org/browse/JXR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed JXR-69. --- Resolution: Fixed Fix Version/s: 2.3 There is now an integration test that shows aggregation working. Since there's no test case in here, I'm closing this as fixed. > fails to create cross links in multi-module project > --- > > Key: JXR-69 > URL: https://jira.codehaus.org/browse/JXR-69 > Project: Maven JXR > Issue Type: Bug > Components: maven2 jxr plugin >Affects Versions: 2.1 >Reporter: Giovanni Azua > Fix For: 2.3 > > > My build pulls jxr 2.1. Although I set the aggregate parameter to true, I > still don't get linked cross module references say e.g. > Module A > Interface X > Module B (depends on A) > Class Y implements X > In the aggregate reports Class Y will not link to X. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTTASKS-213) spawns non-daemon thread
[
https://jira.codehaus.org/browse/MANTTASKS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272977#comment-272977
]
Paul King commented on MANTTASKS-213:
-
I suspect it affects all embedded usage of the maven ant tasks.
It certainly affects Groovy's AntBuilder as per:
http://jira.codehaus.org/browse/GROOVY-4562
> spawns non-daemon thread
>
>
> Key: MANTTASKS-213
> URL: https://jira.codehaus.org/browse/MANTTASKS-213
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.1.1
> Environment: Ubuntu, JDK 6 (but apparently also Vista); originally
> filed as: https://netbeans.org/bugzilla/show_bug.cgi?id=189868#c5
>Reporter: Jesse Glick
>
> When {{}} is run, {{DefaultArtifactResolver}} creates
> a thread pool using non-daemon threads. Thus live threads are left in the
> thread group after the task supposedly finishes. This can cause problems in
> containers such as NetBeans.
> The fix MNG-4738 is already in Maven 3.0; you just need to use Maven 3 in the
> task's dependencies, rather than 2.2.1 as now.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-431) Non-project EJB dependencies need a version number in application.xml
[ https://jira.codehaus.org/browse/MECLIPSE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272992#comment-272992 ] Robrecht Anrijs commented on MECLIPSE-431: -- patch MECLIPSE_431.4 and MECLIPSE_431.3 are working. I was wondering when these bugs are being fixed in the plugin. Is this plugin end of life? > Non-project EJB dependencies need a version number in application.xml > - > > Key: MECLIPSE-431 > URL: https://jira.codehaus.org/browse/MECLIPSE-431 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: RAD support, WTP support >Affects Versions: 2.5.1 >Reporter: Michael Johns > Attachments: MECLIPSE-431.2.patch, MECLIPSE_431.3.patch, > MECLIPSE_431.4.patch, MECLIPSE-431.patch > > > This relates to issue MECLIPSE-430. When including EJBs that were built > previously (ie, not part of the same multi-module project as the ear), the > application.xml needs to include their version number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
