date:20070601

Dont generate javadoc report if project has pom packaging
-

 Key: MJAVADOC-125
 URL: http://jira.codehaus.org/browse/MJAVADOC-125
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Vincent Siveton




-- 
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-2671) Parent/modules relative file path compression


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

John Casey closed MNG-2671.
---

Resolution: Fixed

 Parent/modules relative file path compression
 -

 Key: MNG-2671
 URL: http://jira.codehaus.org/browse/MNG-2671
 Project: Maven 2
  Issue Type: Improvement
  Components: Inheritance and Interpolation
Affects Versions: 2.0.4
 Environment: Windows XP
Reporter: Vincent Beretti
Priority: Minor
 Attachments: MNG-2671-maven-project.patch


 Sometimes a problem appears in M2 with parent and module structure due to
 the OS limitation in filepath length.
 For example Windows file path can not exceed 255 characters.
 But in complex maven 2 structure of parent/modules we can encounter a
 problem with that.
 In Eclipse, one has to put children projects in a flat structure.
 Example :
 in my filesystem my projects are :
 C:/
 |-- parentProject/
 |-- childprojectA/
 |-- childProjectB/
 But in maven the structure is as following :
 parentProject
 |-- childProjectA
 |-- childProjectB
 So in childProjectX poms, I have to references parent project like this :
 relativePath../parentProject/relativePath and the same for modules in
 parent as modulesmodule../parentProject/module/modules
 On a very complex structure, I have a path longer than 255 but in fact i
 could be compressed to remove ..
 for example when maven deletes target dir, it does like this :
 delete C:/parentProject/../childProjectA/target
 instead it could do
 delete C:/childProjectA.
 This would reduce the path length in very complex structures.
 See the post at : 
 http://www.nabble.com/Parent-modules-File-path-compression-tf2628075s177.html

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

[jira] Closed: (MJAVADOC-125) Dont generate javadoc report if project has pom packaging


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

Vincent Siveton closed MJAVADOC-125.


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

Fixed

 Dont generate javadoc report if project has pom packaging
 -

 Key: MJAVADOC-125
 URL: http://jira.codehaus.org/browse/MJAVADOC-125
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Vincent Siveton
Assignee: Vincent Siveton
 Fix For: 2.3




-- 
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-728) Consider using java.net.useSystemProxies

2007-06-01 Thread Brett Porter (JIRA)


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

Brett Porter reopened MNG-728:
--


seems reasonable to me to provide the option, but not by default

 Consider using java.net.useSystemProxies
 

 Key: MNG-728
 URL: http://jira.codehaus.org/browse/MNG-728
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 2.0-alpha-3
Reporter: Kohsuke Kawaguchi
Priority: Minor
 Fix For: 2.1.x

 Attachments: maven-proxy-1.patch, maven-proxy-2.patch, 
 maven-proxy-3.patch


 Consider using the java.net.useSystemProxies property so that Maven can work 
 with a proxy without requring any user intervention.
 See http://weblogs.java.net/blog/kohsuke/archive/2005/08/we_deserve_a_be.html 
 for more information.

-- 
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-336) Allow single test path to use '.' delimiter

2007-06-01 Thread Brett Porter (JIRA)


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

Brett Porter updated SUREFIRE-336:
--

Fix Version/s: 2.3.1

 Allow single test path to use '.' delimiter
 ---

 Key: SUREFIRE-336
 URL: http://jira.codehaus.org/browse/SUREFIRE-336
 Project: Maven Surefire
  Issue Type: Improvement
  Components: plugin
Affects Versions: 2.3
Reporter: Paul Gier
 Fix For: 2.3.1

 Attachments: SurefirePlugin.patch


 Currently when running a single test with the surefire plugin.  The path to 
 the test has to be slash delimited
 mvn -Dtest=org/test/MyTest
 It would be convenient to be able to use the package name for the test like 
 this:
 mvn -Dtest=org.test.MyTest
 The patch is a very simple change to replace the '.' with '/' in the plugin.

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

[jira] Commented: (MNG-2399) file size check on pom.xml (or thing specified by --file opt) should only apply to regular files (patch attached)

2007-06-01 Thread Alan D. Salewski (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98073
 ] 

Alan D. Salewski commented on MNG-2399:
---

Well, one reason for reading the pom from a named pipe is that it facilitates 
using '{{mvn}}' from within shell scripts for performing tasks that leverage 
built\-in maven capabilities. For example, the attached '{{mvn\-get\-plugin}}' 
script retrieves and installs one or more maven plugins using a shell here 
document for the POM:

{noformat}
...
mvn --file /dev/stdin validate EOF
project
  modelVersion4.0.0/modelVersion
  groupIdfoo.bar.baz/groupId
  artifactIdfooshizzle/artifactId
  nameDummy Project for Retrieving and Installing ${plugin_name}/name
  versiondoes-not-matter/version
  build
plugins
  plugin
groupId${plugin_group_id}/groupId
artifactId${plugin_name}/artifactId
${plugin_version_elem}
  /plugin
/plugins
  /build
/project
EOF
...
{noformat}

It does this without creating any temporary files, which simplifies the program 
(there are no temporary file security bugs to worry about; there is no 
temporary directory to clean up when the program ends or when a signal is 
received, etc).

More generally, though, not fixing the issue leaves an arbitrary limitation in 
the program, and violates the principle of least surprise (encountering an 
error when attempting to specify '{{/dev/stdin}}' as an argument to the 
'{{\-\-file}}' option is what lead me to investigate the issue in the first 
place). One of the strengths of unix command line tools is that they are of 
general use and expected to be used in combination with other tools, even in 
ways that their original authors did not foresee. There is no benefit of 
leaving this easily addressed issue in maven, only an arbitrary limitation.

Some examples:
{noformat}
$ make -f /dev/stdin EOF
 all:
   @echo hello from stdin
 EOF
hello from stdin

$ ant -buildfile /dev/stdin EOF
 projectechohello from stdin/echo/project
 EOF
Buildfile: /dev/stdin
 [echo] hello from stdin

BUILD SUCCESSFUL
Total time: 0 seconds
{noformat}

And in case it gives anyone a warm and fuzzy, over the past year I've run maven 
2.0.4, 2.0.5, and now 2.0.6 with the originally attached (simple) patch without 
any problems.


 file size check on pom.xml (or thing specified by --file opt) should only 
 apply to regular files (patch attached)
 -

 Key: MNG-2399
 URL: http://jira.codehaus.org/browse/MNG-2399
 Project: Maven 2
  Issue Type: Bug
  Components: Command Line, General
Affects Versions: 2.0.4
Reporter: Alan D. Salewski
Priority: Minor
 Fix For: 2.0.x

 Attachments: MNG-2399-maven-core-2.0.4.patch, 
 MNG-2399-maven-core-trunk.patch, mvn-get-plugin


 The file size check in {{maven-core/.../org/apache/maven/DefaultMaven.java}} 
 is applied too aggressively. In particular, it should only be applied to 
 regular files; when reading from a unix named pipe (probably other 
 platform-specific devices, too) we may not be able to determine the file size 
 prior to reading the data.
 The real-world motiviation from this is the attached '{{mvn-get-plugin}}' 
 {{bash}} script, which wants to pipe a dummy {{pom.xml}} file to {{mvn}} on 
 {{stdin}} (by specifying {{/dev/stdin}} as the argument to the {{mvn}} 
 {{\-\-file}} command line option).
 Once I submit this issue and have the issue number, I'll attach two patches, 
 one against the maven svn trunk, and one against the {{maven-2.0.4}} tag.

-- 
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: (MNG-3028) plugin configuration issue (DefaultPluginManager.mergeMojoConfiguration)


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

Jason van Zyl moved MNGECLIPSE-290 to MNG-3028:
---

 Priority: (was: Major)
  Environment: (was: 0.0.11 using 
maven-embedder-2.1.0.v20070302-0821-dep.jar)
Affects Version/s: (was: 0.0.11)
   2.1.x
Fix Version/s: (was: 0.0.11)
  Key: MNG-3028  (was: MNGECLIPSE-290)
  Project: Maven 2  (was: Maven Integration for Eclipse)

 plugin configuration issue (DefaultPluginManager.mergeMojoConfiguration)
 

 Key: MNG-3028
 URL: http://jira.codehaus.org/browse/MNG-3028
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.1.x
Reporter: Cliff Resnick
Assignee: Jason van Zyl
 Attachments: sample-ejb-config.zip


 The embedder is throwing an error while configuring the xdoclet-maven-plugin. 
 The error message I get is: 
 on the command line, specify: '-DdummyExpression=VALUE'  
 Cause: Class 'org.codehaus.classworlds.ClassRealm' cannot be instantiated
 In debugging, I noticed that the dummyExpression is being introduced in 
 DefaultPluginManager.mergeMojoConfiguration, which takes two parameters 
 (pomConfiguration, mojoDescriptor)
 pomConfiguration (DOM)= 
 configuration
  tasks
   ejbdoclet excludedtags=@version,@author 
 destdir=${project.build.directory}/generated-sources/xdoclet ejbspec=2.0
fileset dir=src/main/java
 include name=**/*Bean.java/
/fileset
utilobject 
 destdir=${project.build.directory}/generated-sources/xdoclet/utilobject
mdb destdir=${project.build.directory}/generated-sources/xdoclet/mdb
localinterface 
 destdir=${project.build.directory}/generated-sources/xdoclet/
localhomeinterface 
 destdir=${project.build.directory}/generated-sources/xdoclet/
remoteinterface 
 destdir=${project.build.directory}/generated-sources/xdoclet/
homeinterface 
 destdir=${project.build.directory}/generated-sources/xdoclet/
deploymentdescriptor 
 destdir=${project.build.directory}/classes/META-INF/deploymentdescriptor
jboss destdir=${project.build.directory}/classes/META-INF 
 version=4.0/jboss
   /ejbdoclet
  /tasks
  classRealm/
  generatedSourcesDirectory/
  project/
  sourceDirectory/
 /configuration
 mojoDescriptor = 
 org.apache.maven.plugin.descriptor.MojoDescriptor [role: 
 'org.apache.maven.plugin.Mojo', hint: 
 'org.codehaus.mojo:xdoclet-maven-plugin:1.0-alpha-2:xdoclet' realm: 
 'org.codehaus.mojo:xdoclet-maven-plugin']
 what is returned is:
 ?xml version=1.0 encoding=UTF-8?
 configuration
  !-- where did this come from?: --
   classRealm 
 implementation=org.codehaus.classworlds.ClassRealm${dummyExpression}/classRealm
  
   generatedSourcesDirectory 
 implementation=java.lang.String${project.build.directory}/generated-sources/xdoclet/generatedSourcesDirectory
   project 
 implementation=org.apache.maven.project.MavenProject${project}/project
   sourceDirectory 
 implementation=java.lang.String${basedir}/src/main/java/sourceDirectory
   tasks implementation=org.apache.tools.ant.Target
 ejbdoclet excludedtags=@version,@author 
 destdir=${project.build.directory}/generated-sources/xdoclet ejbspec=2.0
   fileset dir=src/main/java
 include name=**/*Bean.java/
   /fileset
   utilobject 
 destdir=${project.build.directory}/generated-sources/xdoclet/utilobject
   mdb 
 destdir=${project.build.directory}/generated-sources/xdoclet/mdb
   localinterface 
 destdir=${project.build.directory}/generated-sources/xdoclet/
   localhomeinterface 
 destdir=${project.build.directory}/generated-sources/xdoclet/
   remoteinterface 
 destdir=${project.build.directory}/generated-sources/xdoclet/
   homeinterface 
 destdir=${project.build.directory}/generated-sources/xdoclet/
   deploymentdescriptor 
 destdir=${project.build.directory}/classes/META-INF/deploymentdescriptor
   jboss destdir=${project.build.directory}/classes/META-INF 
 version=4.0/jboss
 /ejbdoclet${tasks}/tasks
 /configuration
 The top-level stack trace is kind of misleading:
 org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring: 
 org.codehaus.mojo:xdoclet-maven-plugin. Reason: Unable to parse the created 
 DOM for plugin configuration
 If it helps, here is the original plugin config from my pom:
   plugin
   groupIdorg.codehaus.mojo/groupId
   artifactIdxdoclet-maven-plugin/artifactId
   executions
   execution
   phasegenerate-sources/phase
   goals

[jira] Commented: (MEV-524) Javadoc jar not uploaded correctly for digester

2007-06-01 Thread Carlos Sanchez (JIRA)


[ 
http://jira.codehaus.org/browse/MEV-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98080
 ] 

Carlos Sanchez commented on MEV-524:


iirc there were problems with that, i think putting them in /jars instead of 
/javadocs solved the problem

the code for the conversion is in archiva 
org.apache.maven.archiva.cli.ArchivaCli

 Javadoc jar not uploaded correctly for digester
 ---

 Key: MEV-524
 URL: http://jira.codehaus.org/browse/MEV-524
 Project: Maven Evangelism
  Issue Type: Bug
Reporter: Henri Yandell

 The migration of the javadoc jar from the Apache rsync to the central 
 repository doesn't seem to work well for javadocs - or more likely I did 
 something wrong. Any thoughts?
 http://repo1.maven.org/maven2/commons-digester/commons-digester/1.8/

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

[jira] Created: (MCHANGELOG-64) 'org.apache.maven.plugins:maven-zip-plugin' does not

2007-06-01 Thread Sankarapandian (JIRA)

'org.apache.maven.plugins:maven-zip-plugin' does not


 Key: MCHANGELOG-64
 URL: http://jira.codehaus.org/browse/MCHANGELOG-64
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.0
 Environment: WIndows Xp,Maven 2.06
Reporter: Sankarapandian


I am getting The plugin 'org.apache.maven.plugins:maven-zip-plugin' does not 
exist or
no valid version could be found .I removed the repository directory and tried 
again. Still i am getting the same error.

I am not able to replicate the bug in other workstations .I removed the 
repository directory and ran mvn install . But the plug in was installed.

-- 
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-1453) Exception error messages and i18n

2007-06-01 Thread Corridor Software Developer (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97919
 ] 

Corridor Software Developer commented on MNG-1453:
--

Is this something you are still interested in?


 Exception error messages and i18n
 -

 Key: MNG-1453
 URL: http://jira.codehaus.org/browse/MNG-1453
 Project: Maven 2
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Affects Versions: 2.0
 Environment: all
Reporter: Corridor Software Developer
 Fix For: 2.1.x


 Augment the exceptions thrown by components and plugins with a methodology 
 supporting internationlization (i18n) of error messages. 
 The framework would promote the use of readily translatable error message 
 tables by deprecating the use of the standard new Exception(message:String). 
 Each exception thrown by a plugin or component would have a code wrapped in 
 an error object for easy use. A JUnit test object would be available to 
 extend by component developers to immediately check for missing exception 
 strings.
 For a working example, look to the xmlbeans-maven-plugin in the codohaus 
 subversion repository.
 A patch will be attached for a single component for review, followed by a 
 comprehensive patch of the core.

-- 
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-2831) Cannot add custom artifact handler and custom lifecycle as a build extension

2007-06-01 Thread Vincent Massol (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97913
 ] 

Vincent Massol commented on MNG-2831:
-

FYI it is a regression from earlier. It used to work in 2.0.4 or 2.0.5.


 Cannot add custom artifact handler and custom lifecycle as a build extension
 

 Key: MNG-2831
 URL: http://jira.codehaus.org/browse/MNG-2831
 Project: Maven 2
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.5
Reporter: Vincent Massol
Assignee: Jason van Zyl
 Fix For: 2.0.7


 I have an extension registering a custom artifact handler and a custom 
 lifecycle against plexus. The project that uses that extension get the 
 following error:
 {noformat}
 [DEBUG] Error looking up lifecycle mapping to retrieve optional mojos. 
 Lifecycle ID: clean. Error: Component descriptor cannot be found in the 
 component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
 org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
 Component descriptor cannot be found in the component repository: 
 org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323)
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440)
 at 
 org.apache.maven.execution.MavenSession.lookup(MavenSession.java:123)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.findOptionalMojosForLifecycle(DefaultLifecycleExecutor.java:)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:999)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:980)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 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)
 [DEBUG] Skipping disabled repository codehaus.plugin.snapshots
 [DEBUG] Skipping disabled repository apache.snapshots
 [DEBUG] maven-clean-plugin: resolved to version 2.1 from repository central
 [DEBUG] Retrieving parent-POM: 
 org.apache.maven.plugins:maven-plugin-parent::2.0 for project: 
 null:maven-clean-plugin:maven-plugin:2.1 from the repository.
 [DEBUG] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.1:runtime 
 (selected for runtime)
 [DEBUG]   org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for 
 runtime)
 [DEBUG] Retrieving parent-POM: 
 org.apache.maven.shared:shared-components-parent::1 for project: 
 null:file-management:jar:1.0 from the repository.
 [DEBUG]   org.apache.maven.shared:file-management:jar:1.0:runtime (selected 
 for runtime)
 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for 
 runtime)
 [DEBUG] Configuring mojo 
 'org.apache.maven.plugins:maven-clean-plugin:2.1:clean' --
 [DEBUG]   (f) directory = 
 /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target
 [DEBUG]   (f) outputDirectory = 
 /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target/classes
 [DEBUG]   (f) testOutputDirectory = 
 /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target/test-classes
 [DEBUG] -- end configuration --
 [INFO] [clean:clean]
 [INFO]

[jira] Updated: (MRELEASE-128) SCM properties being replaced during release:perform

2007-06-01 Thread Stephane Nicoll (JIRA)


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

Stephane Nicoll updated MRELEASE-128:
-

Fix Version/s: 2.0

 SCM properties being replaced during release:perform
 

 Key: MRELEASE-128
 URL: http://jira.codehaus.org/browse/MRELEASE-128
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
 Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
Reporter: Craig Dickson
Assignee: Emmanuel Venisse
Priority: Critical
 Fix For: 2.0

 Attachments: after-release-perform-pom.xml, 
 after-release-prepre-pom.xml, original-pom.xml


 The scm section of a pom in CVS for a pom archetype project looks like this 
 prior to executing release:prepare :
 scm
   connection${base.cvs.url}:commons-maven/uber-pom/connection
   
 developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
   url${base.viewcvs.url}/commons-maven/uber-pom/url
 /scm
 Then after executing release:prepare, the pom in CVS looks like this (new 
 tag tag is only difference):
 scm
   connection${base.cvs.url}:commons-maven/uber-pom/connection
   
 developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
   url${base.viewcvs.url}/commons-maven/uber-pom/url
   tagR-1_7/tag
 /scm
 Then after executing release:perform, the pom looks like this in CVS:
 scm
   
 connectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/connection
   
 developerConnectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/developerConnection
   
 urlhttp://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom/url
 /scm
 Notice that the properties that were there for the base URLs for CVS and 
 ViewCVS have been replaced with literal values. 
 No other properties in the POM are being replaced

-- 
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-159) DBUnit not working from inside Maven2

2007-06-01 Thread Mike Rosseel (JIRA)


[ 
http://jira.codehaus.org/browse/SUREFIRE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97921
 ] 

Mike Rosseel commented on SUREFIRE-159:
---

not sure this is relevant information, but I had the same exception when 
running dbunit 2.2 in the TestNG eclipse plugin.
After looking into the code, the simple workaround is to pass an extra 'false' 
argument to the FlatXMLDataSet constructor.
This prevents dbunit from trying to set the lexical handler.

Running it with the maven2 surefire plugin gives the same error, so maybe 
surefire's not the problem; my guess is that it's caused by a wrong version of 
an xml parser somewhere.

 DBUnit not working from inside Maven2
 -

 Key: SUREFIRE-159
 URL: http://jira.codehaus.org/browse/SUREFIRE-159
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.0 (2.2 plugin)
 Environment: I'm using maven 2.0.4 with the Surefire plugin 2.2 to 
 test a couple of
 DAOs set up with Hibernate.
 At all tests i get the following exception, and I'm not able to find
 the cause, which I suspect lies within DBUnit 2.1...
Reporter: Bengt-Erik Fröberg
 Fix For: 2.4


 When running from Maven2 I get the following exception:
 Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 11.593 sec 
  FAILURE!
 testCreateEvent(ks.rah.avik2.dao.TestEventDao)  Time elapsed: 11.437 sec   
 ERROR!
 org.dbunit.dataset.DataSetException: org.xml.sax.SAXNotSupportedException: 
 not supported setting property http://xml.org/sax/properties/lexical-handler
   at 
 org.dbunit.dataset.xml.FlatXmlProducer.produce(FlatXmlProducer.java:165)
   at org.dbunit.dataset.CachedDataSet.init(CachedDataSet.java:71)
   at org.dbunit.dataset.xml.FlatXmlDataSet.init(FlatXmlDataSet.java:200)
   at org.dbunit.dataset.xml.FlatXmlDataSet.init(FlatXmlDataSet.java:187)
   at 
 ks.rah.avik2.dao.DBUnitOperationWrapper.getDataSet(DBUnitOperationWrapper.java:74)
   at 
 ks.rah.avik2.dao.DBUnitOperationWrapper.cleanInsert(DBUnitOperationWrapper.java:85)
   at 
 ks.rah.avik2.dao.AbstractDaoTestBase.onSetUp(AbstractDaoTestBase.java:65)
   at ks.rah.avik2.dao.TestEventDao.onSetUp(TestEventDao.java:38)
   at 
 org.springframework.test.AbstractDependencyInjectionSpringContextTests.setUp(AbstractDependencyInjectionSpringContextTests.java:192)
   at junit.framework.TestCase.runBare(TestCase.java:125)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:118)
   at junit.framework.TestSuite.runTest(TestSuite.java:208)
   at junit.framework.TestSuite.run(TestSuite.java:203)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at 
 org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
 org.xml.sax.SAXNotSupportedException: not supported setting property 
 http://xml.org/sax/properties/lexical-handler
   at org.gjt.xpp.sax2.Driver.setProperty(Driver.java:204)
   at 
 org.dbunit.dataset.xml.FlatDtdProducer.setLexicalHandler(FlatDtdProducer.java:87)
   at 
 org.dbunit.dataset.xml.FlatXmlProducer.produce(FlatXmlProducer.java:138)
   at org.dbunit.dataset.CachedDataSet.init(CachedDataSet.java:71)
   at org.dbunit.dataset.xml.FlatXmlDataSet.init(FlatXmlDataSet.java:200)
   at org.dbunit.dataset.xml.FlatXmlDataSet.init(FlatXmlDataSet.java:187)
   at 
 ks.rah.avik2.dao.DBUnitOperationWrapper.getDataSet(DBUnitOperationWrapper.java:74)
   at 
 ks.rah.avik2.dao.DBUnitOperationWrapper.cleanInsert(DBUnitOperationWrapper.java:85)
   at 
 ks.rah.avik2.dao.AbstractDaoTestBase.onSetUp(AbstractDaoTestBase.java:65)
   at

[jira] Closed: (MCHANGELOG-64) 'org.apache.maven.plugins:maven-zip-plugin' does not


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

Dennis Lundberg closed MCHANGELOG-64.
-

Resolution: Incomplete

Not relevant to this plugin.

 'org.apache.maven.plugins:maven-zip-plugin' does not
 

 Key: MCHANGELOG-64
 URL: http://jira.codehaus.org/browse/MCHANGELOG-64
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.0
 Environment: WIndows Xp,Maven 2.06
Reporter: Sankarapandian

 I am getting The plugin 'org.apache.maven.plugins:maven-zip-plugin' does not 
 exist or
 no valid version could be found .I removed the repository directory and 
 tried again. Still i am getting the same error.
 I am not able to replicate the bug in other workstations .I removed the 
 repository directory and ran mvn install . But the plug in was installed.

-- 
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: (MNG-2992) Batch file uses %HOME% - can set this to a value if blank

2007-06-01 Thread Tim Reilly (JIRA)


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

Tim Reilly updated MNG-2992:


Attachment: MNG-2992-maven-core.patch

Created new patch based on Developing Maven 2 : Creating and submitting a patch
Hopefully, this is right now.

 Batch file uses %HOME% - can set this to a value if blank
 -

 Key: MNG-2992
 URL: http://jira.codehaus.org/browse/MNG-2992
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Affects Versions: 2.0.6
 Environment: Windows_NT (WinXP)
Reporter: Tim Reilly
Priority: Minor
 Attachments: MNG-2992-maven-core.patch, mvn.bat.patch


 Batch file uses %HOME% let's set this to a nice value if blank. The patch 
 adds this line to set HOME to the value of 
 HOMEDRIVE + HOMEPATH

-- 
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-328) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedRuntimeException

2007-06-01 Thread uwe schaefer (JIRA)


[ 
http://jira.codehaus.org/browse/SUREFIRE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97932
 ] 

uwe schaefer commented on SUREFIRE-328:
---

we´re having exactly the same problem.

 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 -

 Key: SUREFIRE-328
 URL: http://jira.codehaus.org/browse/SUREFIRE-328
 Project: Maven Surefire
  Issue Type: Bug
  Components: TestNG support
Affects Versions: 2.4
 Environment: Windows XP
 Maven 2.0.6
Reporter: Wim Deblauwe
 Fix For: 2.4


 I just updated my surefire 2.4-SNAPSHOT plugin, but now I cannot build 
 anymore. I get a NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException. This is the console 
 output with the -e option:
 mvn -e clean test
 [INFO] [surefire:test]
 [INFO] Surefire report directory: C:\personal\vigilog\target\surefire-reports
 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 Exception in thread main
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.BuildFailureException: There are test failures.
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
 (DefaultLifecycleExecutor.java:560)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal 
 (DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments 
 (DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 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.MojoFailureException: There are test 
 failures.
 at org.apache.maven.plugin.surefire.SurefirePlugin.execute 
 (SurefirePlugin.java:413)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java
  :539)
 ... 16 more
 [INFO] 
 
 [INFO] Total time: 6 seconds
 [INFO] Finished at: Mon May 14 10:45:43 CEST 2007
 [INFO] Final Memory: 8M/25M
 [INFO] 
 
 I'm using the snapshot release because I use TestNG 5.5. Any solution to make 
 my build work again would be highly appriciated.
 regards,
 Wim

-- 
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] Work started: (MRM-394) default remote repositories central, java.net are not available in remote repositories list

2007-06-01 Thread Fabrice BELLINGARD (JIRA)


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

Work on MRM-394 started by Fabrice BELLINGARD.

 default remote repositories central, java.net are not available in remote 
 repositories list
 ---

 Key: MRM-394
 URL: http://jira.codehaus.org/browse/MRM-394
 Project: Archiva
  Issue Type: Bug
  Components: web application
Affects Versions: 1.0-alpha-1
Reporter: Brett Porter
Assignee: Fabrice BELLINGARD
 Fix For: 1.0-alpha-1


 - without having added any configuration, add a new proxy connector
 - note that remote repositories list is empty
 Not sure if this is deliberate - is it valid to have two connectors to the 
 same remote repository?
 Two potential solutions:
 a) if they are allowed, repositories should be in the list
 b) if duplicates are not allowed (not sure why this would be the case), then 
 the add form should present an error message saying there are no available 
 remote repositories

-- 
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: (MASSEMBLY-210) repository does not include the parent pom

2007-06-01 Thread Stephane Nicoll (JIRA)


[ 
http://jira.codehaus.org/browse/MASSEMBLY-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97941
 ] 

Stephane Nicoll commented on MASSEMBLY-210:
---

I have this with the current build of the plugin. (mvn 2.0.6)

{noformat}
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Internal error in the plugin manager executing goal 
'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-2-SNAPSHOT:attached': 
Unable to find the mojo 
'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-2-SNAPSHOT:attached' 
in the plugin 'org.apache.maven.plugins:maven-assembly-plugin'
Component descriptor cannot be found in the component repository: 
org.apache.maven.artifact.factory.ArtifactFactorydefault.
{noformat}

 repository does not include the parent pom
 --

 Key: MASSEMBLY-210
 URL: http://jira.codehaus.org/browse/MASSEMBLY-210
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Stephane Nicoll
Assignee: John Casey
 Fix For: 2.2-beta-2


 I am running the assembly on a project with a parent pom. ?xml version=1.0 
 encoding=ISO-8859-15? assembly iddist/id formats 
 formatzip/format /formats 
 includeBaseDirectorytrue/includeBaseDirectory 
 baseDirectoryfoo-${version}/baseDirectory fileSets fileSet 
 directory./directory outputDirectoryfoo-base/outputDirectory 
 useDefaultExcludestrue/useDefaultExcludes excludes 
 exclude*/target/*/exclude /excludes /fileSet /fileSets 
 repositories repository outputDirectoryrepository/outputDirectory 
 scopetest/scope /repository /repositories /assembly 
 The parent pom is not included at all.

-- 
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: (MCHANGELOG-52) Links are broken for viewcvs.cgi

2007-06-01 Thread Stefan Seidel (JIRA)

[
http://jira.codehaus.org/browse/MCHANGELOG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97938
]

Stefan Seidel commented on MCHANGELOG-52:
-

I request this to be reopened. When the fix of MCHANGELOG-56 now got the report
working for me, I get exactly this problem (missing src/main/java in the
viewcvs URL). I do not have an 'scmUrl' in the 'configuration' tag as the
plugin is supposed to pick up on scmurl.../url/scm from the pom.xml.

Are only changes in src/main/java considered? I would suggest this as a bug
then, too.

Don't know what the reporter meant with the 'c' after 'java', though.

Links are broken for viewcvs.cgi

Key: MCHANGELOG-52
URL: http://jira.codehaus.org/browse/MCHANGELOG-52
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-1
Environment: cvs on linux
Reporter: Jim Crossley
Assignee: Dennis Lundberg
Fix For: 2.0

My project.scm.url is 'http://cvs/viewcvs.cgi/myproject/'. If I make a
change to 'src/main/java/com/foo/Bar.java', the resulting link is
'http://cvs/viewcvs.cgi/myproject/om/foo/Bar.java'. Note the absence of
'src/main/java/c'. The lopped-off 'c' is especially distressing.
I can hack sort of a fix by adding this to the plugin element:
configuration
scmUrlhttp://cvs/viewcvs.cgi/sdvrpc-maven/src/main/java/c/scmUrl
/configuration
But that's gross, and it would only account for changes beneath
'src/main/java', so changes beneath ${basedir} would still be broken.

--
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: (MEV-45) Full list of poms that doesn't respect the m2 format

2007-06-01 Thread Emmanuel Venisse (JIRA)


[ 
http://jira.codehaus.org/browse/MEV-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97933
 ] 

Emmanuel Venisse commented on MEV-45:
-

http://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-repository-checker/

 Full list of poms that doesn't respect the m2 format
 

 Key: MEV-45
 URL: http://jira.codehaus.org/browse/MEV-45
 Project: Maven Evangelism
  Issue Type: Bug
  Components: Invalid POM
Reporter: Emmanuel Venisse

 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/plugins/maven-release-plugin/1.0/maven-release-plugin-1.0.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm/1.0-alpha-1-SNAPSHOT/maven-scm-1.0-alpha-1-20050407.201937-1.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm/1.0-alpha-1-SNAPSHOT/maven-scm-1.0-alpha-1-20050407.202000-2.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm/1.0-alpha-1-SNAPSHOT/maven-scm-1.0-alpha-1-20050407.203912-3.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm/1.0-alpha-2-SNAPSHOT/maven-scm-1.0-alpha-2-20050610.043511-1.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm/1.0-alpha-2-SNAPSHOT/maven-scm-1.0-alpha-2-20050627.163924-2.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm/1.0-alpha-2-SNAPSHOT/maven-scm-1.0-alpha-2-20050712.151302-3.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm/1.0-alpha-2-SNAPSHOT/maven-scm-1.0-alpha-2-20050720.122749-4.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm/1.0-alpha-2-SNAPSHOT/maven-scm-1.0-alpha-2-20050720.151728-5.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm-1.0-alpha-1-20050407.201937-1.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm-1.0-alpha-1-20050407.202000-2.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/scm/maven-scm-1.0-alpha-1-20050407.203912-3.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3-SNAPSHOT/wagon-1.0-alpha-3-20050407.202417-1.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3-SNAPSHOT/wagon-1.0-alpha-3-20050413.021234-4.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3-SNAPSHOT/wagon-1.0-alpha-3-20050419.043745-5.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3-SNAPSHOT/wagon-1.0-alpha-3-20050419.044035-6.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3-SNAPSHOT/wagon-1.0-alpha-3-20050421.162738-7.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3-SNAPSHOT/wagon-1.0-alpha-3-20050422.075233-8.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3-SNAPSHOT/wagon-1.0-alpha-3-20050429.051847-9.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon-1.0-alpha-2.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon-1.0-alpha-3-20050413.021234-4.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon-1.0-alpha-3-20050419.043745-5.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon-1.0-alpha-3-20050419.044035-6.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon-1.0-alpha-3-20050421.162738-7.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon-1.0-alpha-3-20050422.075233-8.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/apache/maven/wagon/wagon-1.0-alpha-3-20050429.051847-9.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/codehaus/xfire/xfire-parent/1.0-SNAPSHOT/xfire-parent-1.0-20050509.005115-1.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/codehaus/xfire/xfire-parent/1.0-SNAPSHOT/xfire-parent-1.0-20050707.131747-8.pom
 /home/projects/maven/repository-staging/to-ibiblio/maven2/org/codehaus/xfire/xfire-parent/1.0-SNAPSHOT/xfire-parent-1.0-20050511.200909-2.pom

[jira] Commented: (MRELEASE-237) can't release a pom without it's modules

2007-06-01 Thread Emmanuel Venisse (JIRA)


[ 
http://jira.codehaus.org/browse/MRELEASE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97927
 ] 

Emmanuel Venisse commented on MRELEASE-237:
---

Carlos,

What is the content of the tag? the whole tree, right?

 can't release a pom without it's modules
 

 Key: MRELEASE-237
 URL: http://jira.codehaus.org/browse/MRELEASE-237
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-5
Reporter: Brett Porter

 We have the common pattern of a parent POM which may have modules, but is 
 released independently from them (plugins, archetypes being a classic 
 example). This is currently not possible in the release plugin.

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

[jira] Updated: (MNG-2992) Batch file uses %HOME% - can set this to a value if blank

2007-06-01 Thread Tim Reilly (JIRA)


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

Tim Reilly updated MNG-2992:


Attachment: MNG-2992-maven-embedder.patch

Created new patch based on Developing Maven 2 : Creating and submitting a patch
Patch for trunk

 Batch file uses %HOME% - can set this to a value if blank
 -

 Key: MNG-2992
 URL: http://jira.codehaus.org/browse/MNG-2992
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Affects Versions: 2.0.6
 Environment: Windows_NT (WinXP)
Reporter: Tim Reilly
Priority: Minor
 Attachments: MNG-2992-maven-core.patch, 
 MNG-2992-maven-embedder.patch, mvn.bat.patch


 Batch file uses %HOME% let's set this to a nice value if blank. The patch 
 adds this line to set HOME to the value of 
 HOMEDRIVE + HOMEPATH

-- 
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: (MRM-394) default remote repositories central, java.net are not available in remote repositories list

2007-06-01 Thread Fabrice BELLINGARD (JIRA)


[ 
http://jira.codehaus.org/browse/MRM-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97948
 ] 

Fabrice BELLINGARD commented on MRM-394:


The problem comes from the fact that remote repositories are removed from the 
ArchivaConfiguration object: if you simply go to the repositories admin page, 
you'll see that the remote repositories are not displayed any more.

I found where the bug comes from and will fix that.

 default remote repositories central, java.net are not available in remote 
 repositories list
 ---

 Key: MRM-394
 URL: http://jira.codehaus.org/browse/MRM-394
 Project: Archiva
  Issue Type: Bug
  Components: web application
Affects Versions: 1.0-alpha-1
Reporter: Brett Porter
 Fix For: 1.0-alpha-1


 - without having added any configuration, add a new proxy connector
 - note that remote repositories list is empty
 Not sure if this is deliberate - is it valid to have two connectors to the 
 same remote repository?
 Two potential solutions:
 a) if they are allowed, repositories should be in the list
 b) if duplicates are not allowed (not sure why this would be the case), then 
 the add form should present an error message saying there are no available 
 remote repositories

-- 
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-2517) The binary distribution produced by assembly plugin contains .svn directory


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

Vincent Siveton closed MNG-2517.


  Assignee: Vincent Siveton
Resolution: Cannot Reproduce

Cannot reproduce today

 The binary distribution produced by assembly plugin contains .svn directory
 ---

 Key: MNG-2517
 URL: http://jira.codehaus.org/browse/MNG-2517
 Project: Maven 2
  Issue Type: Bug
  Components: Command Line
Affects Versions: 2.0-alpha-1
 Environment: trunk, assembly plugin 2.2-SNAPSHOT
Reporter: Vincent Siveton
Assignee: Vincent Siveton
 Attachments: MNG-2517.txt


 Result in zip file:
 maven-2.1-SNAPSHOT\conf
 \.svn\
 \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: (MCHANGELOG-52) Links are broken for viewcvs.cgi

[
http://jira.codehaus.org/browse/MCHANGELOG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97956
]

Dennis Lundberg commented on MCHANGELOG-52:
---

Stefan, we need more information from you to be able to reproduce your problem.
A complete pom along with a description of your directory structure would be
most helpful.

All changes in your SCM is considered.

Links are broken for viewcvs.cgi

[jira] Created: (CONTINUUM-1299) MD5 checksums of binaries are wrong.

2007-06-01 Thread Ramon Garcia Fernandez (JIRA)

MD5 checksums of binaries are wrong.


 Key: CONTINUUM-1299
 URL: http://jira.codehaus.org/browse/CONTINUUM-1299
 Project: Continuum
  Issue Type: Bug
  Components: Release
Reporter: Ramon Garcia Fernandez


The binaries
http://www.apache.org/dyn/closer.cgi/maven/binaries/continuum-1.0.3-bin.zip

and 
http://www.apache.org/dyn/closer.cgi/maven/binaries/continuum-1.0.3-bin.tar.gz

(at least) do not match the MD5 checksums published in that page.

This can create uncertainity about whether this server has been compromised.

-- 
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: (CONTINUUM-1299) MD5 checksums of binaries are wrong.

2007-06-01 Thread Ramon Garcia Fernandez (JIRA)


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

Ramon Garcia Fernandez closed CONTINUUM-1299.
-

Resolution: Cannot Reproduce

It was a mistake. wget of the URL causes one to download a HTML file with a 
mirror list, rather than the software.

 MD5 checksums of binaries are wrong.
 

 Key: CONTINUUM-1299
 URL: http://jira.codehaus.org/browse/CONTINUUM-1299
 Project: Continuum
  Issue Type: Bug
  Components: Release
Reporter: Ramon Garcia Fernandez

 The binaries
 http://www.apache.org/dyn/closer.cgi/maven/binaries/continuum-1.0.3-bin.zip
 and 
 http://www.apache.org/dyn/closer.cgi/maven/binaries/continuum-1.0.3-bin.tar.gz
 (at least) do not match the MD5 checksums published in that page.
 This can create uncertainity about whether this server has been compromised.

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

[jira] Updated: (DOXIA-100) The iText module should not be coupled to the apt and xdoc modules

2007-06-01 Thread Lukas Theussl (JIRA)


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

Lukas Theussl updated DOXIA-100:


Component/s: Module - Itext

 The iText module should not be coupled to the apt and xdoc modules
 --

 Key: DOXIA-100
 URL: http://jira.codehaus.org/browse/DOXIA-100
 Project: doxia
  Issue Type: Task
  Components: Module - Itext
Reporter: Jason van Zyl
 Fix For: 1.0


 We need a test source for rendering documents and not use the other modules' 
 parsers to generate events for anothe module's sink.

-- 
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-2831) Cannot add custom artifact handler and custom lifecycle as a build extension


[ 
http://jira.codehaus.org/browse/MNG-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97967
 ] 

Jason van Zyl commented on MNG-2831:


Then it's somethign that we'll need to fix for 2.0.7. I'm sure this is a result 
of changing how the extension manager worked. The fix version is 2.0.7.

 Cannot add custom artifact handler and custom lifecycle as a build extension
 

 Key: MNG-2831
 URL: http://jira.codehaus.org/browse/MNG-2831
 Project: Maven 2
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.5
Reporter: Vincent Massol
Assignee: Jason van Zyl
 Fix For: 2.0.7


 I have an extension registering a custom artifact handler and a custom 
 lifecycle against plexus. The project that uses that extension get the 
 following error:
 {noformat}
 [DEBUG] Error looking up lifecycle mapping to retrieve optional mojos. 
 Lifecycle ID: clean. Error: Component descriptor cannot be found in the 
 component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
 org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
 Component descriptor cannot be found in the component repository: 
 org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323)
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440)
 at 
 org.apache.maven.execution.MavenSession.lookup(MavenSession.java:123)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.findOptionalMojosForLifecycle(DefaultLifecycleExecutor.java:)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:999)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:980)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 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)
 [DEBUG] Skipping disabled repository codehaus.plugin.snapshots
 [DEBUG] Skipping disabled repository apache.snapshots
 [DEBUG] maven-clean-plugin: resolved to version 2.1 from repository central
 [DEBUG] Retrieving parent-POM: 
 org.apache.maven.plugins:maven-plugin-parent::2.0 for project: 
 null:maven-clean-plugin:maven-plugin:2.1 from the repository.
 [DEBUG] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.1:runtime 
 (selected for runtime)
 [DEBUG]   org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for 
 runtime)
 [DEBUG] Retrieving parent-POM: 
 org.apache.maven.shared:shared-components-parent::1 for project: 
 null:file-management:jar:1.0 from the repository.
 [DEBUG]   org.apache.maven.shared:file-management:jar:1.0:runtime (selected 
 for runtime)
 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for 
 runtime)
 [DEBUG] Configuring mojo 
 'org.apache.maven.plugins:maven-clean-plugin:2.1:clean' --
 [DEBUG]   (f) directory = 
 /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target
 [DEBUG]   (f) outputDirectory = 
 /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target/classes
 [DEBUG]   (f) testOutputDirectory =

[jira] Created: (ARCHETYPE-75) Submodules have a junit dependency

2007-06-01 Thread Jan Torben Heuer (JIRA)

Submodules have a junit dependency


 Key: ARCHETYPE-75
 URL: http://jira.codehaus.org/browse/ARCHETYPE-75
 Project: Maven Archetype
  Issue Type: Bug
  Components: Archetypes, Creator
Reporter: Jan Torben Heuer


When creating submodules, they should no have a dependency to junit. The 
dependecy is inherited anyway from the parent-module.

Jan

-- 
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: (MJAVADOC-123) Encoding Error When Getting project.name For JavaDoc -doctitle

[
http://jira.codehaus.org/browse/MJAVADOC-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97969
]

Vincent Siveton commented on MJAVADOC-123:
--

Any news? Could we close it?

Encoding Error When Getting project.name For JavaDoc -doctitle
--

Key: MJAVADOC-123
URL: http://jira.codehaus.org/browse/MJAVADOC-123
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Environment: Linux coco-laptop 2.6.20-15-generic #2 SMP Sun Apr 15
07:36:31 UTC 2007 i686 GNU/Linux
Maven version: 2.0.6
Reporter: Steven Coco
Assignee: Vincent Siveton
Fix For: 2.3

Attachments: javadoc-encoding-2.tar.gz, javadoc-encoding-3-4.tar.gz,
javadoc-encoding.tar.gz

I have found an encoding handling error in JavaDoc generation.
The POM for this project is in UTF-8 encoding. the project.name element
contains the trade mark character, U+2122.
When the JavaDoc plugin builds the documentation, the default HTML charset is
used: ISO-8859-1.
When viewing the JavaDoc pages, the trade mark character in the title has
been munged: â¢.
At some location, the project name's text is being copied and ported to the
JavaDoc tool in the wrong encoding.
The attachment has a test case. Since it's very small, the javadoc has
already been built there to prevent any unwanted encoding mismatches during
transmission of the attachment. View the POM to see the trade mark character
in the name. View target/site/apidocs/index.html to see the munged trade mark
character. View the src/main/java/overview.html file to see the other content
used for the API overview page.
N.B.: In the attachment, all files are in UTF-8 encoding.

[jira] Created: (ARCHETYPE-74) Add packaging parameter

2007-06-01 Thread Jan Torben Heuer (JIRA)

Add packaging parameter
---

 Key: ARCHETYPE-74
 URL: http://jira.codehaus.org/browse/ARCHETYPE-74
 Project: Maven Archetype
  Issue Type: Wish
  Components: Archetypes, Creator
Reporter: Jan Torben Heuer


Hi,

I'd like to be able to select a parameter like -Dpackaging=war/pom/... at the 
archetype:create command.

If you don't have time for that, I'd send you a patch. In that case, please 
tell me how you like to get it.

Jan

-- 
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-2934) Cannot Deploy Using Webdav due to DependencyManagement


[ 
http://jira.codehaus.org/browse/MNG-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97973
 ] 

Jason van Zyl commented on MNG-2934:


I needed the fuller explanation. It is the extension manager that is at fault 
here and the changes for MNG-1577 are affecting the resolution for extensions 
which is not right. Yup, this is definitely a problem.

 Cannot Deploy Using Webdav due to DependencyManagement
 --

 Key: MNG-2934
 URL: http://jira.codehaus.org/browse/MNG-2934
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies, Deployment
Affects Versions: 2.0.6
Reporter: Stephen Duncan Jr
 Fix For: 2.0.7

 Attachments: pom.xml


 The webdav wagon requires commons-httpclient-2.0.2.jar.  If I have a 
 dependencyManagement section that specifies commons-httpclient 3.0.1, then 
 deployment fails.
 The resulting output is:
 [EMAIL PROTECTED] webdavtest]$ mvn deploy
 [INFO] Scanning for projects...
 [INFO] artifact org.apache.maven.wagon:wagon-webdav: checking for updates 
 from ce-releases
 -
 this realm = app0.child-container[extensions]
 urls[0] = 
 file:/home/duncans/.m2/repository/de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar
 urls[1] = file:/home/duncans/.m2/repository/jdom/jdom/1.0/jdom-1.0.jar
 urls[2] = 
 file:/home/duncans/.m2/repository/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar
 urls[3] = 
 file:/home/duncans/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
 urls[4] = 
 file:/home/duncans/.m2/repository/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar
 urls[5] = 
 file:/home/duncans/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
 urls[6] = 
 file:/home/duncans/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
 urls[7] = 
 file:/home/duncans/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
 urls[8] = file:/home/duncans/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
 Number of imports: 0
 this realm = plexus.core
 urls[0] = file:/home/duncans/apps/maven/lib/maven-core-2.0.6-uber.jar
 Number of imports: 0
 -
 [INFO] 
 
 [INFO] Building Unnamed - test:webdavtest:pom:1.0-SNAPSHOT
 [INFO]task-segment: [deploy]
 [INFO] 
 
 [INFO] [site:attach-descriptor]
 [INFO] [install:install]
 [INFO] Installing /home/duncans/tmp/webdavtest/pom.xml to 
 /home/duncans/.m2/repository/test/webdavtest/1.0-SNAPSHOT/webdavtest-1.0-SNAPSHOT.pom
 [INFO] [deploy:deploy]
 altDeploymentRepository = null
 [INFO] Retrieving previous build number from snapshots
 [WARNING] repository metadata for: 'snapshot test:webdavtest:1.0-SNAPSHOT' 
 could not be retrieved from repository: snapshots due to an error: 
 Unsupported Protocol: 'dav': Cannot find wagon which supports the requested 
 protocol: dav
 [INFO] Repository 'snapshots' will be blacklisted
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find 
 wagon which supports the requested protocol: dav
 Component descriptor cannot be found in the component repository: 
 org.apache.maven.wagon.Wagondav.
 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 2 seconds
 [INFO] Finished at: Thu Apr 05 13:49:52 EDT 2007
 [INFO] Final Memory: 6M/10M
 [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: (MAVENUPLOAD-1574) Upload Hibernate Entity Manager 3.3.1.ga

2007-06-01 Thread Aleksei Valikov (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97971
 ] 

Aleksei Valikov commented on MAVENUPLOAD-1574:
--

Sorry for disturbing you again.
Approximately how long does it take for the package to appear on ibiblio FTP?
Thank you.

 Upload Hibernate Entity Manager 3.3.1.ga
 

 Key: MAVENUPLOAD-1574
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1574
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Aleksei Valikov
Assignee: Carlos Sanchez
 Attachments: hibernate-entitymanager-3.3.1.ga-bundle.jar, 
 hibernate-entitymanager-3.3.1.ga-bundle.jar


 Emmanuel Bernard of Hibernate has asked me to overtake Ibiblio uploading for 
 Hibernate Entity Manager.
 Please see http://opensource.atlassian.com/projects/hibernate/browse/EJB-287 
 for details (I'm the assignee of the issue).

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

[jira] Commented: (MCHANGELOG-52) Links are broken for viewcvs.cgi

[
http://jira.codehaus.org/browse/MCHANGELOG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97979
]

Jim Crossley commented on MCHANGELOG-52:

I agree this should be reopened, but not as originally described. I now get
the same problem Stefan describes, where src/main/java is missing from the URL
generated for each change. The good news is that the 'c' is back! ;-)

I did confirm that MCHANGELOG-56 is fixed, however.

Links are broken for viewcvs.cgi

[jira] Commented: (MCHANGELOG-52) Links are broken for viewcvs.cgi


[ 
http://jira.codehaus.org/browse/MCHANGELOG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97981
 ] 

Jim Crossley commented on MCHANGELOG-52:


I can't attach an entire project atm, but I did just confirm that the bug 
occurs in both multi and single module projects.  The single module project I 
tested isn't a whole lot different from what you could generate with the 
archetype plugin.  Here's my scm element, if that helps.

  scm
connectionscm:cvs:pserver:[EMAIL 
PROTECTED]:/usr/local/cvsroot:rtsp-java/connection
urlhttp://cvs/viewvc.cgi/rtsp-java//url
  /scm

My cvs version:  Concurrent Versions System (CVS) 1.12.13 (client/server)
Tested with Maven 2.0.6 and this version of the plugin:
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changelog-plugin/artifactId
version2.1-SNAPSHOT/version
  /plugin


 Links are broken for viewcvs.cgi
 

 Key: MCHANGELOG-52
 URL: http://jira.codehaus.org/browse/MCHANGELOG-52
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-1
 Environment: cvs on linux
Reporter: Jim Crossley
Assignee: Dennis Lundberg
 Fix For: 2.0


 My project.scm.url is 'http://cvs/viewcvs.cgi/myproject/'.  If I make a 
 change to 'src/main/java/com/foo/Bar.java', the resulting link is 
 'http://cvs/viewcvs.cgi/myproject/om/foo/Bar.java'.  Note the absence of 
 'src/main/java/c'.  The lopped-off 'c' is especially distressing.
 I can hack sort of a fix by adding this to the plugin element:
   configuration
 scmUrlhttp://cvs/viewcvs.cgi/sdvrpc-maven/src/main/java/c/scmUrl
   /configuration
 But that's gross, and it would only account for changes beneath 
 'src/main/java', so changes beneath ${basedir} would still be broken.

-- 
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-93) Tests can fail with OOME

2007-06-01 Thread Mark Hobson (JIRA)

Tests can fail with OOME


 Key: MDEP-93
 URL: http://jira.codehaus.org/browse/MDEP-93
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
Affects Versions: 2.0-alpha-5
 Environment: Windows XP, Cygwin
Reporter: Mark Hobson
Assignee: Brian Fox
 Attachments: patch.txt

Running the tests within Maven failed with an OOME.  The attached patch does 
some clearing up for the problematic test case and fixes the problem.

-- 
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: (MCHANGELOG-52) Links are broken for viewcvs.cgi


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

Jim Crossley reopened MCHANGELOG-52:



The URL generated for each changelog entry is missing the string, 
src/main/java, so the links are rendered broken.

 Links are broken for viewcvs.cgi
 

 Key: MCHANGELOG-52
 URL: http://jira.codehaus.org/browse/MCHANGELOG-52
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-1
 Environment: cvs on linux
Reporter: Jim Crossley
Assignee: Dennis Lundberg
 Fix For: 2.0


 My project.scm.url is 'http://cvs/viewcvs.cgi/myproject/'.  If I make a 
 change to 'src/main/java/com/foo/Bar.java', the resulting link is 
 'http://cvs/viewcvs.cgi/myproject/om/foo/Bar.java'.  Note the absence of 
 'src/main/java/c'.  The lopped-off 'c' is especially distressing.
 I can hack sort of a fix by adding this to the plugin element:
   configuration
 scmUrlhttp://cvs/viewcvs.cgi/sdvrpc-maven/src/main/java/c/scmUrl
   /configuration
 But that's gross, and it would only account for changes beneath 
 'src/main/java', so changes beneath ${basedir} would still be broken.

-- 
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: (MASSEMBLY-215) The maven-assembly-plugin doesn't support unpacking .rar extensions

2007-06-01 Thread James Abley (JIRA)

The maven-assembly-plugin doesn't support unpacking .rar extensions
---

 Key: MASSEMBLY-215
 URL: http://jira.codehaus.org/browse/MASSEMBLY-215
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2-beta-1
 Environment: Any
Reporter: James Abley
Priority: Minor


[INFO] Failed to create assembly: Error adding file-set for
'org.apache.jackrabbit:jackrabbit-jca:rar:1.3' to archive: Error
adding archived file-set. UnArchiver not found for: C:\
Users\jabley\.m2\repository\org\apache\jackrabbit\jackrabbit-jca\1.3\jackrabbit-jca-1.3.rar

No such archiver: 'rar'.

See also http://jira.codehaus.org/browse/PLXCOMP-67

Perhaps the type of unarchiver should be configurable?

-- 
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: (MCHANGELOG-52) Links are broken for viewcvs.cgi


[ 
http://jira.codehaus.org/browse/MCHANGELOG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97987
 ] 

Jim Crossley commented on MCHANGELOG-52:


Ok, I think I figured out what's going on and I have a workaround that fixes 
the links.  The problem is that the plugin's configuration parameter, basedir, 
defaults to ${project.build.sourceDirectory}.  IMHO, this is wrong.  It should 
default to the actual ${basedir} instead.  For me, the following configuration 
fixes this bug:

  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changelog-plugin/artifactId
version2.1-SNAPSHOT/version
configuration
  basedir${basedir}/basedir
/configuration
  /plugin

So the answer to Stefan's question above is yes, only changes to src/main/java 
are considered, by default, and because of that, the resulting links are 
rendered broken.

 Links are broken for viewcvs.cgi
 

 Key: MCHANGELOG-52
 URL: http://jira.codehaus.org/browse/MCHANGELOG-52
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-1
 Environment: cvs on linux
Reporter: Jim Crossley
Assignee: Dennis Lundberg
 Fix For: 2.0


 My project.scm.url is 'http://cvs/viewcvs.cgi/myproject/'.  If I make a 
 change to 'src/main/java/com/foo/Bar.java', the resulting link is 
 'http://cvs/viewcvs.cgi/myproject/om/foo/Bar.java'.  Note the absence of 
 'src/main/java/c'.  The lopped-off 'c' is especially distressing.
 I can hack sort of a fix by adding this to the plugin element:
   configuration
 scmUrlhttp://cvs/viewcvs.cgi/sdvrpc-maven/src/main/java/c/scmUrl
   /configuration
 But that's gross, and it would only account for changes beneath 
 'src/main/java', so changes beneath ${basedir} would still be broken.

-- 
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: (MCHANGELOG-52) Links are broken for viewcvs.cgi


[ 
http://jira.codehaus.org/browse/MCHANGELOG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97990
 ] 

Dennis Lundberg commented on MCHANGELOG-52:
---

Thanks for digging into this Jim.

Just one more question, do you explicitly set build/sourceDirectory in your 
pom.xml?

 Links are broken for viewcvs.cgi
 

 Key: MCHANGELOG-52
 URL: http://jira.codehaus.org/browse/MCHANGELOG-52
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-1
 Environment: cvs on linux
Reporter: Jim Crossley
Assignee: Dennis Lundberg
 Fix For: 2.0


 My project.scm.url is 'http://cvs/viewcvs.cgi/myproject/'.  If I make a 
 change to 'src/main/java/com/foo/Bar.java', the resulting link is 
 'http://cvs/viewcvs.cgi/myproject/om/foo/Bar.java'.  Note the absence of 
 'src/main/java/c'.  The lopped-off 'c' is especially distressing.
 I can hack sort of a fix by adding this to the plugin element:
   configuration
 scmUrlhttp://cvs/viewcvs.cgi/sdvrpc-maven/src/main/java/c/scmUrl
   /configuration
 But that's gross, and it would only account for changes beneath 
 'src/main/java', so changes beneath ${basedir} would still be broken.

-- 
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-94) Add dependency:tree goal

2007-06-01 Thread Mark Hobson (JIRA)

Add dependency:tree goal


 Key: MDEP-94
 URL: http://jira.codehaus.org/browse/MDEP-94
 Project: Maven 2.x Dependency Plugin
  Issue Type: New Feature
Affects Versions: 2.0-alpha-5
Reporter: Mark Hobson
Assignee: Brian Fox
 Attachments: patch.txt

The attached patch adds the help:dependencies goal from the maven-help-plugin 
to the maven-dependency-plugin as dependency:tree, as discussed on the dev 
mailing list.

-- 
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: (MPH-24) Move help:dependencies goal to maven-dependency-plugin

2007-06-01 Thread Mark Hobson (JIRA)

Move help:dependencies goal to maven-dependency-plugin
--

 Key: MPH-24
 URL: http://jira.codehaus.org/browse/MPH-24
 Project: Maven 2.x Help Plugin
  Issue Type: New Feature
Affects Versions: 2.0.2
Reporter: Mark Hobson
 Attachments: patch.txt

The attached patch removes the help:dependencies goal from the 
maven-help-plugin so it can be moved to the maven-dependency-plugin as 
dependency:tree, as discussed on the dev mailing list.

-- 
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: (MCHANGELOG-52) Links are broken for viewcvs.cgi


[ 
http://jira.codehaus.org/browse/MCHANGELOG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97996
 ] 

Jim Crossley commented on MCHANGELOG-52:


No, I don't set sourceDirectory in my pom.

 Links are broken for viewcvs.cgi
 

 Key: MCHANGELOG-52
 URL: http://jira.codehaus.org/browse/MCHANGELOG-52
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-1
 Environment: cvs on linux
Reporter: Jim Crossley
Assignee: Dennis Lundberg
 Fix For: 2.0


 My project.scm.url is 'http://cvs/viewcvs.cgi/myproject/'.  If I make a 
 change to 'src/main/java/com/foo/Bar.java', the resulting link is 
 'http://cvs/viewcvs.cgi/myproject/om/foo/Bar.java'.  Note the absence of 
 'src/main/java/c'.  The lopped-off 'c' is especially distressing.
 I can hack sort of a fix by adding this to the plugin element:
   configuration
 scmUrlhttp://cvs/viewcvs.cgi/sdvrpc-maven/src/main/java/c/scmUrl
   /configuration
 But that's gross, and it would only account for changes beneath 
 'src/main/java', so changes beneath ${basedir} would still be broken.

-- 
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-719) New Plugin - buildinfo (buildnumber and buildclass)


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

Joakim Erdfelt closed MNG-719.
--

  Assignee: Joakim Erdfelt
Resolution: Won't Fix

This is not commit'd on the apache side.

It can be found here : 
http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/maven-buildinfo-plugin/

 New Plugin - buildinfo (buildnumber and buildclass)
 ---

 Key: MNG-719
 URL: http://jira.codehaus.org/browse/MNG-719
 Project: Maven 2
  Issue Type: New Feature
Affects Versions: 2.0-beta-1
 Environment: n/a
Reporter: Joakim Erdfelt
Assignee: Joakim Erdfelt
Priority: Minor
 Attachments: maven-buildinfo-plugin.tar.gz


 After discussion in #maven, it seemed that this plugin could be of use by the 
 general population.
 It manages the buildnumber for a specific project, and even can produce an 
 (optional) buildclass.
 example setup.
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-buildinfo-plugin/artifactId
 version1.0-alpha-1-SNAPSHOT/version
 configuration
   infofile.buildinfo/infofile
   classnameorg.codehaus.modello.plugins.dom4j.BuildInfo/classname
 /configuration
 executions
   execution
 goals
   goalbuildnumber/goal
   goalbuildclass/goal
 /goals
   /execution
 /executions
   /plugin

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

[jira] Commented: (MANTRUN-37) Antrun breaks on multi-module builds

2007-06-01 Thread Deepak Gupta (JIRA)


[ 
http://jira.codehaus.org/browse/MANTRUN-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97999
 ] 

Deepak Gupta commented on MANTRUN-37:
-

I'm having the same issue as Lee Webb.

I can use version 1.0 of the plugin, to get rid of the exception Internal 
error in the plugin manager executing goal 
'org.apache.maven.plugins:maven-antrun-plugin:1.1:run ...', however when I try 
to use path refid=maven.test.classpath / the classpath does not include 
required classes.

Any idea when a fix will be available ?

thanks,


 Antrun breaks on multi-module builds
 

 Key: MANTRUN-37
 URL: http://jira.codehaus.org/browse/MANTRUN-37
 Project: Maven 2.x Antrun Plugin
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Maven 2.0.1
Reporter: Mike Perham
Priority: Critical

 I just updated to antrun v1.1 (which needs to be marked as released in jira 
 BTW) and find that my multimodule build is now breaking.  Running the build 
 in the child module itself works fine but if I build the parent, it fails 
 when it gets to the child with the antrun task.  Here's part of the debug 
 output.  Note it says 1.1 in the dependency tree but 1.0 further down.
 {noformat}
 [DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1 
 (selected for runtime)
 [DEBUG]   org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
 [DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
 [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for 
 runtime)
 [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
 [DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
 [DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9 
 (selected for runtime)
 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer 
 found: 1.0.5)
 [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
 [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9 
 (selected for runtime)
 [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer 
 found: 1.0.5)
 [DEBUG]   classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
 [DEBUG]   junit:junit:jar:3.8.1 (selected for runtime)
 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
 [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for 
 runtime)
 [DEBUG]   org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected 
 for runtime)
 [DEBUG]   org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5 
 (selected for runtime)
 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer 
 found: 1.0.5)
 [DEBUG]   org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
 [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
 [DEBUG]   org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
 [DEBUG]   ant:ant:jar:1.6.5 (selected for runtime)
 [DEBUG]   ant:ant-launcher:jar:1.6.5 (selected for runtime)
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Internal error in the plugin manager executing goal 
 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the 
 mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin 
 'org.apache.maven.plugins:maven-antrun-plugin'
 Component descriptor cannot be found in the component repository: 
 org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
 [INFO] 
 
 [DEBUG] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the 
 plugin manager executing goal 
 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the 
 mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin 
 'org.apache.maven.plugins:maven-antrun-plugin'
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
   at

[jira] Created: (MRM-410) Dependency Tree is not shown in artifact details screen.

Dependency Tree is not shown in artifact details screen.


 Key: MRM-410
 URL: http://jira.codehaus.org/browse/MRM-410
 Project: Archiva
  Issue Type: Bug
  Components: browser
Affects Versions: 1.0-alpha-1
Reporter: Joakim Erdfelt
 Fix For: 1.0-alpha-2


When browsing to an artifact, the artifact details screen is shown ok.
But when using the Dependency Tree tab, the information is always blank.

-- 
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: (MRM-410) Dependency Tree is not shown in artifact details screen.


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

Joakim Erdfelt updated MRM-410:
---

Fix Version/s: 1.0-alpha-2

 Dependency Tree is not shown in artifact details screen.
 

 Key: MRM-410
 URL: http://jira.codehaus.org/browse/MRM-410
 Project: Archiva
  Issue Type: Bug
  Components: browser
Affects Versions: 1.0-alpha-1
Reporter: Joakim Erdfelt
Assignee: Joakim Erdfelt
 Fix For: 1.0-alpha-2


 When browsing to an artifact, the artifact details screen is shown ok.
 But when using the Dependency Tree tab, the information is always blank.

-- 
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: (MRM-378) Clicking on the tabs in the artifact detail page doesn't change the view


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

Joakim Erdfelt closed MRM-378.
--

Resolution: Fixed

Closing as fixed.
Related work on DependencyTree has been postponed to 1.0-alpha-2 on MRM-410.

 Clicking on the tabs in the artifact detail page doesn't change the view
 

 Key: MRM-378
 URL: http://jira.codehaus.org/browse/MRM-378
 Project: Archiva
  Issue Type: Bug
  Components: browser
 Environment: Windows, Firefox
Reporter: Dawn Angelito
Assignee: Joakim Erdfelt
Priority: Critical
 Fix For: 1.0-alpha-1

 Attachments: patch.txt


 Steps:
 1) Search for an artifact.
 2) In the search results page, click on the artifact to view its details.
 3) Click the other tabs (Dependencies, Dependency Tree, etc.).
 Notice that the view doesn't change.

-- 
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: (MRM-406) Replace the archiva.version propertry with project.version


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

Joakim Erdfelt closed MRM-406.
--

Resolution: Fixed

Fixed in trunk.
Changed archiva.version to fully expanded version id.

 Replace the archiva.version propertry with project.version
 --

 Key: MRM-406
 URL: http://jira.codehaus.org/browse/MRM-406
 Project: Archiva
  Issue Type: Improvement
Affects Versions: 1.0-alpha-1
Reporter: Franz Allan Valencia See
Assignee: Joakim Erdfelt
 Fix For: 1.0-alpha-1

 Attachments: MRM-406-archiva-parent.patch


 There is no need for the archiva.version property in the pom because this can 
 be represented by the project.version property. Furthermore this can cause 
 problems when doing a release with continuum.

-- 
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: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts


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

John Casey updated MNG-2871:


Description: 
I have prepared simple project to show the bug.
It contains three artifacts: 
|-root
\--- ejb3
\--- client

Client depends on ejb3 with typeejb-client/type.

The local and remote repository must not contain those artifacts. 
When I do mvn -X compile (or even integration-tests) on root project I will
get those errors: 

...
[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' --
[DEBUG] (f) filters = []
[DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes
[DEBUG] (f) project = [EMAIL PROTECTED]
[DEBUG] (f) resources = [EMAIL PROTECTED]
[DEBUG] -- end configuration --
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null)
[DEBUG] junit:junit:jar:3.8.1:test (selected for test)
[DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for 
compile)
[DEBUG] Skipping disabled repository Newitech-repository
[DEBUG] Skipping disabled repository central
[DEBUG] ejb3: using locally installed snapshot
[DEBUG] Trying repository Newitech-snapshots-repository
Downloading: 
scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
[WARNING] Unable to get resource 
'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository 
Newitech-snapshots-repository 
(scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots)
[DEBUG] Skipping disabled repository Newitech-repository
[DEBUG] Trying repository Newitech-publiczne
Downloading: 
scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
[WARNING] Unable to get resource 
'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository 
Newitech-publiczne 
(scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/)
[DEBUG] Trying repository Maven Snapshots
Downloading: 
http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
[WARNING] Unable to get resource 
'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven 
Snapshots (http://people.apache.org/maven-snapshot-repository)
[DEBUG] Trying repository codehausSnapshots
Downloading: 
http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
[WARNING] Unable to get resource 
'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository 
codehausSnapshots (http://snapshots.maven.codehaus.org/maven2)
[DEBUG] Skipping disabled repository central
[DEBUG] Unable to download the artifact from any repository

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \
-Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file

Path to dependency:
1) pl.waw.tabor:client:jar:1.0-SNAPSHOT
2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT


pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT

from the specified remote repositories:
Maven Snapshots (http://people.apache.org/maven-snapshot-repository),
central (http://repo1.maven.org/maven2),
codehausSnapshots (http://snapshots.maven.codehaus.org/maven2),
Newitech-snapshots-repository 
(scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots),
Newitech-publiczne 
(scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/),
Newitech-repository 
(scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech)

[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \
-Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file

Path to dependency:
1) pl.waw.tabor:client:jar:1.0-SNAPSHOT
2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT

--
1 required artifact is missing.

for artifact:
pl.waw.tabor:client:jar:1.0-SNAPSHOT

from the specified remote repositories:
Maven Snapshots (http://people.apache.org/maven-snapshot-repository),
central (http://repo1.maven.org/maven2),
codehausSnapshots (http://snapshots.maven.codehaus.org/maven2),
Newitech-snapshots-repository 
(scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots),
Newitech-publiczne 
(scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/),
Newitech-repository

[jira] Created: (SUREFIRE-336) Allow single test path to use '.' delimiter

2007-06-01 Thread Paul Gier (JIRA)

Allow single test path to use '.' delimiter
---

 Key: SUREFIRE-336
 URL: http://jira.codehaus.org/browse/SUREFIRE-336
 Project: Maven Surefire
  Issue Type: Improvement
  Components: plugin
Affects Versions: 2.3
Reporter: Paul Gier
 Attachments: SurefirePlugin.patch

Currently when running a single test with the surefire plugin.  The path to the 
test has to be slash delimited
mvn -Dtest=org/test/MyTest

It would be convenient to be able to use the package name for the test like 
this:
mvn -Dtest=org.test.MyTest

The patch is a very simple change to replace the '.' with '/' in the plugin.

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

[jira] Closed: (MEV-449) lucene 1.9.1 JAR is hosed.


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

Henri Yandell closed MEV-449.
-

Resolution: Fixed

Jar files moved to the repository-removed directory. pom kept.

 lucene 1.9.1 JAR is hosed.
 --

 Key: MEV-449
 URL: http://jira.codehaus.org/browse/MEV-449
 Project: Maven Evangelism
  Issue Type: Task
  Components: Problem with Jar
Reporter: Brett Porter

 the JAR is only 2kb, including pom.xml and pom.properties, but no 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: (MEV-520) retroweaver 1.2.4 jar is corrupt


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

Henri Yandell closed MEV-520.
-

Resolution: Fixed

jar (and related files) moved to repository-removed.

 retroweaver 1.2.4 jar is corrupt
 

 Key: MEV-520
 URL: http://jira.codehaus.org/browse/MEV-520
 Project: Maven Evangelism
  Issue Type: Bug
  Components: Problem with Jar
Reporter: Brian Fox

 http://repo1.maven.org/maven2/net/sourceforge/retroweaver/retroweaver/1.2.4/
 This jar can't be opened with zip,winrar or my compiler.

-- 
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: (MJAVADOC-123) Encoding Error When Getting project.name For JavaDoc -doctitle

2007-06-01 Thread Steven Coco (JIRA)

[
http://jira.codehaus.org/browse/MJAVADOC-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98006
]

Steven Coco commented on MJAVADOC-123:
--

Sorry, I've been so busy.

Since I see the problem when I use ISO-8859-1 in both the POM and the javadoc,
I'd like to perform a test that does guarantee that there is no bug: I
currently still think there's a problem since characters in 8859-1 should port
around without being transcoded, but in one of the second examples the javadoc
contains the replacement character; so I want to be sure about it.

I'll really try to test this. If I lag in time much longer I'll post back a
comment.

Thanks.

Encoding Error When Getting project.name For JavaDoc -doctitle
--

Attachments: javadoc-encoding-2.tar.gz, javadoc-encoding-3-4.tar.gz,
javadoc-encoding.tar.gz

[jira] Commented: (MEV-36) Exo POM(s) missing dependency versions


[ 
http://jira.codehaus.org/browse/MEV-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98008
 ] 

Henri Yandell commented on MEV-36:
--

Doesn't look like they ever did a 1.0.1. I think we could fix the pom as it is 
broken, but we don't know the right jibx-bind versions. Shall we just delete 
this?

 Exo POM(s) missing dependency versions
 --

 Key: MEV-36
 URL: http://jira.codehaus.org/browse/MEV-36
 Project: Maven Evangelism
  Issue Type: Bug
  Components: Invalid POM
Reporter: Vincent Massol

 For example, exoplatform.container-1.0.pom is missing the version for the 
 jibx dependency.
 C:\dev\xwiki\trunkm2 install
 [INFO] 
 
 [INFO] Building XWiki
 [INFO] 
 
 [INFO] maven-surefire-plugin: using locally installed snapshot
 [INFO] maven-war-plugin: using locally installed snapshot
 [INFO] [resources:resources]
 Downloading: 
 http://repo1.maven.org/maven2/exo/exoplatform.container/1.0/exoplatform.container-1.0.pom
 2K downloaded
 ---
 constituent[0]: file:/c:/apps/maven2/lib/commons-cli-1.0-beta-2.jar
 constituent[1]: file:/c:/apps/maven2/lib/commons-validator-1.1.4.jar
 constituent[2]: file:/c:/apps/maven2/lib/doxia-core-1.0-alpha-3.jar
 constituent[3]: file:/c:/apps/maven2/lib/jline-0.9.1.jar
 constituent[4]: file:/c:/apps/maven2/lib/jsch-0.1.17.jar
 constituent[5]: 
 file:/c:/apps/maven2/lib/maven-artifact-2.0-beta-1-SNAPSHOT.jar
 constituent[6]: 
 file:/c:/apps/maven2/lib/maven-artifact-manager-2.0-beta-1-SNAPSHOT.jar
 constituent[7]: file:/c:/apps/maven2/lib/maven-core-2.0-beta-1-SNAPSHOT.jar
 constituent[8]: file:/c:/apps/maven2/lib/maven-model-2.0-beta-1-SNAPSHOT.jar
 constituent[9]: file:/c:/apps/maven2/lib/maven-monitor-2.0-beta-1-SNAPSHOT.jar
 constituent[10]: 
 file:/c:/apps/maven2/lib/maven-plugin-api-2.0-beta-1-SNAPSHOT.jar
 constituent[11]: 
 file:/c:/apps/maven2/lib/maven-plugin-descriptor-2.0-beta-1-SNAPSHOT.jar
 constituent[12]: 
 file:/c:/apps/maven2/lib/maven-plugin-registry-2.0-beta-1-SNAPSHOT.jar
 constituent[13]: 
 file:/c:/apps/maven2/lib/maven-profile-2.0-beta-1-SNAPSHOT.jar
 constituent[14]: 
 file:/c:/apps/maven2/lib/maven-project-2.0-beta-1-SNAPSHOT.jar
 constituent[15]: 
 file:/c:/apps/maven2/lib/maven-reporting-api-2.0-beta-1-SNAPSHOT.jar
 constituent[16]: 
 file:/c:/apps/maven2/lib/maven-settings-2.0-beta-1-SNAPSHOT.jar
 constituent[17]: file:/c:/apps/maven2/lib/oro-2.0.7.jar
 constituent[18]: file:/c:/apps/maven2/lib/plexus-input-handler-1.0-alpha-2.jar
 constituent[19]: file:/c:/apps/maven2/lib/wagon-file-1.0-alpha-4.jar
 constituent[20]: 
 file:/c:/apps/maven2/lib/wagon-http-lightweight-1.0-alpha-4.jar
 constituent[21]: file:/c:/apps/maven2/lib/wagon-provider-api-1.0-alpha-4.jar
 constituent[22]: file:/c:/apps/maven2/lib/wagon-ssh-1.0-alpha-4.jar
 ---
 org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
 {jibx:jibx-bind:null:jar}: The version cannot be empty.
 at 
 org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:108)

-- 
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: (MEV-36) Exo POM(s) missing dependency versions


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

Henri Yandell closed MEV-36.


Resolution: Incomplete

Marking as incomplete. People can workaround the problem with an exclude afaik; 
and hassle exo to make a 1.0.1 release.

 Exo POM(s) missing dependency versions
 --

 Key: MEV-36
 URL: http://jira.codehaus.org/browse/MEV-36
 Project: Maven Evangelism
  Issue Type: Bug
  Components: Invalid POM
Reporter: Vincent Massol

 For example, exoplatform.container-1.0.pom is missing the version for the 
 jibx dependency.
 C:\dev\xwiki\trunkm2 install
 [INFO] 
 
 [INFO] Building XWiki
 [INFO] 
 
 [INFO] maven-surefire-plugin: using locally installed snapshot
 [INFO] maven-war-plugin: using locally installed snapshot
 [INFO] [resources:resources]
 Downloading: 
 http://repo1.maven.org/maven2/exo/exoplatform.container/1.0/exoplatform.container-1.0.pom
 2K downloaded
 ---
 constituent[0]: file:/c:/apps/maven2/lib/commons-cli-1.0-beta-2.jar
 constituent[1]: file:/c:/apps/maven2/lib/commons-validator-1.1.4.jar
 constituent[2]: file:/c:/apps/maven2/lib/doxia-core-1.0-alpha-3.jar
 constituent[3]: file:/c:/apps/maven2/lib/jline-0.9.1.jar
 constituent[4]: file:/c:/apps/maven2/lib/jsch-0.1.17.jar
 constituent[5]: 
 file:/c:/apps/maven2/lib/maven-artifact-2.0-beta-1-SNAPSHOT.jar
 constituent[6]: 
 file:/c:/apps/maven2/lib/maven-artifact-manager-2.0-beta-1-SNAPSHOT.jar
 constituent[7]: file:/c:/apps/maven2/lib/maven-core-2.0-beta-1-SNAPSHOT.jar
 constituent[8]: file:/c:/apps/maven2/lib/maven-model-2.0-beta-1-SNAPSHOT.jar
 constituent[9]: file:/c:/apps/maven2/lib/maven-monitor-2.0-beta-1-SNAPSHOT.jar
 constituent[10]: 
 file:/c:/apps/maven2/lib/maven-plugin-api-2.0-beta-1-SNAPSHOT.jar
 constituent[11]: 
 file:/c:/apps/maven2/lib/maven-plugin-descriptor-2.0-beta-1-SNAPSHOT.jar
 constituent[12]: 
 file:/c:/apps/maven2/lib/maven-plugin-registry-2.0-beta-1-SNAPSHOT.jar
 constituent[13]: 
 file:/c:/apps/maven2/lib/maven-profile-2.0-beta-1-SNAPSHOT.jar
 constituent[14]: 
 file:/c:/apps/maven2/lib/maven-project-2.0-beta-1-SNAPSHOT.jar
 constituent[15]: 
 file:/c:/apps/maven2/lib/maven-reporting-api-2.0-beta-1-SNAPSHOT.jar
 constituent[16]: 
 file:/c:/apps/maven2/lib/maven-settings-2.0-beta-1-SNAPSHOT.jar
 constituent[17]: file:/c:/apps/maven2/lib/oro-2.0.7.jar
 constituent[18]: file:/c:/apps/maven2/lib/plexus-input-handler-1.0-alpha-2.jar
 constituent[19]: file:/c:/apps/maven2/lib/wagon-file-1.0-alpha-4.jar
 constituent[20]: 
 file:/c:/apps/maven2/lib/wagon-http-lightweight-1.0-alpha-4.jar
 constituent[21]: file:/c:/apps/maven2/lib/wagon-provider-api-1.0-alpha-4.jar
 constituent[22]: file:/c:/apps/maven2/lib/wagon-ssh-1.0-alpha-4.jar
 ---
 org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
 {jibx:jibx-bind:null:jar}: The version cannot be empty.
 at 
 org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:108)

-- 
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: (MEV-330) WebWork 2.2.1 POM should list FreeMarker as a dependency since it's required for plain ol' JSPs


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

Henri Yandell closed MEV-330.
-

Resolution: Won't Fix

Webwork 2.2.2 removed the optional on freemarker, so I don't think there's any 
need to work on this.

 WebWork 2.2.1 POM should list FreeMarker as a dependency since it's required 
 for plain ol' JSPs
 ---

 Key: MEV-330
 URL: http://jira.codehaus.org/browse/MEV-330
 Project: Maven Evangelism
  Issue Type: Bug
  Components: Invalid POM
Reporter: Matt Raible

 http://forums.opensymphony.com/message.jspa?messageID=34188#34188

-- 
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: (MCHANGELOG-52) Links are broken for viewcvs.cgi


[ 
http://jira.codehaus.org/browse/MCHANGELOG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98015
 ] 

Dennis Lundberg commented on MCHANGELOG-52:
---

I have deployed a new 2.1-SNAPSHOT. Please verify that it solves this issue.

 Links are broken for viewcvs.cgi
 

 Key: MCHANGELOG-52
 URL: http://jira.codehaus.org/browse/MCHANGELOG-52
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-1
 Environment: cvs on linux
Reporter: Jim Crossley
Assignee: Dennis Lundberg
 Fix For: 2.0


 My project.scm.url is 'http://cvs/viewcvs.cgi/myproject/'.  If I make a 
 change to 'src/main/java/com/foo/Bar.java', the resulting link is 
 'http://cvs/viewcvs.cgi/myproject/om/foo/Bar.java'.  Note the absence of 
 'src/main/java/c'.  The lopped-off 'c' is especially distressing.
 I can hack sort of a fix by adding this to the plugin element:
   configuration
 scmUrlhttp://cvs/viewcvs.cgi/sdvrpc-maven/src/main/java/c/scmUrl
   /configuration
 But that's gross, and it would only account for changes beneath 
 'src/main/java', so changes beneath ${basedir} would still be broken.

-- 
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: (MNG-2255) Use a external XML Pull parser instead of plexus one


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

Jason van Zyl updated MNG-2255:
---


From looking at the related issues I think the crux of the problem is using a 
Reader instead of an InputStream.

 Use a external XML Pull parser instead of plexus one
 

 Key: MNG-2255
 URL: http://jira.codehaus.org/browse/MNG-2255
 Project: Maven 2
  Issue Type: Improvement
  Components: POM
Affects Versions: 2.0.4
Reporter: Carlos Sanchez
Priority: Critical
 Fix For: 2.1.x


 To avoid maintaining the plexus XMLPullParser we should move to a standard 
 implementation like StaX
 As mentioned in DOXIA-60:
 There's a performance white paper
 http://java.sun.com/performance/reference/whitepapers/StAX-1_0.pdf
 The best implementation seems to be http://woodstox.codehaus.org/
 Another nice set of utilities at 
 http://wiki.java.net/bin/view/Javawsxml/StaxUtilsProject
 The indentator could be used instead of the PrettyPrintXMLWriter

-- 
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: (MJAR-29) Artifact name not correctly calculated for EAR

2007-06-01 Thread Corridor Software Developer (JIRA)


[ 
http://jira.codehaus.org/browse/MJAR-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98017
 ] 

Corridor Software Developer commented on MJAR-29:
-

I'm currently facing a case where the jar:sign is not signing an ejb-client jar 
file for me. I need this to occur so I many use it in a webstart app, but 
webstart don't support ejb-client files apparently. The workaround for me is to 
use the dependency plugin to move the ejb-client jar into place first; however, 
webstart doesn't sign it anyway so I need to sign it in advance.

working on a patch now.

 Artifact name not correctly calculated for EAR
 --

 Key: MJAR-29
 URL: http://jira.codehaus.org/browse/MJAR-29
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: maven 2.0.2
 maven-jar-plugin-2.1-SNAPSHOT
Reporter: Michael Böckling

 In a parent POM, I added jar:sign to the plugins section, thus adding it to 
 the default lifecycle. In a child, I try to build an EAR.
 Problem: 
 - It tries to sign a artifactId-version.jar instead of 
 artifactId-version.ear, thus resulting in an error.
 - Should jar:sign really trigger on an EAR artifact at all?
 Error message:
 [INFO] [jar:sign {execution: jar.sign}]
 [INFO] jarsigner: unable to open jar file: C:\Dokumente und 
 Einstellungen\mbo\wo
 rkspace\BAL-DruckComponentServer-Ear\target\druck-component-server-ear-0.9-SNAPS
 HOT.jar
 [INFO] 
 -
 ---
 [ERROR] BUILD ERROR
 [INFO] 
 -
 ---
 [INFO] Result of C:\Programme\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe 
 -keystor
 e C:\Dokumente und Einstellungen\mbo/.keystore -storepass Giniality 
 -keypass G
 iniality -signedjar C:\Dokumente und 
 Einstellungen\mbo\workspace\BAL-DruckCompo
 nentServer-Ear\target\signed\druck-component-server-ear-0.9-SNAPSHOT.jar 
 C:\Do
 kumente und 
 Einstellungen\mbo\workspace\BAL-DruckComponentServer-Ear\target\druc
 k-component-server-ear-0.9-SNAPSHOT.jar mykey execution is: '1'.

-- 
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-2646) [PATCH] MavenProjectBuilder.buildFromRepository(...) does not support profiles


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

Jason van Zyl closed MNG-2646.
--

Resolution: Won't Fix

Upon looking at this it's not something we want to do. Profiles affect your 
builds and change the behavior of what you are building. Influencing dependent 
POMs as they are being read with your profiles makes the outcome fairly random.

 [PATCH] MavenProjectBuilder.buildFromRepository(...) does not support profiles
 --

 Key: MNG-2646
 URL: http://jira.codehaus.org/browse/MNG-2646
 Project: Maven 2
  Issue Type: Bug
  Components: Profiles
Affects Versions: 2.0.4
Reporter: Christian Schulte
 Fix For: 2.1.x

 Attachments: profile.patch


 Currently profiles are not injected into models retrieved from a repository. 
 The attached patch was written against /tags/maven-2.0.4 and should apply 
 cleanly. It adds a ProfileManager parameter to the corresponding 
 MavenProjectBuilder.buildFromRepository(...) methods so that profiles are 
 also injected into models build from a repository.

-- 
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-2536) Resources are merged into derived POMs


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

Jason van Zyl closed MNG-2536.
--

Resolution: Fixed

Applied.

 Resources are merged into derived POMs
 --

 Key: MNG-2536
 URL: http://jira.codehaus.org/browse/MNG-2536
 Project: Maven 2
  Issue Type: Improvement
  Components: Documentation: Introductions
Reporter: Phil Steitz
 Attachments: resources_are_merged.patch


 I have found that build resources get merged into derived POMs.  The attached 
 patch adds resources to the list of POM elements that are merged.

-- 
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-728) Consider using java.net.useSystemProxies

2007-06-01 Thread Jochen Wiedmann (JIRA)

[
http://jira.codehaus.org/browse/MNG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98020
]

Jochen Wiedmann commented on MNG-728:
-

I disagree with Jason's decision to close this issue.

Let's have a look at Steve's points:

1.) This setting appears to do nothing on Linux. While this may be so, there
is no reason to assume that this won't change. Both Gnome (or maybe GTK, I do
not know the details) and KDE offer to configure a proxy. I'd surely hope that
the JRE will be able to pick up this settings at some point.

2.) It is not needed on mac. May be, but if it isn't: Who cares if the
property is set? The situation won't get worse?

3.) It does something on windows, but we do not know what. That's a poor
excuse for not using it. I may even go as far as accepting that it shouldn't be
switched on by default. But why won't you give me at least the change to try
whether it works or not and turn it on for me, if it does? My experiences with
the feature are quite converse to Steve's.

Regarding (3), build files that used to work fail with sql connections using
Oracle's JDBC driver hanging. Sounds questionable to me, but again, this is
at most an argument for not turning the feature on by defauilt.

While automatic synchronization between jvm proxy settings and the OS would be
a good thing, I am not convinced what is in 1.5.0x is a workable solution.
Instead it creates a different set of support calls. Who's talking about 1.5?
We already are at 1.6, 1.7 is approaching fast, and we're beginning to see
alternative JRE's (Harmony), where workable solutions (whatever they are) are
more than likely. Again, I am quite happy with using that feature.

Perhaps a better solution would be a commons-proxy-setup project that did
proxy configuration properly. And the first task of such a project, IMO, would
be to use useSystemSettings.

Consider using java.net.useSystemProxies

Key: MNG-728
URL: http://jira.codehaus.org/browse/MNG-728
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0-alpha-3
Reporter: Kohsuke Kawaguchi
Priority: Minor
Fix For: 2.1.x

Attachments: maven-proxy-1.patch, maven-proxy-2.patch,
maven-proxy-3.patch

Consider using the java.net.useSystemProxies property so that Maven can work
with a proxy without requring any user intervention.
See http://weblogs.java.net/blog/kohsuke/archive/2005/08/we_deserve_a_be.html
for more information.

[jira] Closed: (MNG-1954) Need better handling of malformed poms in local cache, like check for an update every run

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

Jason van Zyl closed MNG-1954.
--

Resolution: Won't Fix

I think the problem here is that we have POMs that are built with tools other
then Maven and the POM is not validated. We don't want to have to check
released POMs over and over again for changes the checking should be made
upfront and

Need better handling of malformed poms in local cache, like check for an
update every run
-

Key: MNG-1954
URL: http://jira.codehaus.org/browse/MNG-1954
Project: Maven 2
Issue Type: Improvement
Components: Artifacts and Repositories
Affects Versions: 2.0
Reporter: Steve Loughran
Fix For: 2.1.x

Attachments: MNG-1954.txt

If a pom has a typo in it, it is downloaded and parsed with a (misspelled)
error message printed
[m2:libraries] [WARNING] POM for
'org.hibernate:hibernate-tools:pom:3.1.0.beta2' is invalid. It will be
ignored for artifact resolution. Reason: Parse error reading POM. Reason:
expected to finsh end tag not from line 7 (position: TEXT seen
.../dependency\r\n /dependencies\r\n... @29:2)
but if the pom is corrected in the source repository, the local system doesnt
check for a change, it just goes with what is there.
Invalid pom files should be remembered and replacements looked for, because
there is no value in retaining them.

[jira] Closed: (MNG-1910) Allow jdk 1.4+ as profile requirement


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

John Casey closed MNG-1910.
---

Resolution: Fixed

Applied, thanks.

 Allow jdk 1.4+ as profile requirement
 -

 Key: MNG-1910
 URL: http://jira.codehaus.org/browse/MNG-1910
 Project: Maven 2
  Issue Type: Improvement
  Components: POM
Affects Versions: 2.0.1
Reporter: Jochen Wiedmann
 Fix For: 2.0.x

 Attachments: jdk_plus.patch, jdk_plus.patch


 The jdk element in the POM allows for strings like 1.5, or !1.4 only. 
 It would be desirable to use 1.4+, or something similar. The attached patch 
 serves that purpose.
 A patch for the docs is missing. I am ready to create such a patch as well, 
 if I know that my idea would be accepted.

-- 
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: (MNG-2010) Add new lifecycle phases for IT


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

John Casey updated MNG-2010:


Description: 
Namely:
* generate-integration-test-sources
* process-integration-test-sources
* generate-integration-test-resources
* process-integration-test-resources
* integration-test-compile

and possibly a:
* integration-test-package

  was:
Namely:
* generate-integration-test-sources
* process-integration-test-sources
* generate-integration-test-resources
* process-integration-test-resources
* integration-test-compile

and possibly a:
* integration-test-package


Patch Submitted:   (was: [Yes])

I'm really not happy with the approach of forever adding new phases to the 
lifecycle. This particular issue is an extreme example, but we really need to 
remember that each addition to the lifecycle is an addition to the build 
vocabulary of Maven. Are we ever really going to stop the build at the 
'generate-integration-test-resources' phase??? What about 
'integration-test-package'...how do you invoke that? The answer is that you've 
changed the build vocabulary such that if you want to really capture the 
integration tests as they were meant to be captured, you have to do:

mvn integration-test-package

Also, we have no provision in the lifecycle for post-processing for cleanup, 
which can be critical for integration tests. To me, this is just putting more 
tape on an already large ball of the same.

 Add new lifecycle phases for IT
 ---

 Key: MNG-2010
 URL: http://jira.codehaus.org/browse/MNG-2010
 Project: Maven 2
  Issue Type: Task
  Components: integration tests, Plugins and Lifecycle
Reporter: Vincent Massol
 Fix For: 2.0.x

 Attachments: MNG-2010-maven-lifecycle.patch, MNG-2010-site.patch


 Namely:
 * generate-integration-test-sources
 * process-integration-test-sources
 * generate-integration-test-resources
 * process-integration-test-resources
 * integration-test-compile
 and possibly a:
 * integration-test-package

-- 
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-1994) Execution order of child plugins is arbitrary if inheritance is involved

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

John Casey closed MNG-1994.
---

Resolution: Won't Fix

Execution order of child plugins is arbitrary if inheritance is involved

Key: MNG-1994
URL: http://jira.codehaus.org/browse/MNG-1994
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.1
Reporter: John Didion
Priority: Critical
Fix For: 2.1.x

Attachments: mergePluginLists.txt

This is related to MNG-1499, but different, and, in my opinion, equally
important. It makes sense that the order of plugin execution should be the
same as it appears in the POM. For example, I have two plugins: one that
generates a batch file and one that executes it. These plugins must run in
order or the build will fail. However, the current implementation of
ModelUtils.mergePluginLists does not respect the order of child plugins.
There is also a seperate bug in that the assembledPlugins map is being
checked for the presence of child plugins before adding them to the
mergedPlugins list, but nothing is ever added to assembledPlugins. So if a
plugin exists in a parent and a child, it will end up appearing twice in the
child's plugin list.
I have re-written this method to fix both these problems. See attached.

[jira] Created: (MAVENUPLOAD-1579) Upload Struts Menu 2.4.3

2007-06-01 Thread Matt Raible (JIRA)

Upload Struts Menu 2.4.3


 Key: MAVENUPLOAD-1579
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1579
 Project: maven-upload-requests
  Issue Type: Wish
Reporter: Matt Raible




-- 
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: (MCHANGELOG-60) Make the date and time formats configurable for the ChangeSet headings in the report


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

Dennis Lundberg closed MCHANGELOG-60.
-

 Assignee: Dennis Lundberg
   Resolution: Fixed
Fix Version/s: 2.1

Fixed in r543584.

 Make the date and time formats configurable for the ChangeSet headings in the 
 report
 

 Key: MCHANGELOG-60
 URL: http://jira.codehaus.org/browse/MCHANGELOG-60
 Project: Maven 2.x Changelog Plugin
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Dennis Lundberg
Assignee: Dennis Lundberg
Priority: Minor
 Fix For: 2.1




-- 
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: (MEV-457) Geronimo jar fails to download


[ 
http://jira.codehaus.org/browse/MEV-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98033
 ] 

Henri Yandell commented on MEV-457:
---

Issue being that 
http://repo1.maven.org/maven2/geronimo/geronimo-javamail-transport/1.1.1/ is 
empty.

 Geronimo jar fails to download
 --

 Key: MEV-457
 URL: http://jira.codehaus.org/browse/MEV-457
 Project: Maven Evangelism
  Issue Type: Bug
Reporter: Henri Yandell

 If you look at http://www.ibiblio.org/maven/geronimo/jars/, you can see that 
 there is a geronimo-javamail-transport-1.1.1.jar file. If you try to click on 
 that/download it you get a reply of 'Not found'.
 (http://www.ibiblio.org/maven/geronimo/jars/geronimo-javamail-transport-1.1.1.jar)
 mod_rewrite or permissions problem?

-- 
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: (MCHANGELOG-61) Timestamp time is always 00:00:00 resulting to badly sorted list


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

Dennis Lundberg closed MCHANGELOG-61.
-

 Assignee: Dennis Lundberg
   Resolution: Fixed
Fix Version/s: 2.1

Fixed in r543594.

 Timestamp time is always 00:00:00 resulting to badly sorted list
 

 Key: MCHANGELOG-61
 URL: http://jira.codehaus.org/browse/MCHANGELOG-61
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
 Environment: Maven 2.0.5
Reporter: Sebastien Brunot
Assignee: Dennis Lundberg
 Fix For: 2.1


 The change log report is reporting a time of 00:00:00 for each entry in the 
 Timestamp column. The date is correct, but while the time is not, the 
 entries are not ordered as expected.

-- 
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-2987) Fix tests for running in path with spaces


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

Jason van Zyl closed MNG-2987.
--

Resolution: Fixed

Patch applied.

 Fix tests for running in path with spaces
 -

 Key: MNG-2987
 URL: http://jira.codehaus.org/browse/MNG-2987
 Project: Maven 2
  Issue Type: Bug
  Components: integration tests
Affects Versions: 2.0.6
 Environment: Windows XP, Cygwin
Reporter: Mark Hobson
Assignee: Jason van Zyl
 Attachments: patch.txt


 it0048 and it0119 fail when run within a path that contains spaces.  Attached 
 patch fixes these.

-- 
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-2784) Multiple executions of the same plugin at the same life cycle phase in a multi-module profile mixed up


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

John Casey closed MNG-2784.
---

Resolution: Fixed

 Multiple executions of the same plugin at the same life cycle phase in a 
 multi-module profile mixed up
 --

 Key: MNG-2784
 URL: http://jira.codehaus.org/browse/MNG-2784
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build, Plugins and Lifecycle, Profiles, 
 Reactor and workspace
Affects Versions: 2.0.4, 2.0.5
Reporter: Maik Ebert
Assignee: Jason van Zyl
Priority: Critical
 Fix For: 2.0.7

 Attachments: MNG-2784.patch


 I use the latest Maven 2.0.5 build found at 
 http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/
 I have multiple executions of the same plugin at the same life cycle phase in 
 a multi-module parent POM. There was a bug regarding the order of this 
 executions. This was fixed at 2.0.5.
 Now I needed to extract these plugin executions to a profile in this parent 
 POM. Now the executions are not ordered correctly anymore :-(
 Before (works fine):
 parent\pom.xml = multiple executions of the same plugin at the same life 
 cycle phase in the default build element
 parent \child1\pom.xml
 parent \child2\pom.xml
 Calling mvn install in parent works fine.
 After (fails):
 parent\pom.xml = multiple executions of the same plugin at the same life 
 cycle phase in the build element of a profile
 parent \child1\pom.xml
 parent \child2\pom.xml
 Calling mvn install in parent mixed up the execution order in the childs.

-- 
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-2206) bad properties interpolation with profiles


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

Jason van Zyl closed MNG-2206.
--

  Assignee: (was: Edwin Punzalan)
Resolution: Duplicate

Duplicate it appears of not being able to have the command line values set 
override anything else. 

 bad properties interpolation with profiles 
 ---

 Key: MNG-2206
 URL: http://jira.codehaus.org/browse/MNG-2206
 Project: Maven 2
  Issue Type: Bug
  Components: Inheritance and Interpolation
Affects Versions: 2.0.3
 Environment: cygwin
Reporter: Olivier Lamy
Priority: Blocker
 Fix For: 2.0.x

 Attachments: MNG-2206-maven-project.patch, pom.xml

   Original Estimate: 2 hours
  Remaining Estimate: 2 hours

 create two profiles in your settings.xml
 - id  test with a property testdev/test 
 - id snapshots with a property testsnapshots/test 
 activeProfiles
 activeProfiledev/activeProfile
 activeProfilesnapshots/activeProfile
 /activeProfiles
 With the attached pom run :
 mvn validate :
 [echo] dev 
 mvn -P snapshots validate :
 [echo] dev
 Olivier

-- 
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: (MCHANGELOG-63) Tag-based reports have new headers, SCM-comments with newlines get linebreaks in HTML, lay-out update on changelog-report

[
http://jira.codehaus.org/browse/MCHANGELOG-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98043
]

Dennis Lundberg commented on MCHANGELOG-63:
---

1. This part of the patch will not work, since the methods getEndTag() and
getStartTag() are not available in Maven-SCM, even after SCM-294 was applied.
2. This has been fixed by MCHANGELOG-59.
3. When I apply this part things look really strange for a subversion
changelog, where you can have several files changed in one commit. They end up
one after the other without formatting.

The code for creating the heading has been refactored into just one method in
ChangeLogReport, if you want to have another go at creating a patch.

Tag-based reports have new headers, SCM-comments with newlines get linebreaks
in HTML, lay-out update on changelog-report
-

Key: MCHANGELOG-63
URL: http://jira.codehaus.org/browse/MCHANGELOG-63
Project: Maven 2.x Changelog Plugin
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Roland Asmann
Priority: Minor
Attachments: maven-changelog-plugin-2.0-CFC-20070330.patch

Several updates that made the lay-out of the sites change:
- Reports based on tags don't show the message for ranges, but have own
headers and messages now. This change needs the updates I made to SCM
(http://jira.codehaus.org/browse/SCM-294)!
- Newlines in SCM-comments are printed with line-breaks now.
- Removed the paragraph-tags around every single file-entry (didn't like the
way it looked).

[jira] Closed: (MNG-2683) [PATCH] ProjectBuildingException should print more information


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

Jason van Zyl closed MNG-2683.
--

Resolution: Fixed

Patch applied.

 [PATCH] ProjectBuildingException should print more information
 --

 Key: MNG-2683
 URL: http://jira.codehaus.org/browse/MNG-2683
 Project: Maven 2
  Issue Type: Improvement
Reporter: Mark Lundquist
Priority: Minor
 Attachments: patch.diff


 I added some more detail to these exception messages to help me track down a 
 problem with a build.

-- 
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-2978) Assembly plugin does not resolve version ranges correctly


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

Jason van Zyl closed MNG-2978.
--

Resolution: Duplicate

 Assembly plugin does not resolve version ranges correctly
 -

 Key: MNG-2978
 URL: http://jira.codehaus.org/browse/MNG-2978
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.6
 Environment: XP Pro SP2
Reporter: David Hoffer
 Attachments: VersionRangeSnapshotFix.patch


 Similar to MRELEASE-134 in maven-release-plugin
 dependency
 groupIdmyGroup/groupId
 artifactIdmyArtifact/artifactId
 version[1.0,)/version
 /dependency
 This version range can resolve to the latest development SNAPSHOT. All 
 artifact dependencies should ignore SNAPSHOTS as that is not intended by the 
 unbounded high end of the version range.  This should resolve to any released 
 version of 1.1 or higher.
 This document:
 http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
 addressed the requirements for version ranges and stated that Resolution of 
 dependency ranges should not resolve to a snapshot (development version) 
 unless it is included as an explicit boundary. I think this requirement was 
 forgotten when version ranges were implemented.

-- 
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-2444) Add deprecation information to mojo parameters


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

John Casey closed MNG-2444.
---

Resolution: Fixed

 Add deprecation information to mojo parameters
 --

 Key: MNG-2444
 URL: http://jira.codehaus.org/browse/MNG-2444
 Project: Maven 2
  Issue Type: New Feature
  Components: Documentation:  General
Reporter: Edwin Punzalan
Assignee: John Casey
Priority: Minor
 Attachments: eclipse-mojo.html, MNG-2444-maven-plugin-tools-api.patch




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

[jira] Updated: (MNG-2444) Add deprecation information to mojo parameters


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

John Casey updated MNG-2444:


   Assignee: John Casey  (was: Edwin Punzalan)
Patch Submitted:   (was: [Yes])

 Add deprecation information to mojo parameters
 --

 Key: MNG-2444
 URL: http://jira.codehaus.org/browse/MNG-2444
 Project: Maven 2
  Issue Type: New Feature
  Components: Documentation:  General
Reporter: Edwin Punzalan
Assignee: John Casey
Priority: Minor
 Attachments: eclipse-mojo.html, MNG-2444-maven-plugin-tools-api.patch




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

[jira] Closed: (MNG-2499) Attach sources to maven-plugin-testing-harness


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

Jason van Zyl closed MNG-2499.
--

Resolution: Fixed

Applied.

 Attach sources to maven-plugin-testing-harness
 --

 Key: MNG-2499
 URL: http://jira.codehaus.org/browse/MNG-2499
 Project: Maven 2
  Issue Type: Improvement
  Components: Plugin Creation Tools
Reporter: Jochen Wiedmann
 Attachments: maven-plugin-testing-harness-source.patch


 Sorry, if this should be the wrong project or component, but I was unable to 
 find any better.
 Please attach sources to the maven-plugin-testing-harness. It helps a lot 
 when understanding the plugins error messages. Patch is attached.

-- 
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-2100) v3 pom properties is already supported in v4 poms and should be converted accordingly


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

Jason van Zyl closed MNG-2100.
--

  Assignee: (was: Edwin Punzalan)
Resolution: Fixed

Stale, and you're a committer. Apply it yourself if it's still valid in shared.

 v3 pom properties is already supported in v4 poms and should be converted 
 accordingly
 -

 Key: MNG-2100
 URL: http://jira.codehaus.org/browse/MNG-2100
 Project: Maven 2
  Issue Type: Bug
Reporter: Edwin Punzalan
 Fix For: 2.2.x

 Attachments: MNG-2100-maven-model-converter.patch




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

[jira] Commented: (MNG-2010) Add new lifecycle phases for IT

2007-06-01 Thread Nelz (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98047
 ] 

Nelz commented on MNG-2010:
---

To Jason:
If we take the simple example of a self-contained web application with just a 
single WAR artifact, I think that requiring a multi-module build is kind of 
overkill.  (In an enterprise scenario, I can see separating out the tests, 
especially if there is a client generated from the single WAR artifact, as is 
the case with Web Services...)

Hypothetically, let's look at a multi-module with the first module building the 
WAR file, and a second module to test the WAR file.  What stops a developer 
from going down to the first module and just building/deploying that artifact?  
Now, the artifact is uploaded to whatever internal repository without being 
tested.

One of the things I really cherish about the Maven lifecycle is how it enforces 
that tests must pass *before* the artifact makes out of the local box...

To John: 
I do think these phases are important, for all the same reasons they are 
important before the (unit) tests.  And, much like what I said above, I think 
it is *very* important to test before it gets out of the current developer's 
workspace.  You are right, we probably won't have many people typing mvn 
process-integration-test-resources (other than the build developers who want 
to test up to that point...), but we sure will have people typing mvn 
install.  And in my opinion, having the integration tests do their thing 
before that 'install' point is *muy importante*...

Also, there *is* already provision for doing post-processing for cleanup, it's 
the post-integration-test...  And if you are talking about using the (unit) 
test functionality for doing the post-processing stuff in a multi-module build, 
that is why I added the post-test phase in my submitted patch...

To No One In Particular:
I believe the two parallel cycles of 'test' and 'integration-test' are 
important for robust artifacts.  The (unit) tests serve to test as a white-box, 
co-locate type of environment, and the integration tests serve to test the 
artifact like a black-box, separate client.


 Add new lifecycle phases for IT
 ---

 Key: MNG-2010
 URL: http://jira.codehaus.org/browse/MNG-2010
 Project: Maven 2
  Issue Type: Task
  Components: integration tests, Plugins and Lifecycle
Reporter: Vincent Massol
 Fix For: 2.0.x

 Attachments: MNG-2010-maven-lifecycle.patch, MNG-2010-site.patch


 Namely:
 * generate-integration-test-sources
 * process-integration-test-sources
 * generate-integration-test-resources
 * process-integration-test-resources
 * integration-test-compile
 and possibly a:
 * integration-test-package

-- 
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-2960) Some maven-project tests fail under maven-surefire-plugin 2.3


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

Jason van Zyl closed MNG-2960.
--

Resolution: Fixed

Applied.

 Some maven-project tests fail under maven-surefire-plugin 2.3
 -

 Key: MNG-2960
 URL: http://jira.codehaus.org/browse/MNG-2960
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build
Affects Versions: 2.0.7
 Environment: Windows XP, Cygwin, Java 1.5.0_11
Reporter: Mark Hobson
 Attachments: patch.txt


 When maven-project tests are run on Windows, within a path with spaces, using 
 maven-surefire-plugin 2.3, some tests fail with test resource path encoding 
 problems.
 This appears to be due to maven-surefire-plugin 2.3 using a different context 
 classloader to 2.2.  IIRC the system classloader has different behaviour to 
 URLClassLoader with regard to escaping spaces, so the attached patch uses the 
 correct URL to File conversion.

-- 
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-2658) [maven-plugin-testing-harness-1.0-beta-2] : expressions are not correctly evaluated


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

Jason van Zyl closed MNG-2658.
--

Resolution: Won't Fix

For testing we don't want system properties and profiles.

 [maven-plugin-testing-harness-1.0-beta-2] : expressions are not correctly 
 evaluated
 ---

 Key: MNG-2658
 URL: http://jira.codehaus.org/browse/MNG-2658
 Project: Maven 2
  Issue Type: Bug
  Components: Plugin Creation Tools
Affects Versions: 2.0.4
Reporter: Emmanuel Hugonnet
 Attachments: expressionEvaluator.patch


 When evaluating an expression, the evaluator doesn't use System.properties, 
 ou profiles.
 I have attached a patch so at least System.properties are checked and null is 
 returned if none is found.

-- 
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-1832) built-in property containing current timestamp


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

Jason van Zyl closed MNG-1832.
--

Resolution: Fixed

There are now several plugins to add information to properties. The buildinfo 
plugin at Mojo for example.

 built-in property containing current timestamp
 --

 Key: MNG-1832
 URL: http://jira.codehaus.org/browse/MNG-1832
 Project: Maven 2
  Issue Type: New Feature
Affects Versions: 2.0.1
Reporter: Michal Stochmialek
 Fix For: 2.1.x

 Attachments: maven-archiver_pomDelete.patch, 
 maven-core_defaultExpressions.patch


 Current timestamp (time or date) is often used while filtering resources or 
 creating manifest in ant builds. There is no equivalent in maven.

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

[jira] Closed: (DOXIA-98) If no urls found in pom hierarchy site failed with NPE

2007-06-01 Thread Olivier Lamy (JIRA)


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

Olivier Lamy closed DOXIA-98.
-

Resolution: Fixed

Cannot reproduce with last snapshot.

 If no urls found in pom hierarchy site failed with NPE
 --

 Key: DOXIA-98
 URL: http://jira.codehaus.org/browse/DOXIA-98
 Project: doxia
  Issue Type: Bug
  Components: Decoration Model
 Environment: all
Reporter: Olivier Lamy
 Attachments: DOXIA-98


 Hi,
 Trying to add some skinning in plexus-components.
 As there is no url defined in any poms hierarchy the site failed.
 A simple workaround is to add an url in a pom.
 --
 Olivier

-- 
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: (MNG-2503) mvn.bat file is not correct for 4NT 5.0 and does endlocal twice if error

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

John Casey updated MNG-2503:

Assignee: John Casey
Description:
1. If not setup properly and error occurs, the script attempts to endlocal
twice:

[d:\] mvn --version
Exception in thread main java.lang.NoClassDefFoundError:
org/codehaus/classworlds/Launcher
4NT: D:\dev\maven2\bin\mvn.bat [145] Missing SETLOCAL

2. Syntax wrong for adding CLASSWORLDS_JAR when under 4NT.

For #1, I updated the :error section of the mvn.bat file.
For #2, I added a new section to add the CLASSWORLDS_JAR

was:
1. If not setup properly and error occurs, the script attempts to endlocal
twice:

[d:\] mvn --version
Exception in thread main java.lang.NoClassDefFoundError:
org/codehaus/classworlds/Launcher
4NT: D:\dev\maven2\bin\mvn.bat [145] Missing SETLOCAL

2. Syntax wrong for adding CLASSWORLDS_JAR when under 4NT.

For #1, I updated the :error section of the mvn.bat file.
For #2, I added a new section to add the CLASSWORLDS_JAR

Patch Submitted: (was: [Yes])

Applied a patch generated from the attached mvn.bat file, with some minor
modifications. This has been applied against trunk...can someone verify that it
works? I will merge it to the branch, but I don't have windows...

mvn.bat file is not correct for 4NT 5.0 and does endlocal twice if error
--

Key: MNG-2503
URL: http://jira.codehaus.org/browse/MNG-2503
Project: Maven 2
Issue Type: Bug
Components: Command Line
Affects Versions: 2.0.4
Environment: Windows XP SP2 and 4NT 5.00U
Reporter: Mark DeLaFranier
Assignee: John Casey
Priority: Minor
Attachments: mvn.bat

1. If not setup properly and error occurs, the script attempts to endlocal
twice:
[d:\] mvn --version
Exception in thread main java.lang.NoClassDefFoundError:
org/codehaus/classworlds/Launcher
4NT: D:\dev\maven2\bin\mvn.bat [145] Missing SETLOCAL
2. Syntax wrong for adding CLASSWORLDS_JAR when under 4NT.
For #1, I updated the :error section of the mvn.bat file.
For #2, I added a new section to add the CLASSWORLDS_JAR

[jira] Closed: (MNG-2503) mvn.bat file is not correct for 4NT 5.0 and does endlocal twice if error


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

John Casey closed MNG-2503.
---

Resolution: Fixed

 mvn.bat file is not correct for 4NT 5.0 and does endlocal twice if error
 --

 Key: MNG-2503
 URL: http://jira.codehaus.org/browse/MNG-2503
 Project: Maven 2
  Issue Type: Bug
  Components: Command Line
Affects Versions: 2.0.4
 Environment: Windows XP SP2 and 4NT 5.00U
Reporter: Mark DeLaFranier
Assignee: John Casey
Priority: Minor
 Attachments: mvn.bat


 1. If not setup properly and error occurs, the script attempts to endlocal 
 twice:
 [d:\]  mvn --version
 Exception in thread main java.lang.NoClassDefFoundError: 
 org/codehaus/classworlds/Launcher
 4NT: D:\dev\maven2\bin\mvn.bat [145] Missing SETLOCAL
 2. Syntax wrong for adding CLASSWORLDS_JAR when under 4NT. 
 For #1, I updated the :error section of the mvn.bat file. 
 For #2, I added a new section to add the CLASSWORLDS_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] Commented: (MNG-2906) version ranges don't work after a day has passed

2007-06-01 Thread Damon Jacobsen (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98055
 ] 

Damon Jacobsen commented on MNG-2906:
-

It appears I was getting this message due to my Maven proxy server being down. 
This is a realy bad message for what is going on however.

 version ranges don't work after a day has passed
 

 Key: MNG-2906
 URL: http://jira.codehaus.org/browse/MNG-2906
 Project: Maven 2
  Issue Type: Bug
Reporter: Bill Dudney

 dependency A has a range dependency on B
 my project has a dependency on A (not directly on B)
 I build my project with a fresh clean repo (i.e. rm -rf ~/.m2/repository)
 B's latest is downloaded as expected
 the next morning I rebuild my project and I get error messages that no 
 suitable version can be found;
 No versions are present in the repository for the artifact with a range 
 [1.02b,) com.lowagie:itext-null.jar
 the particulars are jfreereports depending on [1.02b,) of lowagie.

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

[jira] Updated: (DOXIA-98) If no urls found in pom hierarchy site failed with NPE


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

Dennis Lundberg updated DOXIA-98:
-

Fix Version/s: 1.0-alpha-9

 If no urls found in pom hierarchy site failed with NPE
 --

 Key: DOXIA-98
 URL: http://jira.codehaus.org/browse/DOXIA-98
 Project: doxia
  Issue Type: Bug
  Components: Decoration Model
 Environment: all
Reporter: Olivier Lamy
 Fix For: 1.0-alpha-9

 Attachments: DOXIA-98


 Hi,
 Trying to add some skinning in plexus-components.
 As there is no url defined in any poms hierarchy the site failed.
 A simple workaround is to add an url in a pom.
 --
 Olivier

-- 
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-1019) downloads not rejected when a proxy returns 302; repository gets corrupted


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

Jason van Zyl closed MNG-1019.
--

Resolution: Won't Fix

Stale

 downloads not rejected when a proxy returns 302; repository gets corrupted
 --

 Key: MNG-1019
 URL: http://jira.codehaus.org/browse/MNG-1019
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0-beta-1
 Environment: WinxP laptop, running on a WLAN that has one of those 
 restricted-access-login pages; all HTTP requests are turned into a 302 
 responses redirecting to the login page.
Reporter: Steve Loughran
 Fix For: 2.0.x

 Attachments: MNG-1019-wagon-http-lightweight.patch


 I was trying to do a build in a meeting, but site IT have just changed their 
 security policy for guests; instead of a transparent proxy, we have a 
 transparent proxy that 302s all requests from an unknown client to their 
 login page.
 Here is a bit of the log:
 [m2:libraries] Downloading: servletapi/servletapi/2.3/servletapi-2.3.pom
 [m2:libraries] [WARNING] Unable to get resource from repository remote 
 (file:///
 C:/Projects/SmartFrog/core/antbuild/repository/)
 [m2:libraries] Downloading: servletapi/servletapi/2.3/servletapi-2.3.pom
 [m2:libraries] [WARNING] Unable to get resource from repository remote 
 (file:///
 C:/Projects/SmartFrog/core/components/lib/)
 [m2:libraries] Downloading: servletapi/servletapi/2.3/servletapi-2.3.pom
 [m2:libraries] Transferring 0K
 [m2:libraries] [WARNING] *** CHECKSUM FAILED - Checksum failed on download: 
 loca
 l = '46b0527200bcc179e835380eb454b48f6cc16e81'; remote = 'HTML
 [m2:libraries] HEAD
 [m2:libraries] TITLE302' - RETRYING
 [m2:libraries] Downloading: servletapi/servletapi/2.3/servletapi-2.3.pom
 [m2:libraries] Transferring 0K
 [m2:libraries] [WARNING] *** CHECKSUM FAILED - Checksum failed on download: 
 loca
 l = '46b0527200bcc179e835380eb454b48f6cc16e81'; remote = 'HTML
 [m2:libraries] HEAD
 [m2:libraries] TITLE302' - IGNORING
 [m2:libraries] [WARNING] POM for: 'servletapi:servletapi:pom:2.3' does not 
 appea
 r to be valid. Its will be ignored for artifact resolution.
 this is going to be a dog to 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] Updated: (MNG-2685) mvn.bat detection of 4NT syntax error


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

John Casey updated MNG-2685:


Description: 
Copied from the 4NT 8.0 Documentation:

==
Detecting 4NT or Take Command

From a batch file, you can determine if 4NT or TC is loaded by testing for the 
variable function @EVAL, with a test like this:

if [EMAIL PROTECTED] + 2]% == 4 echo %_cmdproc is loaded!

This test can never succeed in CMD.EXE. (Other variable functions could also be 
used for the same purpose.) The _CMDPROC internal variable tells you which 
specific command processor is running.
===

The mvn.bat in 2.0.4 contains:

@REM -- 4NT shell
if %eval[2+2] == 4 goto 4NTArgs

It should be:

@REM -- 4NT shell
if [EMAIL PROTECTED] == 4 goto 4NTArgs

In case, you don't see it, the first one is missing the @ in between the % and 
eval

I will attach a patch in a moment.

  was:
Copied from the 4NT 8.0 Documentation:

==
Detecting 4NT or Take Command
  
From a batch file, you can determine if  4NT or TC is loaded by testing for 
the variable function @EVAL, with a test like this:

if [EMAIL PROTECTED] + 2]% == 4 echo %_cmdproc is loaded!

This test can never succeed in CMD.EXE. (Other variable functions could also be 
used for the same purpose.) The _CMDPROC internal variable tells you which 
specific command processor is running.
===

The mvn.bat in 2.0.4 contains:

@REM -- 4NT shell
if %eval[2+2] == 4 goto 4NTArgs

It should be:

@REM -- 4NT shell
if [EMAIL PROTECTED] == 4 goto 4NTArgs

In case, you don't see it, the first one is missing the @ in between the % and 
eval

I will attach a patch in a moment.

Patch Submitted:   (was: [Yes])

How does this relate to MNG-2503? I just applied the diff between that attached 
mvn.bat and the current trunk, with minor differences...

It's been applied to both trunk and the maven-2.0.x branch...can someone with 
Windows take a look at these two issues, and give us some insight?

 mvn.bat detection of 4NT syntax error
 -

 Key: MNG-2685
 URL: http://jira.codehaus.org/browse/MNG-2685
 Project: Maven 2
  Issue Type: Bug
  Components: Command Line
Affects Versions: 2.0.4
 Environment: Windows XP  4NT 8.0
Reporter: Mark DeLaFranier
 Attachments: MNG-2685.patch


 Copied from the 4NT 8.0 Documentation:
 ==
 Detecting 4NT or Take Command
 From a batch file, you can determine if 4NT or TC is loaded by testing for 
 the variable function @EVAL, with a test like this:
 if [EMAIL PROTECTED] + 2]% == 4 echo %_cmdproc is loaded!
 This test can never succeed in CMD.EXE. (Other variable functions could also 
 be used for the same purpose.) The _CMDPROC internal variable tells you which 
 specific command processor is running.
 ===
 The mvn.bat in 2.0.4 contains:
 @REM -- 4NT shell
 if %eval[2+2] == 4 goto 4NTArgs
 It should be:
 @REM -- 4NT shell
 if [EMAIL PROTECTED] == 4 goto 4NTArgs
 In case, you don't see it, the first one is missing the @ in between the % 
 and eval
 I will attach a patch in a moment.

-- 
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: (MNG-740) dependencies resolution not work using pom on local source tree - special case

2007-06-01 Thread Tyler Peterson (JIRA)

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

Tyler Peterson updated MNG-740:
---

Attachment: mng-740-test-case.zip

The attached archive contains a proposed test case for verifying any fix to
this bug. The bug is demonstrated by the enclosed toy project with the
following structure:

toy [pom]
`-- toy-module [pom]
`-- toy-submodule [jar]

(The text in square brackets ([]) indicates the packaging type.)

The contents of the enclosed README are as follows:

Proposed Test Case for MNG-740
==

Observe defect MNG-740 by performing the following steps.

1. mng-740/toy$ mvn test # should succeed

2. mng-740/toy/toy-module/toy-submodule$ mvn test# should succeed

3. mng-740/toy/toy-module$ mvn test # will fail

When you perform step three, you should see an error indicating
... Cannot find parent: name.tylerpeterson:toy ... or similar.

In fact, any maven command attempted in the toy-module directory will
fail.

dependencies resolution not work using pom on local source tree - special case
--

Key: MNG-740
URL: http://jira.codehaus.org/browse/MNG-740
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0-beta-1
Environment: xp
Reporter: Dan Tran
Fix For: 2.1.x

Attachments: c.log, jira.zip, mng-740-test-case.zip

Folks, I would like to make sure i am able to build my artitfact with it
parent poms are not either in local or remote repo.
Attached is the dummy m2 structure to repoduce the problem.
Here are detail
somedir
root
pom.xml
subprojects
pom.xml
A
pom.xml
BC-parent
B
pom.xml--- depend on A
C
pom.xml --- depends on B
Here are the step the reproduce
1. Install root's pom ( m2 install )
2. Install A ( m2 install in subproejcts/A
3. install B ( m2 install in subprojects/BC-parent/B
4. install C ( m2 install in subprojects/BC-parent/C)
C fails here. See attach logs
however if I do a full install from subprojects or manually install
subproejcts pom and BC-parent pom ( via m2 install -N) the problem goes away

[jira] Updated: (MNG-2640) Expressions in POMs are not modified when the Maven Project is updated


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

John Casey updated MNG-2640:


Patch Submitted:   (was: [Yes])

The supplied patch only addresses the build.finalName expression, not any 
number of other values in MavenProject (or Model, which is what we're really 
talking about).

IMO, we need to address this more generally, rather than continue adding to the 
exceptions list Brett put together to satisfy one funky little case we had that 
depended on broken functionality.

 Expressions in POMs are not modified when the Maven Project is updated
 --

 Key: MNG-2640
 URL: http://jira.codehaus.org/browse/MNG-2640
 Project: Maven 2
  Issue Type: Bug
  Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Reporter: Vincent Massol
 Attachments: MNG-2640.diff


 In the Clover plugin I'm modifying the finalName with:
 {code:java}
 getProject().getBuild().setFinalName( getProject().getArtifactId() + - + 
 getProject().getVersion() + -clover );
 {code}
 This works fine and all subsequent plugins using the MavenProject object do 
 work fine. However if the user uses, say, the AntRun plugin and uses the 
 ${project.build.fineName} expression in his POM it'll return the original 
 value and not the one modified by the Clover plugin. For example if the user 
 is using the AntRun plugin combined with xdoclet Ant tasks to generate files, 
 they won't be put in the correct target directories when used with the Clover 
 plugin and the build will fail...
 See http://jira.codehaus.org/browse/MCLOVER-59 for an issue filed against the 
 Clover plugin on this.
 I think we need a way for reevaluating interpolated expressions when the 
 model is changed.
 Thanks
 -Vincent

-- 
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: (MNG-2619) building from the middle pom of a (parent,child,grandchild) heirarchy fails


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

John Casey updated MNG-2619:


   Assignee: John Casey
Patch Submitted:   (was: [Yes])

 building from the middle pom of a (parent,child,grandchild) heirarchy fails
 ---

 Key: MNG-2619
 URL: http://jira.codehaus.org/browse/MNG-2619
 Project: Maven 2
  Issue Type: Bug
  Components: POM
Affects Versions: 2.0-alpha-1, 2.0.4, 2.0.5
Reporter: Richard van der Hoff
Assignee: John Casey
 Attachments: maven-project-middlepom.patch


 Given a heirerchy of projects - parent, child, grandchild - with parent and 
 module links between them in the normal way:
 Attempting to start a build from the middle of the heirarchy - ie, the 
 child - causes maven to attempt to download the parent from the repository 
 - even if the version in the filesystem is correct in terms of 
 {artifact,group,version}.
 The problem appears to be that the ProjectBuilder first reads the child pom, 
 and caches the result (but not the parent pom). The reactor then makes the 
 ProjectBuilder read the grandchild pom, and hence the child pom (which now 
 comes from the cache), and the parent pom (which it can't find).
 This is much easier demonstrated than explained :/
 The attached patch fixes the problem by making sure that all the projects in 
 the heirarchy (including the parent) are added to the cache. It also includes 
 a test case to demonstrate the problem.

-- 
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: (MNG-2619) building from the middle pom of a (parent,child,grandchild) heirarchy fails


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

John Casey updated MNG-2619:


Patch Submitted: [Yes]

 building from the middle pom of a (parent,child,grandchild) heirarchy fails
 ---

 Key: MNG-2619
 URL: http://jira.codehaus.org/browse/MNG-2619
 Project: Maven 2
  Issue Type: Bug
  Components: POM
Affects Versions: 2.0-alpha-1, 2.0.4, 2.0.5
Reporter: Richard van der Hoff
Assignee: John Casey
 Attachments: maven-project-middlepom.patch


 Given a heirerchy of projects - parent, child, grandchild - with parent and 
 module links between them in the normal way:
 Attempting to start a build from the middle of the heirarchy - ie, the 
 child - causes maven to attempt to download the parent from the repository 
 - even if the version in the filesystem is correct in terms of 
 {artifact,group,version}.
 The problem appears to be that the ProjectBuilder first reads the child pom, 
 and caches the result (but not the parent pom). The reactor then makes the 
 ProjectBuilder read the grandchild pom, and hence the child pom (which now 
 comes from the cache), and the parent pom (which it can't find).
 This is much easier demonstrated than explained :/
 The attached patch fixes the problem by making sure that all the projects in 
 the heirarchy (including the parent) are added to the cache. It also includes 
 a test case to demonstrate the problem.

-- 
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-2065) Abstract resource filtering into Plexus


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

Jason van Zyl closed MNG-2065.
--

Resolution: Fixed

Patch applied.

 Abstract resource filtering into Plexus
 ---

 Key: MNG-2065
 URL: http://jira.codehaus.org/browse/MNG-2065
 Project: Maven 2
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Reporter: Brian Topping
Priority: Minor
 Fix For: 2.2.x

 Attachments: mng-2065.patch


 ResourcesMojo has capacity for doing resource filtering.  This functionality 
 is useful in other parts of the source tree, and rather than duplicate it, I 
 abstracted the functionality into Plexus FileUtils.
 Attached is a patch for ResourcesMojo to use this new functionality.  If you 
 have svn trunk from Plexus, this code will work.  I do not understand the 
 versioning and dependency changes that are required for this, so I left those 
 patches out.  For my part in it, I did a version override to get things to 
 compile.
 I'll get the web filtering done shortly.

-- 
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: (MNG-2988) Ranges with inclusive upper bounds are not validated against metadata


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

Jason van Zyl updated MNG-2988:
---

Patch Submitted:   (was: [Yes])

 Ranges with inclusive upper bounds are not validated against metadata
 -

 Key: MNG-2988
 URL: http://jira.codehaus.org/browse/MNG-2988
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.6
Reporter: Mark Hobson
Assignee: Jason van Zyl
 Attachments: patch.txt


 See http://www.mail-archive.com/[EMAIL PROTECTED]/msg67131.html
 Patch attached.

-- 
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: (MNG-2583) DefaultArtifact: Method getVersionRange returns null also if field version is already set! [SMALL PATCH ATTACHED]