[jira] Commented: (MASSEMBLY-528) FileSet does not support filtering (again)

2010-11-29 Thread JIRA

[ 
http://jira.codehaus.org/browse/MASSEMBLY-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=245612#action_245612
 ] 

Gérald Quintana commented on MASSEMBLY-528:
---

This a regression between 2.2-beta-5 and 2.2

Workaround: Filters are taken from project but you can force it like this:
{code:xml}
plugin
  artifactIdmaven-assembly-plugin/artifactId
configuration
  filters
filter../src/main/filters/filter-${env}.properties/filter
  /filters
  descriptors
descriptorsrc/main/assembly/descriptor.xml/descriptor
  /descriptors
/configuration
/plugin
{code}

 FileSet does not support filtering (again)
 --

 Key: MASSEMBLY-528
 URL: http://jira.codehaus.org/browse/MASSEMBLY-528
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Maik Richey
Priority: Critical

 After switching to version 2.2 of the Assembly Plugin filtering for FileSets 
 does not work again as in versions prior to 2.2-beta-3.
 Can anybody confirm this issue?

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




[jira] Issue Comment Edited: (MASSEMBLY-528) FileSet does not support filtering (again)

2010-11-29 Thread JIRA

[ 
http://jira.codehaus.org/browse/MASSEMBLY-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=245612#action_245612
 ] 

Gérald Quintana edited comment on MASSEMBLY-528 at 11/29/10 2:12 AM:
-

This a regression between 2.2-beta-5 and 2.2

Workaround: Filters are not taken from project but you can force it like this:
{code:xml}
plugin
  artifactIdmaven-assembly-plugin/artifactId
configuration
  filters
filter../src/main/filters/filter-${env}.properties/filter
  /filters
  descriptors
descriptorsrc/main/assembly/descriptor.xml/descriptor
  /descriptors
/configuration
/plugin
{code}

  was (Author: gquintana):
This a regression between 2.2-beta-5 and 2.2

Workaround: Filters are taken from project but you can force it like this:
{code:xml}
plugin
  artifactIdmaven-assembly-plugin/artifactId
configuration
  filters
filter../src/main/filters/filter-${env}.properties/filter
  /filters
  descriptors
descriptorsrc/main/assembly/descriptor.xml/descriptor
  /descriptors
/configuration
/plugin
{code}
  
 FileSet does not support filtering (again)
 --

 Key: MASSEMBLY-528
 URL: http://jira.codehaus.org/browse/MASSEMBLY-528
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Maik Richey
Priority: Critical

 After switching to version 2.2 of the Assembly Plugin filtering for FileSets 
 does not work again as in versions prior to 2.2-beta-3.
 Can anybody confirm this issue?

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




[jira] Created: (MNG-4920) Maven build crashes

2010-11-29 Thread Matthias Frenzel (JIRA)
Maven build crashes
---

 Key: MNG-4920
 URL: http://jira.codehaus.org/browse/MNG-4920
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 2.2.1
 Environment: Operating systen: Solaris
Build-container: hudson (runs on glafish 2.1.1)
Maven-version: 2.2.1
JDK version: JDK 6 Update 21
Project structure: multi-module project
Reporter: Matthias Frenzel


Sometimes the maven build crashes (about 40 percent of all builds) with a JDK 
crash at different times (while compiling, while generating javadoc, ...). This 
phenomenon occurs in various projects.
If I build at a later time (no configuration changes and no source code 
changes), it works.

Can somebody help me ? Has anybody an idea where could be the problem?
I have no idea where the problem is ?


Thanks in advance !!!



Here are some crash´s with the corresponded pid.logs:

### 1 ###

[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 170 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 44 source files to 
/data/opt/glafish/.hudson/jobs/MyProject/workspace/trunk/common/target/test-classes
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x08051588, pid=26, tid=7
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) Client VM (16.3-b01 mixed mode, sharing solaris-x86 
)
# Problematic frame:
# C  [java+0x1588]  main+0xd0
#
# An error report file with more information is saved as:
# /data/opt/glafish/.hudson/jobs/MyProject/workspace/trunk/hs_err_pid26.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
ERROR: Maven JVM terminated unexpectedly with exit code 6
Email was triggered for: Failure

### 2 ###

[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory 
/data/opt/glafish/.hudson/jobs/MyProject/workspace/trunk/console/target
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x08051588, pid=6031, tid=7
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) Client VM (16.3-b01 mixed mode, sharing solaris-x86 
)
# Problematic frame:
# C  [java+0x1588]  main+0xd0
#
# An error report file with more information is saved as:
# /data/opt/glafish/.hudson/jobs/MyProject/workspace/trunk/hs_err_pid6031.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
ERROR: Maven JVM terminated unexpectedly with exit code 6

### 3 ###

[INFO] Generating Checkstyle report.
[INFO] Generating Cobertura Test Coverage report.
[INFO] Cobertura Report generation was successful.
[INFO] Cobertura Report generation was successful.
[INFO] Generating JavaDocs report.
[WARNING] The Javadoc plugin parameter 'proxyHost' is deprecated since 2.4. 
Please configure an active proxy in your settings.xml.
[WARNING] The Javadoc plugin parameter 'proxyPort' is deprecated since 2.4. 
Please configure an active proxy in your settings.xml.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2e736c63, pid=14882, tid=7
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) Client VM (16.3-b01 mixed mode, sharing solaris-x86 
)
# Problematic frame:
# C  0x2e736c63
#
# An error report file with more information is saved as:
# 
/data/opt/glafish/.hudson/jobs/MyProject_REPORT/workspace/trunk/components/abc/tool/target/site/apidocs/hs_err_pid14882.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
[HUDSON] Archiving site from 
/data/opt/glafish/.hudson/jobs/MyProject_REPORT/workspace/trunk/components/abc/tool/target/site
 to /data/opt/glafish/.hudson/jobs/MyProject_REPORT/site/tool
[HUDSON] Archiving disabled - not archiving 
/data/opt/glafish/.hudson/jobs/MyProject_REPORT/workspace/trunk/components/abc/tool/pom.xml
[HUDSON] Archiving disabled - not archiving 
/data/opt/glafish/.hudson/jobs/MyProject_REPORT/workspace/trunk/components/abc/tool/target/tool-0.9-SNAPSHOT-bnull.jar
[HUDSON] Archiving disabled - not archiving 
/data/opt/glafish/.hudson/jobs/MyProject_REPORT/workspace/trunk/components/abc/tool/target/tool-0.9-SNAPSHOT-bnull-jar-with-dependencies.jar
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error during page generation

Embedded error: Error rendering Maven report: Exit code: 134 - Abbrechen - 
Speicherabbild 'core' geschrieben

Command line was:cd 

[jira] Closed: (MNG-4920) Maven build crashes

2010-11-29 Thread Benjamin Bentmann (JIRA)

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

Benjamin Bentmann closed MNG-4920.
--

Resolution: Not A Bug
  Assignee: Benjamin Bentmann

Please report this to the JVM vendor, Maven isn't invoking native code and Java 
code must not crash a well-behaving JVM.

 Maven build crashes
 ---

 Key: MNG-4920
 URL: http://jira.codehaus.org/browse/MNG-4920
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 2.2.1
 Environment: Operating systen: Solaris
 Build-container: hudson (runs on glafish 2.1.1)
 Maven-version: 2.2.1
 JDK version: JDK 6 Update 21
 Project structure: multi-module project
Reporter: Matthias Frenzel
Assignee: Benjamin Bentmann

 Sometimes the maven build crashes (about 40 percent of all builds) with a JDK 
 crash at different times (while compiling, while generating javadoc, ...). 
 This phenomenon occurs in various projects.
 If I build at a later time (no configuration changes and no source code 
 changes), it works.
 Can somebody help me ? Has anybody an idea where could be the problem?
 I have no idea where the problem is ?
 Thanks in advance !!!
 Here are some crash´s with the corresponded pid.logs:
 ### 1 ###
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] Copying 170 resources
 [INFO] [compiler:testCompile {execution: default-testCompile}]
 [INFO] Compiling 44 source files to 
 /data/opt/glafish/.hudson/jobs/MyProject/workspace/trunk/common/target/test-classes
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGSEGV (0xb) at pc=0x08051588, pid=26, tid=7
 #
 # JRE version: 6.0_20-b02
 # Java VM: Java HotSpot(TM) Client VM (16.3-b01 mixed mode, sharing 
 solaris-x86 )
 # Problematic frame:
 # C  [java+0x1588]  main+0xd0
 #
 # An error report file with more information is saved as:
 # /data/opt/glafish/.hudson/jobs/MyProject/workspace/trunk/hs_err_pid26.log
 #
 # If you would like to submit a bug report, please visit:
 #   http://java.sun.com/webapps/bugreport/crash.jsp
 #
 ERROR: Maven JVM terminated unexpectedly with exit code 6
 Email was triggered for: Failure
 ### 2 ###
 [INFO] [clean:clean {execution: default-clean}]
 [INFO] Deleting directory 
 /data/opt/glafish/.hudson/jobs/MyProject/workspace/trunk/console/target
 [INFO] [resources:resources {execution: default-resources}]
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGSEGV (0xb) at pc=0x08051588, pid=6031, tid=7
 #
 # JRE version: 6.0_20-b02
 # Java VM: Java HotSpot(TM) Client VM (16.3-b01 mixed mode, sharing 
 solaris-x86 )
 # Problematic frame:
 # C  [java+0x1588]  main+0xd0
 #
 # An error report file with more information is saved as:
 # /data/opt/glafish/.hudson/jobs/MyProject/workspace/trunk/hs_err_pid6031.log
 #
 # If you would like to submit a bug report, please visit:
 #   http://java.sun.com/webapps/bugreport/crash.jsp
 #
 ERROR: Maven JVM terminated unexpectedly with exit code 6
 ### 3 ###
 [INFO] Generating Checkstyle report.
 [INFO] Generating Cobertura Test Coverage report.
 [INFO] Cobertura Report generation was successful.
 [INFO] Cobertura Report generation was successful.
 [INFO] Generating JavaDocs report.
 [WARNING] The Javadoc plugin parameter 'proxyHost' is deprecated since 2.4. 
 Please configure an active proxy in your settings.xml.
 [WARNING] The Javadoc plugin parameter 'proxyPort' is deprecated since 2.4. 
 Please configure an active proxy in your settings.xml.
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGSEGV (0xb) at pc=0x2e736c63, pid=14882, tid=7
 #
 # JRE version: 6.0_20-b02
 # Java VM: Java HotSpot(TM) Client VM (16.3-b01 mixed mode, sharing 
 solaris-x86 )
 # Problematic frame:
 # C  0x2e736c63
 #
 # An error report file with more information is saved as:
 # 
 /data/opt/glafish/.hudson/jobs/MyProject_REPORT/workspace/trunk/components/abc/tool/target/site/apidocs/hs_err_pid14882.log
 #
 # If you would like to submit a bug report, please visit:
 #   http://java.sun.com/webapps/bugreport/crash.jsp
 #
 [HUDSON] Archiving site from 
 /data/opt/glafish/.hudson/jobs/MyProject_REPORT/workspace/trunk/components/abc/tool/target/site
  to /data/opt/glafish/.hudson/jobs/MyProject_REPORT/site/tool
 [HUDSON] Archiving disabled - not archiving 
 /data/opt/glafish/.hudson/jobs/MyProject_REPORT/workspace/trunk/components/abc/tool/pom.xml
 [HUDSON] Archiving disabled - not archiving 
 /data/opt/glafish/.hudson/jobs/MyProject_REPORT/workspace/trunk/components/abc/tool/target/tool-0.9-SNAPSHOT-bnull.jar
 [HUDSON] Archiving disabled - not archiving 
 

[jira] Commented: (SUREFIRE-623) Docs say that Java 1.3 is supported, but minimum version is 1.4

2010-11-29 Thread Kristian Rosenvold (JIRA)

[ 
http://jira.codehaus.org/browse/SUREFIRE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=245641#action_245641
 ] 

Kristian Rosenvold commented on SUREFIRE-623:
-

Just for the general heck of it I have restored jdk 1.3 compatibility in the 
upcoming surefire 2.7, and I am able to run the project you supplied with 1.3. 





 Docs say that Java 1.3 is supported, but minimum version is 1.4
 ---

 Key: SUREFIRE-623
 URL: http://jira.codehaus.org/browse/SUREFIRE-623
 Project: Maven Surefire
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.5
 Environment: 
 http://maven.apache.org/plugins/maven-surefire-plugin/plugin-info.html
Reporter: SebbASF
 Fix For: 2.6


 http://maven.apache.org/plugins/maven-surefire-plugin/plugin-info.html
 says:
 The following specifies the minimum requirements to run this Maven plugin:
 Maven 2.0.9
 JDK   1.3
 However I get the following error when using jvm 1.3:
 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/booter/SurefireBooter
 Exception in thread main
 Works OK with Java 1.4

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




[jira] Closed: (MPIR-180) Repositories which require authentication get blacklisted

2010-11-29 Thread Vincent Siveton (JIRA)

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

Vincent Siveton closed MPIR-180.


   Resolution: Fixed
Fix Version/s: 2.3
 Assignee: Vincent Siveton

refactored code to take care of auth defined in your settings.xml in r1040071, 
snapshot deployed.

 Repositories which require authentication get blacklisted
 -

 Key: MPIR-180
 URL: http://jira.codehaus.org/browse/MPIR-180
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: dependencies
Affects Versions: 2.1.2
 Environment: maven 2.2.1
 maven-site-plugin 2.1
Reporter: Stevo Slavic
Assignee: Vincent Siveton
 Fix For: 2.3


 Dependencies report when rendering dependency repository locations wrongfully 
 blacklists repositories which require authentication.
 Bug is in DependenciesRenderer, void blacklistRepositoryMap( Map repos, List 
 repoUrlBlackListed ) method, ProjectInfoReportUtils.getInputStream( repoUrl, 
 settings ) call throws IOException (java.io.IOException: Server returned 
 HTTP response code: 401 for URL: ...) if repoUrl is URL of a repository 
 which requires authentication.

-- 
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: (MRESOURCES-130) Using within a delimiter does not work

2010-11-29 Thread Christian (JIRA)
Using  within a delimiter does not work


 Key: MRESOURCES-130
 URL: http://jira.codehaus.org/browse/MRESOURCES-130
 Project: Maven 2.x Resources Plugin
  Issue Type: Bug
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_20
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Christian


Hi guys,

I am trying to use the pattern %=*% as a delimiter and it is not working.

This is the snippet from my pom.xml:
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.4.3/version
configuration
   delimiters
  delimiterlt;%= * %/delimiter
   /delimiters
   encodingUTF-8/encoding
/configuration
 /plugin

The resource plugin seems to handle that well like its output let me guess:
[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources' --
[DEBUG]   (f) buildFilters = [C:\.properties]
[DEBUG]   (s) delimiters = [%= * %, lll]
[DEBUG]   (f) encoding = UTF-8
[DEBUG]   (f) escapeWindowsPaths = true
[DEBUG]   (s) includeEmptyDirs = false
[DEBUG]   (s) outputDirectory = C:\
[DEBUG]   (s) overwrite = false
...
[DEBUG]   (f) useBuildFilters = true
[DEBUG]   (s) useDefaultDelimiters = false
[DEBUG] -- end configuration --

Looking into the resulting files shows me that NOTHING was filtered...
I also tried specifying the delimiter like this:
delimiter%=*%/delimiter
delimiterlt;%=*%/delimiter
delimiter#60;%=*%/delimiter
delimiter![CDATA[%=*%]]/delimiter

Nothing worked.

Please fix this or give me any hint what I am doing wrong. I didnt get a reply 
on the mailing list 
(http://maven.40175.n5.nabble.com/Using-lt-gt-as-delimiter-td3265330.html).

Thx a lot

Cheers
Christian

-- 
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: (MRESOURCES-130) Using within a delimiter does not work

2010-11-29 Thread Christian (JIRA)

[ 
http://jira.codehaus.org/browse/MRESOURCES-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=245646#action_245646
 ] 

Christian commented on MRESOURCES-130:
--

Hm damn it... How do i escape escaping here?! I mean i also tried using lt; and 
#60; each with an ampersand before it.

 Using  within a delimiter does not work
 

 Key: MRESOURCES-130
 URL: http://jira.codehaus.org/browse/MRESOURCES-130
 Project: Maven 2.x Resources Plugin
  Issue Type: Bug
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
 Java version: 1.6.0_20
 Default locale: de_DE, platform encoding: Cp1252
 OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Christian

 Hi guys,
 I am trying to use the pattern %=*% as a delimiter and it is not working.
 This is the snippet from my pom.xml:
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-resources-plugin/artifactId
 version2.4.3/version
 configuration
delimiters
   delimiterlt;%= * %/delimiter
/delimiters
encodingUTF-8/encoding
 /configuration
  /plugin
 The resource plugin seems to handle that well like its output let me guess:
 [DEBUG] Configuring mojo 
 'org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources' --
 [DEBUG]   (f) buildFilters = [C:\.properties]
 [DEBUG]   (s) delimiters = [%= * %, lll]
 [DEBUG]   (f) encoding = UTF-8
 [DEBUG]   (f) escapeWindowsPaths = true
 [DEBUG]   (s) includeEmptyDirs = false
 [DEBUG]   (s) outputDirectory = C:\
 [DEBUG]   (s) overwrite = false
 ...
 [DEBUG]   (f) useBuildFilters = true
 [DEBUG]   (s) useDefaultDelimiters = false
 [DEBUG] -- end configuration --
 Looking into the resulting files shows me that NOTHING was filtered...
 I also tried specifying the delimiter like this:
 delimiter%=*%/delimiter
 delimiterlt;%=*%/delimiter
 delimiter#60;%=*%/delimiter
 delimiter![CDATA[%=*%]]/delimiter
 Nothing worked.
 Please fix this or give me any hint what I am doing wrong. I didnt get a 
 reply on the mailing list 
 (http://maven.40175.n5.nabble.com/Using-lt-gt-as-delimiter-td3265330.html).
 Thx a lot
 Cheers
 Christian

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




[jira] Closed: (MPIR-181) Dependency reporting plugin overwrites other project's artifact file

2010-11-29 Thread Vincent Siveton (JIRA)

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

Vincent Siveton closed MPIR-181.


Resolution: Fixed

should be fixed with MPIR-158

 Dependency reporting plugin overwrites other project's artifact file
 

 Key: MPIR-181
 URL: http://jira.codehaus.org/browse/MPIR-181
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
 Environment: Linux
Reporter: blaabloo

 Projectmap is map of artifacts with groupid:artifactid being the key. When 
 project has multiple artifacts only one of them is put to the map. Dependency 
 node contains information about artifact and file information is the same 
 reference as used DefaultLifecycleExecutor. Every dependency's file is set 
 from this map and when building multimodule projects the latter projects may 
 fail because project's default artifact file is set to one of its attached 
 artifacts.
 In org.apache.maven.report.projectinfo.dependencies.Dependencies
 private void mapArtifactFiles( DependencyNode node, Map projectMap )
 {
 List childs = node.getChildren();
 if ( ( childs == null ) || childs.isEmpty() )
 {
 return;
 }
 Iterator it = childs.iterator();
 while ( it.hasNext() )
 {
 DependencyNode anode = (DependencyNode) it.next();
 String key = ArtifactUtils.versionlessKey( anode.getArtifact() );
 Artifact projartifact = (Artifact) projectMap.get( key );
 if ( projartifact != null )
 {
 anode.getArtifact().setFile( projartifact.getFile() );
 }
 mapArtifactFiles( anode, projectMap );
 }
 }

-- 
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-4921) Improve POM model

2010-11-29 Thread Vincent Siveton (JIRA)
Improve POM model
-

 Key: MNG-4921
 URL: http://jira.codehaus.org/browse/MNG-4921
 Project: Maven 2  3
  Issue Type: New Feature
  Components: POM
Affects Versions: 3.0.1
Reporter: Vincent Siveton


The POM model was not enhanced in m3 for backward compatible reasons.
Some users ask to add qualityMangement section (MPIR-149) and javadoc link 
(MJAVADOC-32).
We need to have a plan to include them.


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




[jira] Commented: (MPIR-147) Dependencies report hangs while accessing SSL site. Connection never closes

2010-11-29 Thread Vincent Siveton (JIRA)

[ 
http://jira.codehaus.org/browse/MPIR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=245657#action_245657
 ] 

Vincent Siveton commented on MPIR-147:
--

I bumped to latest wagon r1040075 (snap deployed). Confirm if it solves the pb.

 Dependencies report hangs while accessing SSL site. Connection never closes
 ---

 Key: MPIR-147
 URL: http://jira.codehaus.org/browse/MPIR-147
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: dependencies
Affects Versions: 2.1
Reporter: Jerome Lacoste

 mvn site hangs while generating the reports (dump below). This is 100% 
 reproducible.
 This happens while contacting maven-repository.dev.java.net. The connection 
 is opened and never closed. The connection to this external repository was 
 done successfully several time in the same build.
 Notes:
 * a timeout would be useful:
 at 
 org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
 at 
 org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
 * for some reason, the site report bypass our corporate repository (nexus). 
 Cf MPIR-137
 * workaround is to enable
   dependencyLocationsEnabledfalse/dependencyLocationsEnabled
   dependencyDetailsEnabledfalse/dependencyDetailsEnabled
 as done in MPIR-137
 Full thread dump Java HotSpot(TM) Client VM (1.5.0_16-133 mixed mode):
 AWT-AppKit daemon prio=5 tid=0x01038530 nid=0xa0110fa0 runnable 
 [0x..0xbfffe818]
 Low Memory Detector daemon prio=5 tid=0x01009030 nid=0x805800 runnable 
 [0x..0x]
 CompilerThread0 daemon prio=9 tid=0x01008580 nid=0x812c00 waiting on 
 condition [0x..0xb0b077d8]
 Signal Dispatcher daemon prio=9 tid=0x01008130 nid=0x811e00 waiting on 
 condition [0x..0x]
 Finalizer daemon prio=8 tid=0x01007860 nid=0x819200 in Object.wait() 
 [0xb0a05000..0xb0a05d90]
 at java.lang.Object.wait(Native Method)
 - waiting on 0x0a440228 (a java.lang.ref.ReferenceQueue$Lock)
 at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
 - locked 0x0a440228 (a java.lang.ref.ReferenceQueue$Lock)
 at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
 at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
 Reference Handler daemon prio=10 tid=0x01007480 nid=0x817800 in 
 Object.wait() [0xb0984000..0xb0984d90]
 at java.lang.Object.wait(Native Method)
 - waiting on 0x0a4402b0 (a java.lang.ref.Reference$Lock)
 at java.lang.Object.wait(Object.java:474)
 at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
 - locked 0x0a4402b0 (a java.lang.ref.Reference$Lock)
 main prio=5 tid=0x01001570 nid=0xb0801000 runnable [0xb07fe000..0xb0800148]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:129)
 at 
 com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
 at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
 at 
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)
 - locked 0x05a4ba78 (a java.lang.Object)
 at 
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680)
 at 
 com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
 - locked 0x05a4bb28 (a com.sun.net.ssl.internal.ssl.AppInputStream)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
 at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
 - locked 0x06b58100 (a java.io.BufferedInputStream)
 at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681)
 at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
 at 
 sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:957)
 - locked 0x06b56708 (a 
 sun.net.www.protocol.https.DelegateHttpsURLConnection)
 at 
 java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
 at 
 sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
 at 
 org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
 at 
 org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
 at 
 

[jira] Updated: (MNG-4921) Improve POM model with sections for qualityManagement and JavaDoc link

2010-11-29 Thread Brett Porter (JIRA)

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

Brett Porter updated MNG-4921:
--

Summary: Improve POM model with sections for qualityManagement and JavaDoc 
link  (was: Improve POM model)

Made the summary more descriptive as there are several such elements.

I'm skeptical on a specific Javadoc link, since that would be fairly language 
specific for a top level POM element. Maybe some generic keyed links might be 
more appropriate.

 Improve POM model with sections for qualityManagement and JavaDoc link
 --

 Key: MNG-4921
 URL: http://jira.codehaus.org/browse/MNG-4921
 Project: Maven 2  3
  Issue Type: New Feature
  Components: POM
Affects Versions: 3.0.1
Reporter: Vincent Siveton

 The POM model was not enhanced in m3 for backward compatible reasons.
 Some users ask to add qualityMangement section (MPIR-149) and javadoc link 
 (MJAVADOC-32).
 We need to have a plan to include them.

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




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

2010-11-29 Thread Vincent Siveton (JIRA)

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

Vincent Siveton closed MPIR-194.


   Resolution: Not A Bug
Fix Version/s: 2.3

Should be fixed in latest maven-site-plugin (2.2)

 [WARNING] Deprecated API called
 ---

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


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

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




[jira] Created: (MDEP-294) copy-dependencies goal doesn't properly respect classifier when creating base version of snapshots

2010-11-29 Thread Tim Downey (JIRA)
copy-dependencies goal doesn't properly respect classifier when creating base 
version of snapshots
--

 Key: MDEP-294
 URL: http://jira.codehaus.org/browse/MDEP-294
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy-dependencies
Affects Versions: 2.1
Reporter: Tim Downey
Assignee: Brian Fox
 Attachments: CopyDependenciesMojo.java, CopyDependenciesMojo.java.diff

CopyDependenciesMojo ignores any classifier on the artifact being copied when 
creating the base version of a snapshot.  It works correctly for the non-base 
(timestamped) version.  This leads to a mismatch in the copied dependencies 
where the timestamped version correctly keeps the classifier, but the base 
-SNAPSHOT version has the classifier completely dropped.

The fix is simple, although a bit ugly.  In the installBaseSnapshot method, a 
check must be made for the presence of a classifier on the artifact being 
copied before using the ArtifactFactory to create a copy of the base version.  
Ideally, the ArtifactFactory would expose a single method that takes all 
parameters, but unfortunately it does not.  This requires a separate 'if' check 
for the presence of a classifier.

Another potential issue is that the method 
ArtifactFactory#createArtifactWithClassifier has no parameter for scope.  I 
don't think that causes any issue in this case, but is another reason why there 
should be a single method createArtifact that takes all combinations of 
parameters including classifier.

I've attached a patch that will fix the issue, but not a test case since it 
looks like the maven-plugin-testing-tools-harness would need to be updated as 
well.  It doesn't appear to expose any artifacts that both have a classifier 
and are snapshots from the ArtifactStubFactory.  If deemed important, I can 
produce a patch for that as well along with a test.

-- 
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: (MDEPLOY-126) Deploy only artifacts which have been explicitly attached

2010-11-29 Thread Matthias Vach (JIRA)
Deploy only artifacts which have been explicitly attached
-

 Key: MDEPLOY-126
 URL: http://jira.codehaus.org/browse/MDEPLOY-126
 Project: Maven 2.x Deploy Plugin
  Issue Type: Improvement
Affects Versions: 2.5
 Environment: Maven 3
Reporter: Matthias Vach
 Attachments: 001.diff

Hi all,
General Information:

while releasing maven projects we do generate release metadata for any project. 
The generated metadate need to be uploaded to nexus and are located right 
beside the build results.
Since we don't want to affect the release build iselfe, the whole metadata 
generation runs as a second build after the release build finished.

Now the problem:

We want to use the deploy plugin to deploy the generated release metadata to 
nexus. But the deploy plugin is currently attaching project artifacts and 
pom-files automatically to the deployment. But this causes a HTTP-400 Error at 
Nexus, since all pom-files and project artifacts have been deployed to Nexus 
already. And redeployment is not allowed.

Currently missing:

It would be cool if the deploy plugin would offer a switch to reduce the 
deployment only to those artifacts/files which have been explicitly attached 
for deployment in the reactor before.

Attached you do find a small patch.

Regards Matthias

-- 
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: (MDEP-294) copy-dependencies goal doesn't properly respect classifier when creating base version of snapshots

2010-11-29 Thread Brian Fox (JIRA)

[ 
http://jira.codehaus.org/browse/MDEP-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=245691#action_245691
 ] 

Brian Fox commented on MDEP-294:


Can you add a test?

 copy-dependencies goal doesn't properly respect classifier when creating base 
 version of snapshots
 --

 Key: MDEP-294
 URL: http://jira.codehaus.org/browse/MDEP-294
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy-dependencies
Affects Versions: 2.1
Reporter: Tim Downey
Assignee: Brian Fox
 Attachments: CopyDependenciesMojo.java, CopyDependenciesMojo.java.diff


 CopyDependenciesMojo ignores any classifier on the artifact being copied when 
 creating the base version of a snapshot.  It works correctly for the non-base 
 (timestamped) version.  This leads to a mismatch in the copied dependencies 
 where the timestamped version correctly keeps the classifier, but the base 
 -SNAPSHOT version has the classifier completely dropped.
 The fix is simple, although a bit ugly.  In the installBaseSnapshot method, a 
 check must be made for the presence of a classifier on the artifact being 
 copied before using the ArtifactFactory to create a copy of the base version. 
  Ideally, the ArtifactFactory would expose a single method that takes all 
 parameters, but unfortunately it does not.  This requires a separate 'if' 
 check for the presence of a classifier.
 Another potential issue is that the method 
 ArtifactFactory#createArtifactWithClassifier has no parameter for scope.  I 
 don't think that causes any issue in this case, but is another reason why 
 there should be a single method createArtifact that takes all combinations of 
 parameters including classifier.
 I've attached a patch that will fix the issue, but not a test case since it 
 looks like the maven-plugin-testing-tools-harness would need to be updated as 
 well.  It doesn't appear to expose any artifacts that both have a classifier 
 and are snapshots from the ArtifactStubFactory.  If deemed important, I can 
 produce a patch for that as well along with a test.

-- 
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: (MDEP-294) copy-dependencies goal doesn't properly respect classifier when creating base version of snapshots

2010-11-29 Thread Tim Downey (JIRA)

[ 
http://jira.codehaus.org/browse/MDEP-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=245692#action_245692
 ] 

Tim Downey commented on MDEP-294:
-

It looks like the artifacts used in the test cases come from the 
maven-plugin-testing-tools-harness (The artifacts supplied by the current 
harness don't have any that use a classifier and are snapshot).  If so, I'd 
need to modify that as well, right?  Would I submit a patch for both to this 
ticket?

 copy-dependencies goal doesn't properly respect classifier when creating base 
 version of snapshots
 --

 Key: MDEP-294
 URL: http://jira.codehaus.org/browse/MDEP-294
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy-dependencies
Affects Versions: 2.1
Reporter: Tim Downey
Assignee: Brian Fox
 Attachments: CopyDependenciesMojo.java, CopyDependenciesMojo.java.diff


 CopyDependenciesMojo ignores any classifier on the artifact being copied when 
 creating the base version of a snapshot.  It works correctly for the non-base 
 (timestamped) version.  This leads to a mismatch in the copied dependencies 
 where the timestamped version correctly keeps the classifier, but the base 
 -SNAPSHOT version has the classifier completely dropped.
 The fix is simple, although a bit ugly.  In the installBaseSnapshot method, a 
 check must be made for the presence of a classifier on the artifact being 
 copied before using the ArtifactFactory to create a copy of the base version. 
  Ideally, the ArtifactFactory would expose a single method that takes all 
 parameters, but unfortunately it does not.  This requires a separate 'if' 
 check for the presence of a classifier.
 Another potential issue is that the method 
 ArtifactFactory#createArtifactWithClassifier has no parameter for scope.  I 
 don't think that causes any issue in this case, but is another reason why 
 there should be a single method createArtifact that takes all combinations of 
 parameters including classifier.
 I've attached a patch that will fix the issue, but not a test case since it 
 looks like the maven-plugin-testing-tools-harness would need to be updated as 
 well.  It doesn't appear to expose any artifacts that both have a classifier 
 and are snapshots from the ArtifactStubFactory.  If deemed important, I can 
 produce a patch for that as well along with a test.

-- 
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-527) Issue warning if run from Maven 3

2010-11-29 Thread Jesse Glick (JIRA)
Issue warning if run from Maven 3
-

 Key: MSITE-527
 URL: http://jira.codehaus.org/browse/MSITE-527
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Jesse Glick
Priority: Minor


The 2.x plugin should issue a warning linking to e.g. 
http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html if 
you attempt to run it from Maven 3.x.

-- 
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: (MRESOURCES-130) Using within a delimiter does not work

2010-11-29 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MRESOURCES-130:
---

Description: 
Hi guys,

I am trying to use the pattern %=*% as a delimiter and it is not working.

This is the snippet from my pom.xml:
{code}
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.4.3/version
configuration
   delimiters
  delimiterlt;%= * %/delimiter
   /delimiters
   encodingUTF-8/encoding
/configuration
 /plugin
{code}

The resource plugin seems to handle that well like its output let me guess:
{noformat}
[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources' --
[DEBUG]   (f) buildFilters = [C:\.properties]
[DEBUG]   (s) delimiters = [%= * %, lll]
[DEBUG]   (f) encoding = UTF-8
[DEBUG]   (f) escapeWindowsPaths = true
[DEBUG]   (s) includeEmptyDirs = false
[DEBUG]   (s) outputDirectory = C:\
[DEBUG]   (s) overwrite = false
...
[DEBUG]   (f) useBuildFilters = true
[DEBUG]   (s) useDefaultDelimiters = false
[DEBUG] -- end configuration --
{noformat}

Looking into the resulting files shows me that NOTHING was filtered...
I also tried specifying the delimiter like this:
{code}
delimiter%=*%/delimiter
delimiterlt;%=*%/delimiter
delimiter#60;%=*%/delimiter
delimiter![CDATA[%=*%]]/delimiter
{code}

Nothing worked.

Please fix this or give me any hint what I am doing wrong. I didnt get a reply 
on the mailing list 
(http://maven.40175.n5.nabble.com/Using-lt-gt-as-delimiter-td3265330.html).

Thx a lot

Cheers
Christian

  was:
Hi guys,

I am trying to use the pattern %=*% as a delimiter and it is not working.

This is the snippet from my pom.xml:
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.4.3/version
configuration
   delimiters
  delimiterlt;%= * %/delimiter
   /delimiters
   encodingUTF-8/encoding
/configuration
 /plugin

The resource plugin seems to handle that well like its output let me guess:
[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources' --
[DEBUG]   (f) buildFilters = [C:\.properties]
[DEBUG]   (s) delimiters = [%= * %, lll]
[DEBUG]   (f) encoding = UTF-8
[DEBUG]   (f) escapeWindowsPaths = true
[DEBUG]   (s) includeEmptyDirs = false
[DEBUG]   (s) outputDirectory = C:\
[DEBUG]   (s) overwrite = false
...
[DEBUG]   (f) useBuildFilters = true
[DEBUG]   (s) useDefaultDelimiters = false
[DEBUG] -- end configuration --

Looking into the resulting files shows me that NOTHING was filtered...
I also tried specifying the delimiter like this:
delimiter%=*%/delimiter
delimiterlt;%=*%/delimiter
delimiter#60;%=*%/delimiter
delimiter![CDATA[%=*%]]/delimiter

Nothing worked.

Please fix this or give me any hint what I am doing wrong. I didnt get a reply 
on the mailing list 
(http://maven.40175.n5.nabble.com/Using-lt-gt-as-delimiter-td3265330.html).

Thx a lot

Cheers
Christian


 Using  within a delimiter does not work
 

 Key: MRESOURCES-130
 URL: http://jira.codehaus.org/browse/MRESOURCES-130
 Project: Maven 2.x Resources Plugin
  Issue Type: Bug
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
 Java version: 1.6.0_20
 Default locale: de_DE, platform encoding: Cp1252
 OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Christian

 Hi guys,
 I am trying to use the pattern %=*% as a delimiter and it is not working.
 This is the snippet from my pom.xml:
 {code}
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-resources-plugin/artifactId
 version2.4.3/version
 configuration
delimiters
   delimiterlt;%= * %/delimiter
/delimiters
encodingUTF-8/encoding
 /configuration
  /plugin
 {code}
 The resource plugin seems to handle that well like its output let me guess:
 {noformat}
 [DEBUG] Configuring mojo 
 'org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources' --
 [DEBUG]   (f) buildFilters = [C:\.properties]
 [DEBUG]   (s) delimiters = [%= * %, lll]
 [DEBUG]   (f) encoding = UTF-8
 [DEBUG]   (f) escapeWindowsPaths = true
 [DEBUG]   (s) includeEmptyDirs = false
 [DEBUG]   (s) outputDirectory = C:\
 [DEBUG]   (s) overwrite = false
 ...
 [DEBUG]   (f) useBuildFilters = true
 [DEBUG]   (s) useDefaultDelimiters = false
 [DEBUG] -- end configuration --
 {noformat}
 Looking into the resulting files shows me that NOTHING was filtered...
 I also 

[jira] Closed: (MANTRUN-159) Error in Referencing the Maven Classpaths documentation

2010-11-29 Thread Paul Gier (JIRA)

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

Paul Gier closed MANTRUN-159.
-

   Resolution: Fixed
Fix Version/s: 1.7
 Assignee: Paul Gier

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

 Error in Referencing the Maven Classpaths documentation 
 --

 Key: MANTRUN-159
 URL: http://jira.codehaus.org/browse/MANTRUN-159
 Project: Maven 2.x Antrun Plugin
  Issue Type: Bug
Affects Versions: 1.6
Reporter: David Cramer
Assignee: Paul Gier
 Fix For: 1.7


 On the page 
 https://maven.apache.org/plugins/maven-antrun-plugin/examples/classpaths.html 
 it says:
 A property is set for each dependency with the format 
 groupId:artifactId[:classifier]:type. For example, to show the path to a 
 dependency with groupId org.apache and artifactId common-util, the 
 following could be used.
 The position of the classifier in the property is not accurate, however. 
 Through trial and error, I have determined that it is instead:
 groupId:artifactId:type[:classifier]
 So for the following:
 dependency
   groupIdnet.sf.docbook/groupId
   artifactIddocbook-xml/artifactId
   typezip/type
   classifierresources/classifier
   version${docbook.schema.version}-all/version
 /dependency
 This works:
 $${net.sf.docbook:docbook-xsl:zip:ns-resources}=
  ${net.sf.docbook:docbook-xsl:zip:ns-resources}
 But this does not work:
 $${net.sf.docbook:docbook-xsl:ns-resources:zip}=
  ${net.sf.docbook:docbook-xsl:ns-resources:zip}
 Change the sentence to the following.
 A property is set for each dependency with the format 
 groupId:artifactId:type[:classifier]. For example, to show the path to a 
 dependency with groupId org.apache and artifactId common-util, the 
 following could be used.
 It might be helpful to include an example that has a classifier 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: (DOXIASITETOOLS-41) allow declaring google analytics code in maven generated website

2010-11-29 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg moved MSITE-161 to DOXIASITETOOLS-41:
-

Key: DOXIASITETOOLS-41  (was: MSITE-161)
Project: Maven Doxia Sitetools  (was: Maven 2.x Site Plugin)

 allow declaring google analytics code in maven generated website
 

 Key: DOXIASITETOOLS-41
 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-41
 Project: Maven Doxia Sitetools
  Issue Type: New Feature
Reporter: Milos Kleint

 as per discussion with trygve, i'm adding this issue. 
 I have a non maven-site-plugin solution at mojo.codehaus.org  that does 
 postprocessing of the generated site. 
 http://fisheye.codehaus.org/browse/mojo/trunk/mojo/mojo-sandbox/ganalytics-maven-mojo

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




[jira] Closed: (DOXIASITETOOLS-41) Allow declaring Google Analytics code in generated site

2010-11-29 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed DOXIASITETOOLS-41.
-

Resolution: Fixed

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

 Allow declaring Google Analytics code in generated site
 ---

 Key: DOXIASITETOOLS-41
 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-41
 Project: Maven Doxia Sitetools
  Issue Type: New Feature
  Components: Decoration model, Site renderer
Affects Versions: 1.1.4
Reporter: Milos Kleint
Assignee: Dennis Lundberg
 Fix For: 1.2


 as per discussion with trygve, i'm adding this issue. 
 I have a non maven-site-plugin solution at mojo.codehaus.org  that does 
 postprocessing of the generated site. 
 http://fisheye.codehaus.org/browse/mojo/trunk/mojo/mojo-sandbox/ganalytics-maven-mojo

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




[jira] Updated: (DOXIASITETOOLS-41) Allow declaring Google Analytics code in generated site

2010-11-29 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated DOXIASITETOOLS-41:
--

  Component/s: Site renderer
   Decoration model
Affects Version/s: 1.1.4
Fix Version/s: 1.2
 Assignee: Dennis Lundberg
  Summary: Allow declaring Google Analytics code in generated site  
(was: allow declaring google analytics code in maven generated website)

 Allow declaring Google Analytics code in generated site
 ---

 Key: DOXIASITETOOLS-41
 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-41
 Project: Maven Doxia Sitetools
  Issue Type: New Feature
  Components: Decoration model, Site renderer
Affects Versions: 1.1.4
Reporter: Milos Kleint
Assignee: Dennis Lundberg
 Fix For: 1.2


 as per discussion with trygve, i'm adding this issue. 
 I have a non maven-site-plugin solution at mojo.codehaus.org  that does 
 postprocessing of the generated site. 
 http://fisheye.codehaus.org/browse/mojo/trunk/mojo/mojo-sandbox/ganalytics-maven-mojo

-- 
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