[jira] Closed: (SCM-334) Faulty svn commandline is generated for passwords containing special chars

[Olivier Lamy (JIRA)]

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

Olivier Lamy closed SCM-334.


  Assignee: Olivier Lamy
Resolution: Fixed

Upgrade to last p-u fix the issue (tested on solaris env)

> Faulty svn commandline is generated for passwords containing special chars
> --
>
> Key: SCM-334
> URL: http://jira.codehaus.org/browse/SCM-334
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.0
> Environment: All
>Reporter: Jan Lisse
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 1.1
>
> Attachments: patch.txt
>
>
> If i use a svn password containing a semicolon with the 
> maven-scm-provider-svnexe, the commandline generated by SvnCommandlineUtils 
> is faulty, because
> the password is not quoted. Passwords containing other special chars might 
> cause problems too. 
> Solution: Enclosing the password for the commandline in single quotes solves 
> this problem. 
> I have attached a patch for SvnCommandlineUtils that fixes this issue.

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

[jira] Updated: (MSITE-307) Site generation broken with multi-module property inheritence

[Thomas Schmidt (JIRA)]

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

Thomas Schmidt updated MSITE-307:
-

Attachment: mvn_output.txt

I've reviewed our solution using the actual SNAPSHOT of the site plugin.
Indeed, the build is successfull. But there is still a problem.

I attached the output of Maven which was produced while running the site phase 
in the sample project which is attached to this issue.

First I recognized that if running site on the cleaned project (and not 
installed in my local repository!) the build fails as Maven tries to get the 
module artifacts from the local repository instead of using the project files 
themselves. You can verify that in the attached output log in lines 1 to 84.
Is this the desired behavior? All other phases don't try to use the local 
repository for the modules and use the project files themselves...

The second and more important thing I discovered is that the resolution of 
properties still doesn't work properly.
If you have a look at lines 406 to 419 you see that the site plugin again tries 
to download a wrong version of the parent pom and site.xml while processing the 
first module (i.e. "module-app-${xx_test_module-app_version}"). So it seems 
that the property itself is used instead of the value that it represents when 
processing the modules. I believe that it doesn't happen again for the other 
two modules as the wrong parent then already exists in the local repository. 
You can verify this by running the site phase in the project an then have a 
look into your local repository. There you will find a version folder 
"${xx_test_module-app_version}" in the artifact folder "module-app".

The fact that it doesn't end up in a build error makes it even worse as it 
leaves the impression that everything worked correctly which it didn't.

> Site generation broken with multi-module property inheritence
> -
>
> Key: MSITE-307
> URL: http://jira.codehaus.org/browse/MSITE-307
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: inheritance
>Affects Versions: 2.0-beta-6
> Environment: Ubuntu 7.10, Maven 2.0.8
>Reporter: Eric Ryan
> Attachments: module_project.zip, mvn_output.txt
>
>
> Maven2 site plugin inheritence
> I have a multi-module project with the following directory structure:
> my-app
> |
> |---my-client-ui
> |   |
> |   |---pom.xml
> |
> |---my-core
> |   |
> |   |---pom.xml
> |
> |---my-common
> |   |
> |   |---pom.xml
> |
> |---pom.xml
> I define properties such as ${myVersion}, ${myArtifactId}, ${myGroupId} in 
> the parent pom.  These properties are used by the child poms to resolve the 
> parent pom (they are used in the  tags).  These properties are 
> inherited by the children (as expected) when running goals such as clean, 
> package, or install.
> I start to see problems when I try to use the site plugin.  I first run the 
> install goal to install my project's jars and poms into my local 
> repo(~/.m2/repository/).  I then verify that the jars and poms are in my 
> local repo.  When I try to run the site plugin it seems as though maven is 
> unable to interpret the properties defined in the parent pom.  I receive the 
> following output for each module:
> [INFO] 
> 
> [INFO] Building my-client-ui
> [INFO]task-segment: [site]
> [INFO] 
> 
> [INFO] [site:site]
> Downloading: 
> http://repo1.maven.org/maven2/${myGroupId}/${myArtifactId}/${myVersion}/${myArtifactId}-${myVersion}.pom
> [WARNING] Unable to load parent project from repository: Failed to validate 
> POM for project ${myGroupId}:${myArtifactId} at Artifact 
> [${myGroupId}:${myArtifactId}:pom:${myVersion}]
> [INFO] Generating "Continuous Integration" report...
> I've tried using site:deploy, site:run, and site:stage.  In all cases I 
> recieve a sucessful build, but all sites generated contain broken links. 
> (Note. parent pom's distributionManagement site url=file:///home/eric/tmp) 
> When using site:deploy, there are two issues with the site.  The first is 
> that none of the modules are listed for the project on the left hand side of 
> the screen.  The second is that when I go to the Dependence Convergence 
> section, the links to my project's modules are broken.  In example, the link 
> to my-client-ui incorrectly points to http://www.mycompany.com/my-client-ui 
> when it is in fact located at file:///home/eric/tmp/my-client-ui  (Note.  
> http://www.mycompany.com is defined in the parent pom as the project's url).  
> site:run demonstrates the same problems as site:deploy. 
> When using site:stage -DstagingDirectory=/home/eric/tmp, there are again two 
> issues w/ the site.  The

[jira] Issue Comment Edited: (MSITE-307) Site generation broken with multi-module property inheritence

[Thomas Schmidt (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138503#action_138503
 ] 

mithrandir edited comment on MSITE-307 at 6/13/08 2:48 AM:
---

I've reviewed our solution using the actual SNAPSHOT of the site plugin.
Indeed, the build is successfull. But there is still a problem.

I attached the output of Maven which was produced while running the site phase 
in the sample project which was attached to this issue earlier.

First I recognized that if running site on the cleaned project (and not 
installed in my local repository!) the build fails as Maven tries to get the 
module artifacts from the local repository instead of using the project files 
themselves. You can verify that in the attached output log in lines 1 to 84.
Is this the desired behavior? All other phases don't try to use the local 
repository for the modules and use the project files themselves...

The second and more important thing I discovered is that the resolution of 
properties still doesn't work properly.
If you have a look at lines 406 to 419 of the attached output file you see that 
the site plugin again tries to download a wrong version of the parent pom and 
site.xml while processing the first module (i.e. 
"module-app-${xx_test_module-app_version}"). So it seems that the property 
itself is used instead of the value that it represents when processing the 
modules. I believe that it doesn't happen again for the other two modules as 
the wrong parent then already exists in the local repository. You can verify 
this by running the site phase in the project an then have a look into your 
local repository. There you will find a version folder 
"${xx_test_module-app_version}" in the artifact folder "module-app".

The fact that it doesn't end up in a build error makes it even worse as it 
leaves the impression that everything worked correctly which is not the case.

  was (Author: mithrandir):
I've reviewed our solution using the actual SNAPSHOT of the site plugin.
Indeed, the build is successfull. But there is still a problem.

I attached the output of Maven which was produced while running the site phase 
in the sample project which is attached to this issue.

First I recognized that if running site on the cleaned project (and not 
installed in my local repository!) the build fails as Maven tries to get the 
module artifacts from the local repository instead of using the project files 
themselves. You can verify that in the attached output log in lines 1 to 84.
Is this the desired behavior? All other phases don't try to use the local 
repository for the modules and use the project files themselves...

The second and more important thing I discovered is that the resolution of 
properties still doesn't work properly.
If you have a look at lines 406 to 419 you see that the site plugin again tries 
to download a wrong version of the parent pom and site.xml while processing the 
first module (i.e. "module-app-${xx_test_module-app_version}"). So it seems 
that the property itself is used instead of the value that it represents when 
processing the modules. I believe that it doesn't happen again for the other 
two modules as the wrong parent then already exists in the local repository. 
You can verify this by running the site phase in the project an then have a 
look into your local repository. There you will find a version folder 
"${xx_test_module-app_version}" in the artifact folder "module-app".

The fact that it doesn't end up in a build error makes it even worse as it 
leaves the impression that everything worked correctly which it didn't.
  
> Site generation broken with multi-module property inheritence
> -
>
> Key: MSITE-307
> URL: http://jira.codehaus.org/browse/MSITE-307
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: inheritance
>Affects Versions: 2.0-beta-6
> Environment: Ubuntu 7.10, Maven 2.0.8
>Reporter: Eric Ryan
> Attachments: module_project.zip, mvn_output.txt
>
>
> Maven2 site plugin inheritence
> I have a multi-module project with the following directory structure:
> my-app
> |
> |---my-client-ui
> |   |
> |   |---pom.xml
> |
> |---my-core
> |   |
> |   |---pom.xml
> |
> |---my-common
> |   |
> |   |---pom.xml
> |
> |---pom.xml
> I define properties such as ${myVersion}, ${myArtifactId}, ${myGroupId} in 
> the parent pom.  These properties are used by the child poms to resolve the 
> parent pom (they are used in the  tags).  These properties are 
> inherited by the children (as expected) when running goals such as clean, 
> package, or install.
> I start to see problems when I try to use the site plugin.  I first run the 
> install goal to install my project's jars and poms into my local 
> repo(~/.m

[jira] Updated: (MECLIPSE-368) Dependency configuration in DependencyManagement with exclusions is ignored

[Espen Wiborg (JIRA)]

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

Espen Wiborg updated MECLIPSE-368:
--

Attachment: MECLIPSE-368.patch

Patch for this issue, with test.

> Dependency configuration in DependencyManagement with exclusions is ignored
> ---
>
> Key: MECLIPSE-368
> URL: http://jira.codehaus.org/browse/MECLIPSE-368
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Ubuntu Linux 7.10
>Reporter: jh
> Attachments: exclusion-example-20080116.zip, MECLIPSE-368.patch
>
>
> A transitive dependency which is defined in the DependencyManagement section 
> with exclusions does not take these exclusions into account when generating 
> an eclipse classpath.
> Example:
> - childProject has a dependency 'acegi-security-tiger'
> - parentProject has a dependencyManagement section that defines the version 
> and the exclusions
> - acegi-security-tiger has a transitive dependency to acegi-security
> - parentProject has defined acegi-security and a number of exclusions one of 
> which is spring-remoting 1.2.7
> - childProject's classpath ends up with spring-remoting 1.2.7 as dependency
> - we are using spring 2.5.1 which does not have spring-remoting
> If I check dependencies with dependency:tree -Dscope=null the dependency 
> resolving of acegi-security-tiger stops with acegi-security and no other 
> transitive dependencies are added (all are excluded)
> Workaround is to add acegi-security in childProject's pom. 
> Main concern here is that dependency resolution in the eclipse plugin seems 
> to be different from the dependency 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: (MECLIPSE-368) Dependency configuration in DependencyManagement with exclusions is ignored

[Espen Wiborg (JIRA)]

[ 
http://jira.codehaus.org/browse/MECLIPSE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138505#action_138505
 ] 

Espen Wiborg commented on MECLIPSE-368:
---

Fixed with the attached patch

> Dependency configuration in DependencyManagement with exclusions is ignored
> ---
>
> Key: MECLIPSE-368
> URL: http://jira.codehaus.org/browse/MECLIPSE-368
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Ubuntu Linux 7.10
>Reporter: jh
> Attachments: exclusion-example-20080116.zip, MECLIPSE-368.patch
>
>
> A transitive dependency which is defined in the DependencyManagement section 
> with exclusions does not take these exclusions into account when generating 
> an eclipse classpath.
> Example:
> - childProject has a dependency 'acegi-security-tiger'
> - parentProject has a dependencyManagement section that defines the version 
> and the exclusions
> - acegi-security-tiger has a transitive dependency to acegi-security
> - parentProject has defined acegi-security and a number of exclusions one of 
> which is spring-remoting 1.2.7
> - childProject's classpath ends up with spring-remoting 1.2.7 as dependency
> - we are using spring 2.5.1 which does not have spring-remoting
> If I check dependencies with dependency:tree -Dscope=null the dependency 
> resolving of acegi-security-tiger stops with acegi-security and no other 
> transitive dependencies are added (all are excluded)
> Workaround is to add acegi-security in childProject's pom. 
> Main concern here is that dependency resolution in the eclipse plugin seems 
> to be different from the dependency 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-3519) Artifact finalName is not propagated to other modules.

[Michael Osipov (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138509#action_138509
 ] 

Michael Osipov commented on MNG-3519:
-

Brett,

thanks I'll do in the next couple of days.

> Artifact finalName is not propagated to other modules.
> --
>
> Key: MNG-3519
> URL: http://jira.codehaus.org/browse/MNG-3519
> Project: Maven 2
>  Issue Type: Bug
>  Components: Inheritance and Interpolation
>Affects Versions: 2.0.9
> Environment: Maven 2.0.9, JDK 6, WinXP SP2
>Reporter: Michael Osipov
> Attachments: example.png
>
>
> I have a multimodule project.
> groupId: net.fckeditor
> Parent ArtifactId: fckeditor-java
> 1. module ArtifactId: java-core; finalName 
> "fckeditor-${artifactId}-${version}" though => e.g. 
> fckeditor-java-core-2.4-SNAPSHOT 
> 2. module ArtifactId: java-demo; finalName 
> "fckeditor-${artifactId}-${version}" though
> module one is a jar artifact, module 2 a war artifact which has a dependency 
> on module 2.
> the final WAR file contains all dependencies included the java-core but the 
> jar name is not fckeditor-java-core-2.4-SNAPSHOT.jar but 
> java-core-2.4-SNAPSHOT.jar
> The same happens in assembly and moduleSets.
> An example picture is attached and the project can be checked out at our 
> [trac |http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4] and the 
> [SVN|http://svn.fckeditor.net/FCKeditor.Java/branches/2.4/]  directly

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

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2206:
--

Fix Version/s: (was: 2.0.x)

> 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
> 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 dev 
> - id snapshots with a property snapshots 
> 
> dev
> snapshots
> 
> 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] Updated: (MNG-1985) Triggering Profiles bugs

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-1985:
--

Fix Version/s: (was: 2.0.x)

> Triggering Profiles bugs
> 
>
> Key: MNG-1985
> URL: http://jira.codehaus.org/browse/MNG-1985
> Project: Maven 2
>  Issue Type: Bug
>  Components: Profiles
>Affects Versions: 2.0.2
> Environment: windows2000 maven 2.02
>Reporter: pinghe
>Priority: Critical
>
> ===env 1,
> inside pom.xml
> 
>   
>   env-common
>   
>   true
>   
>   
>   
>   os-win32
>   
>   true
>   
>   
>   performRelease
>   
>   
>   
>   
>   env-prod
>   
>   
>   performRelease
>   
>   
>   
>   
> exec: mvn projecthelp:active-profiles
> output:  
>  - env-common (source: pom)
>  - os-win32 (source: pom)
> exec: mvn projecthelp:active-profiles -DperformRelease
> output:  
>  - env-prod (source: pom)
>  - os-win32 (source: pom)
> expect:
>  - env-prod (source: pom)
>  - os-win32 (source: pom)
>  - env-common (source: pom)
> ===env 2:
> inside pom.xml
> 
>   
>   env-common
>   
>   true
>   
>   
>   
>   os-win32
>   
>   true
>   
>   windows
>   
>   
>   performRelease
>   
>   
>   
>   
>   env-prod
>   
>   
>   performRelease
>   
>   
>   
>   
> exec: mvn projecthelp:active-profiles
> output:  
>  - os-win32 (source: pom)
> expect:
>  - env-prod (source: pom)
>  - os-win32 (source: pom)

-- 
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-2294) If /project/parent/relativePath fails to resolve, no error is reported.

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2294:
--

Fix Version/s: (was: 2.0.x)

> If /project/parent/relativePath fails to resolve, no error is reported.
> ---
>
> Key: MNG-2294
> URL: http://jira.codehaus.org/browse/MNG-2294
> Project: Maven 2
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 2.0.4
>Reporter: David Smiley
>Assignee: Maria Odea Ching
>   Original Estimate: 15 hours
>  Remaining Estimate: 15 hours
>
> If I have a bad /project/parent/relativePath specified, maven does not tell 
> me.  Instead the build proceeds as if there is no parent.  The build should 
> fail if the parent can't be resolved.

-- 
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-3430) Toolchain doesn't match Toolchain extensions

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-3430:
--

Fix Version/s: (was: 2.1-alpha-1)
   (was: 2.0.x)

> Toolchain doesn't match Toolchain extensions
> 
>
> Key: MNG-3430
> URL: http://jira.codehaus.org/browse/MNG-3430
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.9
>Reporter: Shane Isbell
>Assignee: Milos Kleint
>Priority: Minor
> Fix For: 2.0.9
>
>
> Toolchain uses null key within storing toolchains in Maven Session, which 
> causes extensions not to match.
> Specifically, this problem occurs in the 
> DefaultToolchainManager.storeToolchainToBuildContext method.  When storing 
> into context
> context.put( getStorageKey( toolchain.getType() ), toolchain.getModel() );
> toolchain.getType() always returns null. Using toolchain.getModel().getType() 
> will return the correct type and fix 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-2352) Upgrade to plexus-container-default-alpha-10

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2352:
--

Fix Version/s: (was: 2.0.x)

> Upgrade to plexus-container-default-alpha-10
> 
>
> Key: MNG-2352
> URL: http://jira.codehaus.org/browse/MNG-2352
> Project: Maven 2
>  Issue Type: Improvement
>Reporter: Jerome Lacoste
>Priority: Blocker
> Attachments: MNG-2352.diff
>
>
> This is required for MNG-2201 in particular.

-- 
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-2399) file size check on pom.xml (or thing specified by --file opt) should only apply to regular files (patch attached)

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2399:
--

Fix Version/s: (was: 2.0.x)

> 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
> 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] Updated: (MNG-1420) When profile selected in command line doesn't exist print a warning/error

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-1420:
--

Fix Version/s: (was: 2.0.x)

> When profile selected in command line doesn't exist print a warning/error
> -
>
> Key: MNG-1420
> URL: http://jira.codehaus.org/browse/MNG-1420
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Errors, Profiles
>Affects Versions: 2.0
>Reporter: Carlos Sanchez
>Priority: Minor
>


-- 
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-2301) Maven Archiver deleteing already existing pom.properties file.

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2301:
--

Fix Version/s: (was: 2.0.x)

> Maven Archiver deleteing already existing pom.properties file.
> --
>
> Key: MNG-2301
> URL: http://jira.codehaus.org/browse/MNG-2301
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.4
>Reporter: Sharmarke Aden
> Attachments: maven-archiver_pomDelete.patch
>
>
> My project has it's own pom.properties file and it seems that maven archiver 
> is deleting it right after packaging the application. Any particular reason 
> why it's doing this? It seems to me the archiver shouldn't be deleting the 
> file if it already exists. It should delete the file if it doesn't exists 
> otherwise it should add the necessary information (version, groupId, etc) to 
> the file and leave it be. I have attached a patch that fixes the issue. 
> Also note that this patch adds the "builtOn" property to the pom.properties 
> which is satisfy the following enhancement request: 
> http://jira.codehaus.org/browse/MNG-1830 

-- 
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-2203) Problem with duplicates

[Brett Porter (JIRA)]

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

Brett Porter updated MNG-2203:
--

Fix Version/s: (was: 2.0.x)

> Problem with duplicates
> ---
>
> Key: MNG-2203
> URL: http://jira.codehaus.org/browse/MNG-2203
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0-alpha-1, 2.0.3
> Environment: Windows XP SP 2 - JDK 1.5.06 - Maven 2.1-SNAPSHOT 
>Reporter: Francesco Tinti
> Attachments: MNG-2203-maven.patch, pomerr.zip
>
>  Time Spent: 1 day, 6 hours, 30 minutes
>  Remaining Estimate: 0 minutes
>
> Declare in POM a duplicate group-artifact dependency but with different 
> versions.: there's no log of duplicate entry.
> Maven will also take care only of the latest dependency, so if the version is 
> ancient of the other, you can obtain (of course) compilation error.
> In attachment a simple demonstration with a specific commons-io 1.2 function.

-- 
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-3416) Setting testOutDirectory to ${basedir}/target/test-classes causes test classpath to be reversed.

[Ben Lidgey (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138510#action_138510
 ] 

Ben Lidgey commented on MNG-3416:
-

I've not noticed in 2.0.9, but haven't deliberately tested for it either.


> Setting testOutDirectory to ${basedir}/target/test-classes causes test 
> classpath to be reversed.
> 
>
> Key: MNG-3416
> URL: http://jira.codehaus.org/browse/MNG-3416
> Project: Maven 2
>  Issue Type: Bug
>  Components: Inheritance and Interpolation
>Affects Versions: 2.0.8
>Reporter: Ben Lidgey
> Fix For: 2.0.x
>
>
> Environment: maven 2.0.8, surefire 2.4.1,2.4.2
>  We are running tests using Surefire 2.4.1 and Maven 2.0.8. The Junit  test 
> classes are expecting to load a properties file from 
> {{src/test/resources}} with the same name as a properties file in 
> {{src/main/resources}} to load test data etc. However the src/main/resources 
> properties file is being loaded.
> Looking at the debug output shows:
> [DEBUG] Test Classpath :
> [DEBUG]   C:\Documents and
> Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar
> [more jars]
> [DEBUG]   c:\Development\Projects\MyProject\target\classes
> [DEBUG]   c:\Development\Projects\MyProject\target\test-classes
> Which would explain it. Setting childDelegation to true doesn't get the 
> test-classes before classes in the classpath order.
> I generated the effective-pom and used it in a copy of the Surefire 
> integration test for the classpath order 
> (http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/classpath-order).
>  The tests failed. I then trawled through the project POM and then its parent 
> POM commenting out plugins, reporting, dependencies, and other bits until the 
> test passed.
> The thing that was causing the test to fail was that in the parent POM:
> {code:xml}
> package
> target
> ${pom.artifactId}-${pom.version}
> ${basedir}/src/main/java
> ${basedir}/src/test/java
> ${basedir}/target/test-classes
> ${basedir}/target/classes
> {code}
> Changing just testOutputDirectory to
> {code:xml}
> target/test-classes
> {code}
> Made the tests pass. I've no idea why.

-- 
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-3356) Multiple -Dkey=value command line options not handled correctly

[Paul Cager (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138511#action_138511
 ] 

Paul Cager commented on MNG-3356:
-

I've investigated this further (see Apache's list: 
http://mail-archives.apache.org/mod_mbox/commons-user/200805.mbox/[EMAIL 
PROTECTED]). In summary I think version 1.1 is so broken that it is impossible 
to handle multiple "-D" type arguments. I think changing to use "hasArgs()" 
(plural) just makes cli 1.1 fall over in a different way.

Here's an extract of the email I sent to Apache:

As far as I can see it is simply not possible to use commons-cli to
parse repeating options, such as occur in ant:

  ant -Dproperty1=value1 -Dproperty2=value2 compile

Cli *does* have a junit test for ant-type options, but it unfortunately
doesn't catch the error because it tests the command line:

  ant -Dproperty1=value1 -Dproperty2=value2 -projecthelp

I attach a patch for the junit test (Cli-junit.patch) that will provoke 
the error, if you want to try it yourself.


_Here's what I think is happening:_

The unit test (and the work-around suggested in issue 137) creates the
"D" option using "hasArgs()" [note the 's' on the end of the method
name]. Using hasArgs() for the "D" option causes cli to assume that all
arguments following the "-D" (until it encounters another option) belong
to the "-D" option. I've probably not explained that clearly so here's
an example:

  ant -Dproperty1=value1 -Dproperty2=value2 compile

will treat "compile" as though it was "-Dcompile". getArgs() will return
0 elements, rather than one ("compile").

If instead you construct the "D" option using hasArg() [singular] then
it will *not* interpret the second "-D" as an option. getArgs() will
return 2 elements: "property2=value2" and "compile". getOptionValues()
will return only the first -D value.

This problem first came to light when Debian upgraded CLI from 1.0 to 
1.1, and caused Debian's Maven package to fail (the standard Maven 
package uses cli 1.0 of course). As part of the Debian packaging I have 
created a quick-and-dirty patch which allows Maven to work (see 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469082 for the Debian 
bug report, and I have attached the patch (MultiOptions.patch). I would 
guess that a proper fix would be rather more elegant than my patch.



> Multiple -Dkey=value command line options not handled correctly
> ---
>
> Key: MNG-3356
> URL: http://jira.codehaus.org/browse/MNG-3356
> Project: Maven 2
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Christian Koelle
>Priority: Critical
> Fix For: 2.0.x
>
> Attachments: command-line.patch
>
>
> After upgrading to 2.0.8 on Debian the handling of multiple (more than one) 
> -Dkey=value cli options fail, i.e. something like:
> mvn plugin:goal -Dkey1=value1 -Dkey2=value2
> fails with:
> Invalid task 'key2=value2': you must specify a valid lifecycle phase, or a 
> goal in the format plugin:goal or 
> pluginGroupId:pluginArtifactId:pluginVersion:goal

-- 
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: (MARTIFACT-17) Add generics details to collections

[Brett Porter (JIRA)]

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

Brett Porter closed MARTIFACT-17.
-

Resolution: Fixed

> Add generics details to collections
> ---
>
> Key: MARTIFACT-17
> URL: http://jira.codehaus.org/browse/MARTIFACT-17
> Project: Maven Artifact
>  Issue Type: Improvement
>Reporter: Jason Dillon
>Assignee: Jason van Zyl
> Fix For: 3.0-alpha-1
>
> Attachments: MARTIFACT-17-2.diff, MARTIFACT-17-3.diff, 
> MARTIFACT-17.diff
>
>
> Also adds some use of java5 for bits and such.

-- 
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: (MARTIFACT-8) Make wagon lookup case-insensitive with regard to protocol

[Brett Porter (JIRA)]

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

Brett Porter closed MARTIFACT-8.


 Assignee: Brett Porter
   Resolution: Fixed
Fix Version/s: (was: 3.0)
   3.0-alpha-1

> Make wagon lookup case-insensitive with regard to protocol
> --
>
> Key: MARTIFACT-8
> URL: http://jira.codehaus.org/browse/MARTIFACT-8
> Project: Maven Artifact
>  Issue Type: Bug
> Environment: Maven 2.0.8
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>Priority: Minor
> Fix For: 3.0-alpha-1
>
> Attachments: case-insensitive-lookup.patch
>
>
> From [RFC 2396|http://www.ietf.org/rfc/rfc2396.txt], section 3.1, "Scheme 
> Component":
> bq. [...] programs interpreting URI should treat upper case letters as 
> equivalent to lower case in scheme names (e.g., allow "HTTP" as well as 
> "http").
> Currently, the lookup of a wagon fails if the protocol is not completely 
> lower case which deviates from the RFC, the implementation of 
> java.net.URL/URI and everyday experience of users. The attached patch fixes 
> this by normalizing the protocol to lower case before lookup. Porting this 
> fix to other branches or WagonManagers is left to the reviewer.
> Please note the implication of this patch for wagon providers: Any provider 
> that does not use an all lower case role-hint for the registration with 
> Plexus cannot be lookuped. As far as I can see, this is no problem with the 
> existing providers. 

-- 
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: (MARTIFACT-9) Prefer LinkedHashMap over HashMap

[Brett Porter (JIRA)]

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

Brett Porter closed MARTIFACT-9.


 Assignee: Brett Porter
   Resolution: Fixed
Fix Version/s: (was: 3.0)
   3.0-alpha-1

> Prefer LinkedHashMap over HashMap
> -
>
> Key: MARTIFACT-9
> URL: http://jira.codehaus.org/browse/MARTIFACT-9
> Project: Maven Artifact
>  Issue Type: Improvement
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>Priority: Trivial
> Fix For: 3.0-alpha-1
>
> Attachments: deterministic-map-ordering.patch
>
>
> Sometimes order is important, Maven is learning that the hard way (MNG-1412, 
> MNG-3118, SUREFIRE-61, ...). Methods that don't know for sure that ordering 
> is irrelevant should follow "better safe than sorry" and keep the ordering of 
> input collections.

-- 
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: (MAVENUPLOAD-2102) Please upload nanoxml-2.2.3

[Dennis Lundberg (JIRA)]

Please upload nanoxml-2.2.3
---

 Key: MAVENUPLOAD-2102
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2102
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Dennis Lundberg


I'm not a developer of this project. I downloaded the jar file from 
http://nanoxml.cyberelf.be/downloads/nanoxml-2.2.3.jar. Then I downloaded the 
pom for nanoxml-lite-2.2.3 from 
http://repo1.maven.org/maven2/be/cyberelf/nanoxml/lite/2.2.3/lite-2.2.3.pom and 
modified it to have an artifactId of "nanoxml" and also changed the name and 
description. I choose that artifactId because it makes the repository jar file 
name match the name of the jar file that you can download from the nanoxml site.

-- 
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: (MARTIFACT-16) DefaultArtifactVersion.hashCode() violates general contract

[Brett Porter (JIRA)]

[ 
http://jira.codehaus.org/browse/MARTIFACT-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138519#action_138519
 ] 

Brett Porter commented on MARTIFACT-16:
---

I agree we should fix this, but 'm going to hesitate in case we have nay map 
keys relying on DefaultArtifactVersion. We'll need to take a close look at this.

> DefaultArtifactVersion.hashCode() violates general contract
> ---
>
> Key: MARTIFACT-16
> URL: http://jira.codehaus.org/browse/MARTIFACT-16
> Project: Maven Artifact
>  Issue Type: Bug
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
> Fix For: 3.0
>
> Attachments: default-artifact-version-hashcode.patch
>
>
> Compare 
> [{{Object.hashCode()}}|http://java.sun.com/javase/6/docs/api/java/lang/Object.html#hashCode()]
>  and [Effective Java, Chapter 3, "Methods Common to All 
> Objects"|http://java.sun.com/docs/books/effective/chapters.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: (MARTIFACT-14) Use specific encoding for checksum files

[Brett Porter (JIRA)]

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

Brett Porter closed MARTIFACT-14.
-

 Assignee: Brett Porter
   Resolution: Fixed
Fix Version/s: (was: 3.0)
   3.0-alpha-1

> Use specific encoding for checksum files
> 
>
> Key: MARTIFACT-14
> URL: http://jira.codehaus.org/browse/MARTIFACT-14
> Project: Maven Artifact
>  Issue Type: Bug
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>Priority: Minor
> Fix For: 3.0-alpha-1
>
> Attachments: checksum-file-encoding.patch
>
>
> The checksum files are currently written/read using the JVM's default 
> encoding. Even though the ASCII characters constituting the checksums are 
> quite safe from being messed up, the principal possibility for such a problem 
> exists. Just assume somebody running with EBCDIC (like in MANTTASKS-14). See 
> also [Common Bugs|http://www.nabble.com/Re%3A-Common-Bugs-p15919795s177.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] Commented: (MAVENUPLOAD-2102) Please upload nanoxml-2.2.3

[Brett Porter (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138521#action_138521
 ] 

Brett Porter commented on MAVENUPLOAD-2102:
---

Dennis, as a PMC member, would you like access to process uploads?

> Please upload nanoxml-2.2.3
> ---
>
> Key: MAVENUPLOAD-2102
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2102
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Dennis Lundberg
>
> I'm not a developer of this project. I downloaded the jar file from 
> http://nanoxml.cyberelf.be/downloads/nanoxml-2.2.3.jar. Then I downloaded the 
> pom for nanoxml-lite-2.2.3 from 
> http://repo1.maven.org/maven2/be/cyberelf/nanoxml/lite/2.2.3/lite-2.2.3.pom 
> and modified it to have an artifactId of "nanoxml" and also changed the name 
> and description. I choose that artifactId because it makes the repository jar 
> file name match the name of the jar file that you can download from the 
> nanoxml site.

-- 
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: (MARTIFACT-11) Do not use FileReader/FileWriter

[Brett Porter (JIRA)]

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

Brett Porter closed MARTIFACT-11.
-

 Assignee: Brett Porter
   Resolution: Fixed
Fix Version/s: (was: 3.0)
   3.0-alpha-1

> Do not use FileReader/FileWriter
> 
>
> Key: MARTIFACT-11
> URL: http://jira.codehaus.org/browse/MARTIFACT-11
> Project: Maven Artifact
>  Issue Type: Improvement
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>Priority: Trivial
> Fix For: 3.0-alpha-1
>
> Attachments: avoid-platform-specific-encoding.patch
>
>
> Using {{FileReader}} or {{FileWriter}} makes code dependent on the platform's 
> default encoding. For platform-independent behavior, the tests should use a 
> fixed encoding.

-- 
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: (MARTIFACT-16) DefaultArtifactVersion.hashCode() violates general contract

[Benjamin Bentmann (JIRA)]

[ 
http://jira.codehaus.org/browse/MARTIFACT-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138524#action_138524
 ] 

Benjamin Bentmann commented on MARTIFACT-16:


Brett, you could simply add the unit test and closed this issue as fixed. Hervé 
already fixed it in 
[r656776|http://svn.apache.org/viewvc?view=rev&revision=656776].

> DefaultArtifactVersion.hashCode() violates general contract
> ---
>
> Key: MARTIFACT-16
> URL: http://jira.codehaus.org/browse/MARTIFACT-16
> Project: Maven Artifact
>  Issue Type: Bug
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
> Fix For: 3.0
>
> Attachments: default-artifact-version-hashcode.patch
>
>
> Compare 
> [{{Object.hashCode()}}|http://java.sun.com/javase/6/docs/api/java/lang/Object.html#hashCode()]
>  and [Effective Java, Chapter 3, "Methods Common to All 
> Objects"|http://java.sun.com/docs/books/effective/chapters.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: (MARTIFACT-16) DefaultArtifactVersion.hashCode() violates general contract

[Brett Porter (JIRA)]

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

Brett Porter closed MARTIFACT-16.
-

 Assignee: Brett Porter
   Resolution: Fixed
Fix Version/s: (was: 3.0)
   3.0-alpha-1

thanks

> DefaultArtifactVersion.hashCode() violates general contract
> ---
>
> Key: MARTIFACT-16
> URL: http://jira.codehaus.org/browse/MARTIFACT-16
> Project: Maven Artifact
>  Issue Type: Bug
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
> Fix For: 3.0-alpha-1
>
> Attachments: default-artifact-version-hashcode.patch
>
>
> Compare 
> [{{Object.hashCode()}}|http://java.sun.com/javase/6/docs/api/java/lang/Object.html#hashCode()]
>  and [Effective Java, Chapter 3, "Methods Common to All 
> Objects"|http://java.sun.com/docs/books/effective/chapters.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: (MARTIFACT-10) Fix error handling for system-scoped artifacts

[Brett Porter (JIRA)]

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

Brett Porter closed MARTIFACT-10.
-

   Resolution: Duplicate
Fix Version/s: (was: 3.0)

already the case

> Fix error handling for system-scoped artifacts
> --
>
> Key: MARTIFACT-10
> URL: http://jira.codehaus.org/browse/MARTIFACT-10
> Project: Maven Artifact
>  Issue Type: Improvement
>Reporter: Benjamin Bentmann
>Priority: Trivial
> Attachments: file-error-handling.patch
>
>
> The current order of checking for error cases checks {{!File.isFile()}} 
> before {{!File.exists()}}. However, {{!File.isFile()}} might also fail if the 
> file does not exist at all, hence capturing the same case that is intended to 
> be captured by the later check with {{!File.exists()}}. The order needs to be 
> reversed to get the desired exception messages.

-- 
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: (MARTIFACT-10) Fix error handling for system-scoped artifacts

[Benjamin Bentmann (JIRA)]

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

Benjamin Bentmann reopened MARTIFACT-10:



The fix for MNG-3288 is no duplicate, it is the origin of this issue. If the 
file does not exist at all, the code will bail off with "... is not a file ..." 
instead of "... not found in path...", i.e. the later check is effectively 
unreachable. So either the later {{if}} is deleted or needs to be put before 
the check {{!systemFile.isFile()}}.

> Fix error handling for system-scoped artifacts
> --
>
> Key: MARTIFACT-10
> URL: http://jira.codehaus.org/browse/MARTIFACT-10
> Project: Maven Artifact
>  Issue Type: Improvement
>Reporter: Benjamin Bentmann
>Priority: Trivial
> Attachments: file-error-handling.patch
>
>
> The current order of checking for error cases checks {{!File.isFile()}} 
> before {{!File.exists()}}. However, {{!File.isFile()}} might also fail if the 
> file does not exist at all, hence capturing the same case that is intended to 
> be captured by the later check with {{!File.exists()}}. The order needs to be 
> reversed to get the desired exception messages.

-- 
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-3560) unable to use plugins that exist in multiple repositories

[Brett Porter (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138534#action_138534
 ] 

Brett Porter commented on MNG-3560:
---

Thanks for the patch!

I've taken a look - unfortunately the test cases don't appear to be reflective 
of the problem (they pass on an unmodified artifact trunk). Marica, would you 
be able to come up with an integration test that reflects the steps you took 
above?

http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test


> unable to use plugins that exist in multiple repositories
> -
>
> Key: MNG-3560
> URL: http://jira.codehaus.org/browse/MNG-3560
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.9
>Reporter: Maria Catherine Tan
>Assignee: Brett Porter
> Fix For: 2.0.10
>
> Attachments: MNG-3560-maven-artifact.patch
>
>
> I created two test cases using maven-2.0.9
> A. Here's the settings for my first test case which builds successfully using 
> mvn site or mvn site -up
> 1. Created two remote repository
>  - sandbox has maven-project-info-reports-plugin 2.0.1
>  - corporate has maven-project-info-reports-plugin 2.0
> 2. No maven-project-info-reports-plugin in my local repository
> 3. Access to central repository is disabled
> 4. The order in my settings.xml for the plugin repositories is sandbox first 
> before corporate
> 
> sandbox
> http://localhost:9091/repository/sandbox
> 
> 
> corporate
> http://localhost:9091/repository/corporate
> 
> Result:
> * downloaded maven-project-info-reports-plugin 2.0 pom in corporate
> * check maven-project-info-reports-plugin 2.0 jar in sandbox
> * downloaded maven-project-info-reports-plugin 2.0 jar in corporate
> {code}
> [EMAIL PROTECTED]:~/projects/testproject$ mvn site -up
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Building testproject
> [INFO]task-segment: [site]
> [INFO] 
> 
> [INFO] artifact org.apache.maven.plugins:maven-project-info-reports-plugin: 
> checking for updates from sandbox
> [INFO] artifact org.apache.maven.plugins:maven-project-info-reports-plugin: 
> checking for updates from corporate
> [INFO] artifact org.apache.maven.plugins:maven-project-info-reports-plugin: 
> checking for updates from central
> [WARNING] repository metadata for: 'artifact 
> org.apache.maven.plugins:maven-project-info-reports-plugin' could not be 
> retrieved from repository: central due to an error: Error transferring file
> [INFO] Repository 'central' will be blacklisted
> Downloading: 
> http://localhost:9091/repository/corporate/org/apache/maven/plugins/maven-project-info-reports-plugin/2.0/maven-project-info-reports-plugin-2.0.pom
> 5K downloaded
> Downloading: 
> http://localhost:9091/repository/sandbox/org/apache/maven/plugins/maven-project-info-reports-plugin/2.0/maven-project-info-reports-plugin-2.0.jar
> Downloading: 
> http://localhost:9091/repository/corporate/org/apache/maven/plugins/maven-project-info-reports-plugin/2.0/maven-project-info-reports-plugin-2.0.jar
> [INFO] Setting property: classpath.resource.loader.class => 
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [site:site]
> [INFO] Generating "Source Repository" report.
> [INFO] Generating "Issue Tracking" report.
> [INFO] Generating "About" report.
> [INFO] Generating "Project License" report.
> [INFO] Generating "Project Summary" report.
> [INFO] Generating "Dependencies" report.
> [INFO] Generating "Continuous Integration" report.
> [INFO] Generating "Project Team" report.
> [INFO] Generating "Mailing Lists" report.
> [INFO] 
> 
> [INFO] BUILD SUCCESSFUL
> [INFO] 
> 
> {code}
> B. Here's the settings for my second test case which replicate this issue
> 1. Created two remote repository
>  - sandbox has maven-project-info-reports-plugin 2.0.1
>  - corporate has maven-project-info-reports-plugin 2.0
> 2. No maven-project-info-reports-plugin in my local repository
> 3. Access to central repository is disabled
> 4. The order in my settings.xml for the plugin repositories is corporate 
> first before sandbox
> 
> corporate
> http://localhost:9091/repository/corporate
> 
> 
> sandbox
> http://localhost:9091/repository/sandbox
> 
> Result:
> * downloaded maven-project-info-reports-plugin 2.0 pom 

[jira] Commented: (MASSEMBLY-214) java.lang.NullPointerException: version was null for junit:junit

[Markus Nolte (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138536#action_138536
 ] 

Markus Nolte commented on MASSEMBLY-214:


the exception occurs if you define a version range in the parents dependency 
management:
e.g.
 
  junit
  junit
  [3.8,4.0)
  jar
  test

 
workaround: set a fixed version in the assembly project, skipping tests does 
not work


> java.lang.NullPointerException: version was null for junit:junit
> 
>
> Key: MASSEMBLY-214
> URL: http://jira.codehaus.org/browse/MASSEMBLY-214
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Christian Schulte
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.2-beta-2
>
>
> Released version completely does not work for me anymore.
> [INFO] 
> 
> [INFO] version was null for junit:junit
> [INFO] 
> 
> [INFO] Trace
> java.lang.NullPointerException: version was null for junit:junit
> at 
> org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:364)
> at 
> org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225)
> at 
> org.apache.maven.shared.artifact.filter.ScopeArtifactFilter.include(ScopeArtifactFilter.java:142)
> at 
> org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:345)
> at 
> org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencies(DefaultDependencyResolver.java:82)
> at 
> org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.resolveDependencyArtifacts(AddDependencySetsTask.java:155)
> at 
> org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:100)
> at 
> org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:90)
> at 
> org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:54)
> at 
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:98)
> at 
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:278)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
> 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: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)

-- 
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: (MARTIFACT-10) Fix error handling for system-scoped artifacts

[Brett Porter (JIRA)]

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

Brett Porter closed MARTIFACT-10.
-

 Assignee: Brett Porter
   Resolution: Fixed
Fix Version/s: 3.0-alpha-1

my mistake - patch was saying it was already applied, I misread it.

(btw, feel free to apply yourself for others :)

> Fix error handling for system-scoped artifacts
> --
>
> Key: MARTIFACT-10
> URL: http://jira.codehaus.org/browse/MARTIFACT-10
> Project: Maven Artifact
>  Issue Type: Improvement
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>Priority: Trivial
> Fix For: 3.0-alpha-1
>
> Attachments: file-error-handling.patch
>
>
> The current order of checking for error cases checks {{!File.isFile()}} 
> before {{!File.exists()}}. However, {{!File.isFile()}} might also fail if the 
> file does not exist at all, hence capturing the same case that is intended to 
> be captured by the later check with {{!File.exists()}}. The order needs to be 
> reversed to get the desired exception messages.

-- 
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: (MARTIFACT-10) Fix error handling for system-scoped artifacts

[Benjamin Bentmann (JIRA)]

[ 
http://jira.codehaus.org/browse/MARTIFACT-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138539#action_138539
 ] 

Benjamin Bentmann commented on MARTIFACT-10:


bq. btw, feel free to apply yourself for others
Sorry, but there are some parts of Maven that I really don't like to touch. 
Please don't take it as an offense, but the almost complete lack of proper API 
docs for maven-artifact (and other vital core components) makes me perceive 
such code as voodoo and I am on the other side not skilled enough to call 
myself a voodoo priest.

> Fix error handling for system-scoped artifacts
> --
>
> Key: MARTIFACT-10
> URL: http://jira.codehaus.org/browse/MARTIFACT-10
> Project: Maven Artifact
>  Issue Type: Improvement
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>Priority: Trivial
> Fix For: 3.0-alpha-1
>
> Attachments: file-error-handling.patch
>
>
> The current order of checking for error cases checks {{!File.isFile()}} 
> before {{!File.exists()}}. However, {{!File.isFile()}} might also fail if the 
> file does not exist at all, hence capturing the same case that is intended to 
> be captured by the later check with {{!File.exists()}}. The order needs to be 
> reversed to get the desired exception messages.

-- 
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-3413) Allow plugins to be downloaded from standard repository

[Paul Gier (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138547#action_138547
 ] 

Paul Gier commented on MNG-3413:


Yes, the changes in 2.1 removes the need for this issue.

> Allow plugins to be downloaded from standard repository
> ---
>
> Key: MNG-3413
> URL: http://jira.codehaus.org/browse/MNG-3413
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Dependencies, Plugins and Lifecycle, Settings
>Reporter: Paul Gier
>Assignee: Brett Porter
>Priority: Minor
>
> I would like to be able to define a single repository either in settings.xml 
> or in my pom that can be used for downloading both project dependencies and 
> plugins.  In many situations the regular repository and the plugin repository 
> are the same place, so it would be nice to be able to do something like this:
> 
>   snapshots.mydomain.com
>   My snapshot repository
>   http://snapshots.mydomain.com/
>   
> true
>   
>   
> false
>   
>   
> true
>   
> 
>  
> This would allow me to download snapshots of both project dependencies and 
> plugins from the repository without needing to configure a separate plugin 
> 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] Created: (MRELEASE-357) mutable CVS User

[Franz Mayer (JIRA)]

mutable CVS User


 Key: MRELEASE-357
 URL: http://jira.codehaus.org/browse/MRELEASE-357
 Project: Maven 2.x Release Plugin
  Issue Type: Improvement
  Components: scm
Affects Versions: 2.0
 Environment: Maven version: 2.0.8
Java version: 1.5.0_05
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Reporter: Franz Mayer


Hi, I would like to have a mutable user of the cvs-connection, since the 
changes are done of different users. So I tried to do it like this:

scm:cvs:pserver:${CVS_USER}@


The ${CVS_USER} is a property in settings.xml. This works fine for the first 
time, but when doing mvn release:clean release:prepare maven substitutes the 
CVS_USER for the current user and checks the pom in like this:

scm:cvs:pserver:@


It would be good, if the pom wouldn't override the variable ${CVS_USER}.

-- 
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: (MARTIFACT-12) [regression] ear dependencies are propagated transitively

[Brett Porter (JIRA)]

[ 
http://jira.codehaus.org/browse/MARTIFACT-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138549#action_138549
 ] 

Brett Porter commented on MARTIFACT-12:
---

the component descriptors for the artifact handlers were removed - need to 
check whether they are actually still used, and if so add a factory back for 
these

> [regression] ear dependencies are propagated transitively
> -
>
> Key: MARTIFACT-12
> URL: http://jira.codehaus.org/browse/MARTIFACT-12
> Project: Maven Artifact
>  Issue Type: Bug
>Affects Versions: 3.0-alpha-1
>Reporter: Brett Porter
> Fix For: 3.0-alpha-1
>
>
> In Maven 2.0.x, if you have a dependency on an EAR, the dependencies of the 
> EAR are not exposed as transitive dependencies since they are already packed 
> inside the EAR.
> While alternate solutions for this (to solve both the Java EE scenarios, and 
> shading/uberjar/assembly type dependencies), no such solution is in place so 
> the previous functionality should be retained until deprecated and removed.

-- 
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-2199) Version ranges not supported for parent artifacts

[Sander Nieuwenhuizen (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138551#action_138551
 ] 

Sander Nieuwenhuizen commented on MNG-2199:
---

It makes no sense imho that you cannot set a version range for the parent as 
you can with any other (regular) dependency. I would like the option to let my 
artifact lift on the latest version of the parent instead of linking it 
strictly to a specific version of the parent.

> Version ranges not supported for parent artifacts
> -
>
> Key: MNG-2199
> URL: http://jira.codehaus.org/browse/MNG-2199
> Project: Maven 2
>  Issue Type: Bug
>  Components: Inheritance and Interpolation, POM, Reactor and workspace
>Affects Versions: 2.0.3
>Reporter: Christian Schulte
> Fix For: 2.1
>
>
> It would be great if Maven supports version ranges when specifying parent 
> artifacts in a multi-module build. Currently this does not work.
>   
> artifactId
> groupId
> [2.0, 2.0.1]
>   
> [INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
> 2.0.1]/artifactId-[2.0, 2.0.1].pom
> Additionally it would be great if this
>   
> artifactId
> groupId
> [2.0, ${pom.version}]
>   
> [INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
> ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
> would also work, if the version is specified in the same pom.xml which 
> defines this parent definition.

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

[jira] Created: (MDEPLOY-80) No deployment of attached artifacts when no main build artifact set

[Ringo De Smet (JIRA)]

No deployment of attached artifacts when no main build artifact set
---

 Key: MDEPLOY-80
 URL: http://jira.codehaus.org/browse/MDEPLOY-80
 Project: Maven 2.x Deploy Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Maven version: 2.0.9
Java version: 1.4.2_09
OS name: "windows 2000" version: "5.0" arch: "x86" Family: "windows"
Reporter: Ringo De Smet


The install plugin installs attached artifacts, even when there is no main 
build artifact set. The deploy plugin throws a MojoExecutionException if no 
such main build artifact set. When this occurs, the attached artifacts are not 
deployed.

Look at the code differences in the InstallMojo and the DeployMojo:

http://maven.apache.org/plugins/maven-install-plugin/xref/org/apache/maven/plugin/install/InstallMojo.html
http://maven.apache.org/plugins/maven-deploy-plugin/xref/org/apache/maven/plugin/deploy/DeployMojo.html

The install mojo first checks if there are attached artifacts (line 118) before 
it ends up in the throws clause. I ask for a similar code change in the deploy 
plugin.

We have a custom Maven plugin that generates a number of artifacts, each one 
under a different classifier, but without a main build artifact. The install in 
the local repository succeeds, the deploy fails:

[INFO] [install:install]
[INFO] No primary artifact to install, installing attached artifacts instead.
[INFO] Installing 
C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.control_public_common.jar
 to 
C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-control_public_common.jar
[INFO] Installing 
C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.java_public_common.jar
 to 
C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-java_public_common.jar
[INFO] Installing 
C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.schema_system.jar
 to 
C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-schema_system.jar
[INFO] Installing 
C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.wli_control_error.jar
 to 
C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-wli_control_error.jar
[INFO] Installing 
C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.wli_control_process.jar
 to 
C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-wli_control_process.jar
[INFO] Installing 
C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT-tests.jar to 
C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-tests.jar
[INFO] Installing 
C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT-sources.jar 
to 
C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-sources.jar
[INFO] Installing 
C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT-test-sources.jar
 to 
C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-test-sources.jar
[INFO] [deploy:deploy]
altDeploymentRepository = null
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] The packaging for this project did not assign a file to the build 
artifact
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 2 minutes 32 seconds
[INFO] Finished at: Fri Jun 13 15:50:11 CEST 2008
[INFO] Final Memory: 25M/347M
[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: (MNG-3068) Build extensions fail to load if not available locally and remote repo is defined in the same POM where the extension is defined

[Brian Brooks (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138553#action_138553
 ] 

Brian Brooks commented on MNG-3068:
---

Thanks for the guidance Brett, I was pretty confused with all the similarly 
named projects.  I opened a defect in the Maven Integration for Eclipse project
http://jira.codehaus.org/browse/MNGECLIPSE-684

> Build extensions fail to load if not available locally and remote repo is 
> defined in the same POM where the extension is defined
> 
>
> Key: MNG-3068
> URL: http://jira.codehaus.org/browse/MNG-3068
> Project: Maven 2
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.1
>Reporter: Vincent Massol
>Assignee: John Casey
> Fix For: 2.1-alpha-1
>
>
> * If you define the remote repo in settings.xml it works 
> * If you define it in the pom.xml file it doesn't work 
> For example, this fails if xwiki-build-xar-handlers isn't available in the 
> local repo: 
> {noformat} 
>  
>  
>  
> com.xpn.xwiki.platform 
> xwiki-build-xar-handlers 
> 1.0-SNAPSHOT 
>  
>  
>  
>  
>  
> xwiki 
> XWiki Maven2 Remote Repository 
> http://maven.xwiki.org 
>  
> true 
>  
>  
> true 
>  
>  
>  
>  
> {noformat}

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

[jira] Closed: (MDEPLOY-80) No deployment of attached artifacts when no main build artifact set

[Wendy Smoak (JIRA)]

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

Wendy Smoak closed MDEPLOY-80.
--

Resolution: Duplicate

Duplicate of MDEPLOY-45 (which is fixed but not yet released)

> No deployment of attached artifacts when no main build artifact set
> ---
>
> Key: MDEPLOY-80
> URL: http://jira.codehaus.org/browse/MDEPLOY-80
> Project: Maven 2.x Deploy Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: Maven version: 2.0.9
> Java version: 1.4.2_09
> OS name: "windows 2000" version: "5.0" arch: "x86" Family: "windows"
>Reporter: Ringo De Smet
>
> The install plugin installs attached artifacts, even when there is no main 
> build artifact set. The deploy plugin throws a MojoExecutionException if no 
> such main build artifact set. When this occurs, the attached artifacts are 
> not deployed.
> Look at the code differences in the InstallMojo and the DeployMojo:
> http://maven.apache.org/plugins/maven-install-plugin/xref/org/apache/maven/plugin/install/InstallMojo.html
> http://maven.apache.org/plugins/maven-deploy-plugin/xref/org/apache/maven/plugin/deploy/DeployMojo.html
> The install mojo first checks if there are attached artifacts (line 118) 
> before it ends up in the throws clause. I ask for a similar code change in 
> the deploy plugin.
> We have a custom Maven plugin that generates a number of artifacts, each one 
> under a different classifier, but without a main build artifact. The install 
> in the local repository succeeds, the deploy fails:
> [INFO] [install:install]
> [INFO] No primary artifact to install, installing attached artifacts instead.
> [INFO] Installing 
> C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.control_public_common.jar
>  to 
> C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-control_public_common.jar
> [INFO] Installing 
> C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.java_public_common.jar
>  to 
> C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-java_public_common.jar
> [INFO] Installing 
> C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.schema_system.jar
>  to 
> C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-schema_system.jar
> [INFO] Installing 
> C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.wli_control_error.jar
>  to 
> C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-wli_control_error.jar
> [INFO] Installing 
> C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT.wli_control_process.jar
>  to 
> C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-wli_control_process.jar
> [INFO] Installing 
> C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT-tests.jar 
> to 
> C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-tests.jar
> [INFO] Installing 
> C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT-sources.jar 
> to 
> C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-sources.jar
> [INFO] Installing 
> C:\Data\Workspaces\HEAD\wli.common\target\wli.common-1.0-SNAPSHOT-test-sources.jar
>  to 
> C:\Data\maven\repository\be\telenet\wli.common\1.0-SNAPSHOT\wli.common-1.0-SNAPSHOT-test-sources.jar
> [INFO] [deploy:deploy]
> altDeploymentRepository = null
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] The packaging for this project did not assign a file to the build 
> artifact
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 2 minutes 32 seconds
> [INFO] Finished at: Fri Jun 13 15:50:11 CEST 2008
> [INFO] Final Memory: 25M/347M
> [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: (MNG-3540) No plugin update from a staged repository

[JIRA]

[ 
http://jira.codehaus.org/browse/MNG-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138581#action_138581
 ] 

Raphaël Piéroni commented on MNG-3540:
--

At that time i reproduced the problem using
only a profile containing repository plugin-repository. 
it was activated by default.
...

staged


stagedR
stagedR

http://people.apache.org/~rafale/archetype-stage-repository/




stagedP
stagedP

http://people.apache.org/~rafale/archetype-stage-repository/



...


nexus
Nexus
external:*
http://localhost:8081/nexus/content/groups/all




> No plugin update from a staged repository
> -
>
> Key: MNG-3540
> URL: http://jira.codehaus.org/browse/MNG-3540
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: Maven 2.0.9,  JDK6, both linux and windows 
>Reporter: Raphaël Piéroni
> Fix For: 2.0.x
>
> Attachments: with-nexus.txt, with-profile.txt
>
>
> The archetype plugin depends on other projects.
> One of them is staged along with the plugin in a
> staged repository.
> When i define that repository in settings.xml in a profile
> which is always activated (both repository and pluginRepository)
> and remove all references from archetype in my local repository.
> I then call mvn archetype:create-from-project.
> Maven downloads the plugin but don't download the dependencies
> there it fails to instantiate the first used class from these dependencies.
> The first attachment (with-profile.txt) holds the trace
> When i define the repository in nexus (grouping first the repository then 
> central in one url) and defining that url as mirror of central in my setting,
> Also using a fresh repository. I call the same goal, and it works.
> The second attachment (with-nexus.txt) holds the trace.

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

[jira] Issue Comment Edited: (MNG-3540) No plugin update from a staged repository

[JIRA]

[ 
http://jira.codehaus.org/browse/MNG-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138581#action_138581
 ] 

raphael edited comment on MNG-3540 at 6/13/08 2:58 PM:
---

At that time i reproduced the problem using
only a profile containing repository plugin-repository. 
it was activated by default.
{code:xml} 
...

staged


stagedR
stagedR

http://people.apache.org/~rafale/archetype-stage-repository/




stagedP
stagedP

http://people.apache.org/~rafale/archetype-stage-repository/



...


nexus
Nexus
external:*
http://localhost:8081/nexus/content/groups/all


{code} 

  was (Author: raphael):
At that time i reproduced the problem using
only a profile containing repository plugin-repository. 
it was activated by default.
...

staged


stagedR
stagedR

http://people.apache.org/~rafale/archetype-stage-repository/




stagedP
stagedP

http://people.apache.org/~rafale/archetype-stage-repository/



...


nexus
Nexus
external:*
http://localhost:8081/nexus/content/groups/all



  
> No plugin update from a staged repository
> -
>
> Key: MNG-3540
> URL: http://jira.codehaus.org/browse/MNG-3540
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: Maven 2.0.9,  JDK6, both linux and windows 
>Reporter: Raphaël Piéroni
> Fix For: 2.0.x
>
> Attachments: with-nexus.txt, with-profile.txt
>
>
> The archetype plugin depends on other projects.
> One of them is staged along with the plugin in a
> staged repository.
> When i define that repository in settings.xml in a profile
> which is always activated (both repository and pluginRepository)
> and remove all references from archetype in my local repository.
> I then call mvn archetype:create-from-project.
> Maven downloads the plugin but don't download the dependencies
> there it fails to instantiate the first used class from these dependencies.
> The first attachment (with-profile.txt) holds the trace
> When i define the repository in nexus (grouping first the repository then 
> central in one url) and defining that url as mirror of central in my setting,
> Also using a fresh repository. I call the same goal, and it works.
> The second attachment (with-nexus.txt) holds the trace.

-- 
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-2102) Please upload nanoxml-2.2.3

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138584#action_138584
 ] 

Dennis Lundberg commented on MAVENUPLOAD-2102:
--

Sure, the more hands the better.

> Please upload nanoxml-2.2.3
> ---
>
> Key: MAVENUPLOAD-2102
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2102
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Dennis Lundberg
>
> I'm not a developer of this project. I downloaded the jar file from 
> http://nanoxml.cyberelf.be/downloads/nanoxml-2.2.3.jar. Then I downloaded the 
> pom for nanoxml-lite-2.2.3 from 
> http://repo1.maven.org/maven2/be/cyberelf/nanoxml/lite/2.2.3/lite-2.2.3.pom 
> and modified it to have an artifactId of "nanoxml" and also changed the name 
> and description. I choose that artifactId because it makes the repository jar 
> file name match the name of the jar file that you can download from the 
> nanoxml site.

-- 
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-3583) Shorten the path to the IT for MNG-3341

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138585#action_138585
 ] 

Dennis Lundberg commented on MNG-3583:
--

Problem for me is that I don't use cygwin...

> Shorten the path to the IT for MNG-3341
> ---
>
> Key: MNG-3583
> URL: http://jira.codehaus.org/browse/MNG-3583
> Project: Maven 2
>  Issue Type: Task
>  Components: integration tests
> Environment: Windows XP
>Reporter: Dennis Lundberg
>Assignee: Brett Porter
>
> Some paths in that IT are to long for a Windows file system. Checking out 
> core-integration-testing to a folder with the same name in the root of a 
> Windows drive doesn't work because the length of the path exceeds the 255 
> character limit.
> {noformat}
> svn: Can't open file 
> 'core-integration-tests\src\test\resources\mng-3341-metadataUpdatedFromDeploymentRepository\deployment-repository\org\apache\maven\its\mng3341\test-artifact\1.0-SNAPSHOT\.svn\tmp\text-base\test-artifact-1.0-20080306.011328-1.pom.md5.svn-base'
> {noformat}
> Please make the path shorter.

-- 
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-3583) Shorten the path to the IT for MNG-3341

[Benjamin Bentmann (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138586#action_138586
 ] 

Benjamin Bentmann commented on MNG-3583:


And Dennis is not the only developer...

The path
{noformat}
core-integration-tests\src\test\resources\mng-3341-metadataUpdatedFromDeployRepo\deploy-repo\org\apache\maven\its\mng3341\test\1.0-SNAPSHOT\.svn\tmp\text-base\test-1.0-20080306.011328-1.pom
{noformat}
is notably shorter and should still be sufficiently expressive, isn't it?

> Shorten the path to the IT for MNG-3341
> ---
>
> Key: MNG-3583
> URL: http://jira.codehaus.org/browse/MNG-3583
> Project: Maven 2
>  Issue Type: Task
>  Components: integration tests
> Environment: Windows XP
>Reporter: Dennis Lundberg
>Assignee: Brett Porter
>
> Some paths in that IT are to long for a Windows file system. Checking out 
> core-integration-testing to a folder with the same name in the root of a 
> Windows drive doesn't work because the length of the path exceeds the 255 
> character limit.
> {noformat}
> svn: Can't open file 
> 'core-integration-tests\src\test\resources\mng-3341-metadataUpdatedFromDeploymentRepository\deployment-repository\org\apache\maven\its\mng3341\test-artifact\1.0-SNAPSHOT\.svn\tmp\text-base\test-artifact-1.0-20080306.011328-1.pom.md5.svn-base'
> {noformat}
> Please make the path shorter.

-- 
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: (MAVENUPLOAD-2103) Please add Morph v1.1 to the m2 repo

[Matt Benson (JIRA)]

Please add Morph v1.1 to the m2 repo


 Key: MAVENUPLOAD-2103
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2103
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Matt Benson


I am user orangeherbert, Project Admin for this sf.net project.  Thanks!

-- 
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-2433) Maven looks for snapshots in offline mode

[Philip Wu (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138594#action_138594
 ] 

Philip Wu commented on MNG-2433:


I have maven version 2.0.9 and I am having the same issue.

doing "mvn install -Dmaven.test.skip" works fine, but when I use
"mvn install -Dmaven.test.skip -o" (the offline mode) it doesn't work and I 
double checked that the jar is in my local repo!
It's painfully slow to do a build trying to download all the dependencies and 
POM files everytime!

> Maven looks for snapshots in offline mode
> -
>
> Key: MNG-2433
> URL: http://jira.codehaus.org/browse/MNG-2433
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.5
>Reporter: Carsten Ziegeler
>Assignee: Jason van Zyl
>Priority: Critical
> Fix For: 2.0.6
>
>
> It seems that sometimes Maven2 is looking for snapshots in offline mode (this 
> happens for example in the Cocoon project). here is an output that might help:
> :\dev\workspace\cocoon-2.2\core\cocoon-webapp>mvn -o -Dmaven.test.skip=true 
> coc
> oon:deploy
> [INFO]
> NOTE: Maven is executing in offline mode. Any artifacts not already in your 
> loca
> l
> repository will be inaccessible.
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'cocoon'.
> [INFO] org.apache.maven.plugins: checking for updates from snapshots
> [INFO] org.apache.maven.plugins: checking for updates from mortbay-repo
> [INFO] org.codehaus.mojo: checking for updates from snapshots
> [INFO] org.codehaus.mojo: checking for updates from mortbay-repo
> [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
> checkin
> g for updates from snapshots
> [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
> checkin
> g for updates from mortbay-repo
> [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
> checkin
> g for updates from central
> [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
> checkin
> g for updates from apache.snapshot
> [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
> checkin
> g for updates from apache-cvs
> [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
> checkin
> g for updates from apache.snapshots
> [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
> updat
> es from snapshots
> [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
> updat
> es from mortbay-repo
> [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
> updat
> es from central
> [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
> updat
> es from apache.snapshot
> [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
> updat
> es from apache-cvs
> [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
> updat
> es from apache.snapshots
> [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
> for
> updates from snapshots
> [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
> for
> updates from mortbay-repo
> [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
> for
> updates from central
> [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
> for
> updates from apache.snapshot
> [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
> for
> updates from apache-cvs
> [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
> for
> updates from apache.snapshots
> [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
> from s
> napshots
> [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
> from m
> ortbay-repo
> [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
> from c
> entral
> [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
> from a
> pache.snapshot
> [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
> from a
> pache-cvs
> [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
> from a
> pache.snapshots

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

[jira] Commented: (MSITE-238) multi project default URL is wrong

[Paul Sundling (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138595#action_138595
 ] 

Paul Sundling commented on MSITE-238:
-

It's confusing for a starting user that when you do mvn site:site the links for 
the subprojects aren't pointing to the write place with where the files are 
generated.  As John Allen comments if you do mvn site:site site:deploy and the 
url is not filled in, then this will copy the files to a location that will 
have the right links for the subprojects.

i.e. after doing site:site on ANY multi-module project without urls specified:

actual site generation location:
overall/target/site/  (parent project)
overall/child1/target/site/  (child 1)
overall/child2/target/site/  (child 2)

It would be nice if the subprojects would have links to where the site files 
for subprojects are generated when no url is provided, using relative paths  
Then the url could be templated for the stage/deploy use cases and the relative 
links to projects would always work, even for site:site.



> multi project default URL is wrong
> --
>
> Key: MSITE-238
> URL: http://jira.codehaus.org/browse/MSITE-238
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: multi module
>Reporter: Paul Sundling
>Priority: Trivial
>
> In multi module projects the default URL if non is included is 
> //target/site//index.html , but it 
> should be ///target/site/index.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] Issue Comment Edited: (MSITE-238) multi project default URL is wrong

[Paul Sundling (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138595#action_138595
 ] 

sundling edited comment on MSITE-238 at 6/13/08 7:13 PM:
--

It's confusing for a starting user that when you do mvn site:site the links for 
the subprojects aren't pointing to the right place with where the files are 
generated.  As John Allen comments if you do mvn site:site site:deploy and the 
url is not filled in, then this will copy the files to a location that will 
have the right links for the subprojects.

i.e. after doing site:site on ANY multi-module project without urls specified:

actual site generation location:
overall/target/site/  (parent project)
overall/child1/target/site/  (child 1)
overall/child2/target/site/  (child 2)

It would be nice if the subprojects would have links to where the site files 
for subprojects are generated when no url is provided, using relative paths  
Then the url could be templated for the stage/deploy use cases and the relative 
links to projects would always work, even for site:site.



  was (Author: sundling):
It's confusing for a starting user that when you do mvn site:site the links 
for the subprojects aren't pointing to the write place with where the files are 
generated.  As John Allen comments if you do mvn site:site site:deploy and the 
url is not filled in, then this will copy the files to a location that will 
have the right links for the subprojects.

i.e. after doing site:site on ANY multi-module project without urls specified:

actual site generation location:
overall/target/site/  (parent project)
overall/child1/target/site/  (child 1)
overall/child2/target/site/  (child 2)

It would be nice if the subprojects would have links to where the site files 
for subprojects are generated when no url is provided, using relative paths  
Then the url could be templated for the stage/deploy use cases and the relative 
links to projects would always work, even for site:site.


  
> multi project default URL is wrong
> --
>
> Key: MSITE-238
> URL: http://jira.codehaus.org/browse/MSITE-238
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: multi module
>Reporter: Paul Sundling
>Priority: Trivial
>
> In multi module projects the default URL if non is included is 
> //target/site//index.html , but it 
> should be ///target/site/index.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] Commented: (MNG-3583) Shorten the path to the IT for MNG-3341

[Brett Porter (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138598#action_138598
 ] 

Brett Porter commented on MNG-3583:
---

Dennis - it works without cygwin - just type the absolute path or appropriate 
windows env var. It was something I recently discovered :)

Benjamin - I agree, though that path is probably still too long and there are 
lots of examples of it. It'd really be best to pack the repos up in some way 

> Shorten the path to the IT for MNG-3341
> ---
>
> Key: MNG-3583
> URL: http://jira.codehaus.org/browse/MNG-3583
> Project: Maven 2
>  Issue Type: Task
>  Components: integration tests
> Environment: Windows XP
>Reporter: Dennis Lundberg
>Assignee: Brett Porter
>
> Some paths in that IT are to long for a Windows file system. Checking out 
> core-integration-testing to a folder with the same name in the root of a 
> Windows drive doesn't work because the length of the path exceeds the 255 
> character limit.
> {noformat}
> svn: Can't open file 
> 'core-integration-tests\src\test\resources\mng-3341-metadataUpdatedFromDeploymentRepository\deployment-repository\org\apache\maven\its\mng3341\test-artifact\1.0-SNAPSHOT\.svn\tmp\text-base\test-artifact-1.0-20080306.011328-1.pom.md5.svn-base'
> {noformat}
> Please make the path shorter.

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