[jira] Commented: (MSITE-30) site:deploy incompatibilities with m1.02

2008-09-08 Thread Paul Spencer (JIRA)

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

Paul Spencer commented on MSITE-30:
---

Yes.

Paul Spencer

> site:deploy incompatibilities with m1.02
> 
>
> Key: MSITE-30
> URL: http://jira.codehaus.org/browse/MSITE-30
> Project: Maven 2.x Site Plugin
>  Issue Type: Improvement
>  Components: site:deploy
> Environment: All
>Reporter: Paul Spencer
> Fix For: 2.0-beta-8
>
>
> Deploying a site in m2 has changed since m1. 
> 1)  m1 used the "tar" and "gunzip" command on the remote site, where m2 uses 
> the "unzip" command. This poses a problem for be since my remote site does 
> not support the  "unzip" command, thus making the "priority" of this issue 
> major
> 1.1)  Their may be desire to deploy without the use of tools like tar and zip 
> on some site. The deploy would esentailly be a recersive copy
> 2) No equivelent to m1 property maven.site.chmod.mode.  I use this to allow 
> other member is the group update and delete permission
> 3) No equivelent to m1 property maven.site.publish.clean
> Their are other properties for  the m1.02 not mentioned above, but I suspect 
> the they can be calculated from m2 files, i.e. pom.xml and settings.xml.
> Paul Spencer

-- 
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-30) site:deploy incompatibilities with m1.02

2008-09-08 Thread Paul Spencer (JIRA)

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

Paul Spencer commented on MSITE-30:
---

Dennis,
I object to this issue be downgraded from a BUG since the desired behavior 
worked in a prior version of the plugin.

Although have installed unzip on my HP-UX box to get around the problem  #1 of 
the issue, I continue to have an issues with the chmod command. 

Paul Spencer

> site:deploy incompatibilities with m1.02
> 
>
> Key: MSITE-30
> URL: http://jira.codehaus.org/browse/MSITE-30
> Project: Maven 2.x Site Plugin
>  Issue Type: Improvement
>  Components: site:deploy
> Environment: All
>Reporter: Paul Spencer
> Fix For: 2.0-beta-8
>
>
> Deploying a site in m2 has changed since m1. 
> 1)  m1 used the "tar" and "gunzip" command on the remote site, where m2 uses 
> the "unzip" command. This poses a problem for be since my remote site does 
> not support the  "unzip" command, thus making the "priority" of this issue 
> major
> 1.1)  Their may be desire to deploy without the use of tools like tar and zip 
> on some site. The deploy would esentailly be a recersive copy
> 2) No equivelent to m1 property maven.site.chmod.mode.  I use this to allow 
> other member is the group update and delete permission
> 3) No equivelent to m1 property maven.site.publish.clean
> Their are other properties for  the m1.02 not mentioned above, but I suspect 
> the they can be calculated from m2 files, i.e. pom.xml and settings.xml.
> Paul Spencer

-- 
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-339) site:deploy fails on HP-UX due to invalid chmod option

2008-06-20 Thread Paul Spencer (JIRA)

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

Paul Spencer commented on MSITE-339:


Lukas,
Yes, this issues does not exist in Maven 1.  The plugin was rewritten in Maven 
2 and some of the configuration options that existed in the Maven 1 plugin 
where removed and replaced with hard coded values.  This is one example.

Paul Spencer

> site:deploy fails on HP-UX due to invalid chmod option
> --
>
> Key: MSITE-339
> URL: http://jira.codehaus.org/browse/MSITE-339
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 2.0-beta-6
> Environment: HP-UX v11.33 or HP-UX 11.11
>Reporter: Paul Spencer
>
> Deploying a site to an HP server running HP-UX version 11i Release 3 or 
> Release 1 fails because the chmod does not support the "f" option.
> {code}
> ###
> Transfer finished. 108804 bytes copied in 0.141 seconds
> Executing command: cd /internal/geotab-webapp/1.0.2-SNAPSHOT/.; unzip -q -o 
> wagon13079.zip; rm -f wagon1
> Executing command: chmod -Rf g+w,a+rX /internal/geotab-webapp/1.0.2-SNAPSHOT
> scp://projects.foo.com/internal/geotab-webapp/1.0.2-SNAPSHOT - Session: 
> Disconnecting
> scp://projects.foo.com/internal/geotab-webapp/1.0.2-SNAPSHOT - Session: 
> Disconnected
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error uploading site
> Embedded error: Exit code: 255 - chmod: invalid mode
> [INFO] 
> 
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading 
> site
> at 
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:216)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> ... 16 more
> Caused by: org.apache.maven.wagon.CommandExecutionException: Exit code: 255 - 
> chmod: invalid mode
> at 
> org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.executeCommand(AbstractJschWagon.java:237)
> at 
> org.apache.maven.wagon.providers.ssh.AbstractSshWagon.executeCommand(AbstractSshWagon.java:239)
> at 
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:191)
> ... 18 more
> [INFO] 
> 
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Thu Jun 19 12:25:05 EDT 2008
> [INFO] Final Memory: 6M/11M
> [INFO] 
> 
> {code}

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

[jira] Created: (MSITE-339) site:deploy fails on HP-UX due to invalid chmod option

2008-06-19 Thread Paul Spencer (JIRA)
site:deploy fails on HP-UX due to invalid chmod option
--

 Key: MSITE-339
 URL: http://jira.codehaus.org/browse/MSITE-339
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 2.0-beta-6
 Environment: HP-UX v11.33 or HP-UX 11.11
Reporter: Paul Spencer


Deploying a site to an HP server running HP-UX version 11i Release 3 or Release 
1 fails because the chmod does not support the "f" option.

{code}
###
Transfer finished. 108804 bytes copied in 0.141 seconds
Executing command: cd /internal/geotab-webapp/1.0.2-SNAPSHOT/.; unzip -q -o 
wagon13079.zip; rm -f wagon1
Executing command: chmod -Rf g+w,a+rX /internal/geotab-webapp/1.0.2-SNAPSHOT
scp://projects.foo.com/internal/geotab-webapp/1.0.2-SNAPSHOT - Session: 
Disconnecting
scp://projects.foo.com/internal/geotab-webapp/1.0.2-SNAPSHOT - Session: 
Disconnected
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error uploading site

Embedded error: Exit code: 255 - chmod: invalid mode

[INFO] 
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading site
at 
org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:216)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
... 16 more
Caused by: org.apache.maven.wagon.CommandExecutionException: Exit code: 255 - 
chmod: invalid mode

at 
org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.executeCommand(AbstractJschWagon.java:237)
at 
org.apache.maven.wagon.providers.ssh.AbstractSshWagon.executeCommand(AbstractSshWagon.java:239)
at 
org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:191)
... 18 more
[INFO] 
[INFO] Total time: 7 seconds
[INFO] Finished at: Thu Jun 19 12:25:05 EDT 2008
[INFO] Final Memory: 6M/11M
[INFO] 
{code}

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




[jira] Commented: (MSITE-330) Wagon nukes the permission bits of uploaded files.

2008-06-19 Thread Paul Spencer (JIRA)

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

Paul Spencer commented on MSITE-330:


1) The command "chmod -Rf g+w,a+rX" fails on HP-UX servers because "f", which 
is for silent output,  is not an option. 

2)  I would prefer the file permissions, directory permissions, and chmod 
options be in the  tag since the values are 
specific to the server.  Each user should not have different values for the 
tags.

{code:xml|title=pom.xml}

  ...
  

  projects.foo.com
Foo.Com Project Site

scp://projectsfoo.com/${project.artifactId}/${project.version}
775
664
 
 
  


{code}





> Wagon nukes the permission bits of uploaded files.
> --
>
> Key: MSITE-330
> URL: http://jira.codehaus.org/browse/MSITE-330
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Reporter: Henning Schmiedehausen
>
> Uploading a site using wagon might nuke permission bits of e.g. CGI scripts 
> thus making these unavailable. 
> For Apache webserver, a CGI script can have the permission bit set and is 
> then executed. This is e.g. used for the "download.cgi" script on many Apache 
> project sites. 
> The wagon uploader (at least ssh and ssh-external) unconditionally change the 
> permissions of all files to be 664. Which kills the execution bits. Which is 
> bad (TM).

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




[jira] Created: (MSITE-338) URLs in site.xml banner tags not rendered by site plugin if host not resolved by "nslookup"

2008-06-19 Thread Paul Spencer (JIRA)
URLs in site.xml banner tags not rendered by site plugin if host not resolved 
by "nslookup"
---

 Key: MSITE-338
 URL: http://jira.codehaus.org/browse/MSITE-338
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-6
Reporter: Paul Spencer


Absolute URL's in the banner tags of site.xml are translated to relative URLs 
by the maven-site-plugin when the hostname is not found by nslookup.  In my 
case the hostname only exists in my hosts files on a the Windows machine 
running "mvn site".

In the example below, the generated URLs for bannerLeft will be absolute and 
the URL's for bannerRight will be relative.  Adding "badhost.apache.org" to the 
hosts file will not change the outcome.



  
Maven
http://maven.apache.org/images/apache-maven-project.png
http://maven.apache.org/
  
  
Maven
http://badhost.apache.org/images/apache-maven-project.png
http://badhost.apache.org/
  


It appears the plugin is validating the hostname.  Is their a way of turning 
this validation off?


-- 
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: (MSKINS-4) maven-application-skin does not work in IE7

2008-06-17 Thread Paul Spencer (JIRA)
maven-application-skin does not work in IE7
---

 Key: MSKINS-4
 URL: http://jira.codehaus.org/browse/MSKINS-4
 Project: Maven Skins
  Issue Type: Bug
  Components: Application Skin
Reporter: Paul Spencer


Revision 440343 of maven-theme.css in maven-application-skin undid revision 
430364 - "fix the CSS so that it renders correctly in IE7 and Opera."

Basically the height for #navcolumn li.expanded should be auto.

#navcolumn li.expanded {
background-image: url( ../images/super.gif );
height: auto;
}

Note: The Archiva and Continuum projects may use this skin.


[1]http://svn.apache.org/viewvc/maven/skins/trunk/maven-application-skin/src/main/resources/css/maven-theme.css?r1=430364&r2=440343&diff_format=h


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




[jira] Created: (MPH-36) List of plugins used by a POM

2008-03-24 Thread Paul Spencer (JIRA)
List of plugins used by a POM
-

 Key: MPH-36
 URL: http://jira.codehaus.org/browse/MPH-36
 Project: Maven 2.x Help Plugin
  Issue Type: Improvement
Reporter: Paul Spencer


I would like to get an inventory of plugins used by my POM for the purpose of 
explicitly setting their version in my POM.  This will make builds much more 
reliable.  The help:describe can do this for one plugin at a time, but this is 
tedious and makes the incorrect assumption I know all of the plugins used.

A command like the following would produce a list of plugins, including the 
GroupId, ArtifactId, and version used by a specific goal.
  mvn help:describe -Dgoal=test

Going a step further, adding a -DupdatePom=true to actually add the plugin 
information to the POM wound make the process much easier.


-- 
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: (MEV-565) commons-lang is missing versions greater then 2.1 in the metadata.

2007-12-26 Thread Paul Spencer (JIRA)

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

Paul Spencer reopened MEV-565:
--


I am getting the following error when using a dependency that is dependent on 
commons-lang version [2.2,)

[DEBUG] commons-lang: using locally installed snapshot
[DEBUG] Unable to determine the release version

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=commons-lang -DartifactId=commons-lang \
-Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file

Path to dependency:
1) com.mikon.customer.kc:apms-reporting-jsf:war:1.0.6-SNAPSHOT
2) org.apache.myfaces.core:myfaces-api:jar:1.1.5
3) commons-lang:commons-lang:jar:RELEASE


  commons-lang:commons-lang:jar:RELEASE

Is maven-metadata.xml missing the release tag?

  ...
  
 2.3
 
...

  ...

> commons-lang is missing versions greater then 2.1 in the metadata.
> --
>
> Key: MEV-565
> URL: http://jira.codehaus.org/browse/MEV-565
> Project: Maven Evangelism
>  Issue Type: Bug
>  Components: Invalid Metadata
>Reporter: Paul Spencer
>Assignee: Carlos Sanchez
>
> Versions > 2.1 are missing from the metadata.  This is preventing version 
> range like  [2.2,) from working,

-- 
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: (MEV-565) commons-lang is missing versions greater then 2.1 in the metadata.

2007-12-21 Thread Paul Spencer (JIRA)
commons-lang is missing versions greater then 2.1 in the metadata.
--

 Key: MEV-565
 URL: http://jira.codehaus.org/browse/MEV-565
 Project: Maven Evangelism
  Issue Type: Bug
  Components: Invalid Metadata
Reporter: Paul Spencer


Versions > 2.1 are missing from the metadata.  This is preventing version range 
like  [2.2,) from working,

-- 
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: (MCHANGES-82) Issue Management URL not ending in a '/' result in an incorrect issue link on the change report.

2007-07-16 Thread Paul Spencer (JIRA)

[ 
http://jira.codehaus.org/browse/MCHANGES-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102382
 ] 

Paul Spencer commented on MCHANGES-82:
--


> Are you using a changes.xml file to produce the report? 
Yes, I am using changes.xml

> What does it look like?
 


  
Changes
  
  

  
Selected list will not change as when group
changes.
  

 


> How is this problem made worse by the example that you mention?
It is documenting how to experience this issue.  
Please note: I have no reason to believe the example is incorrect.  I believe 
the issue is in the changes plugin and it's usage of the URL.


> Can you please supply a full issue management element that exemplifies this 
> issue.
The following will produce an incorrect URL in the changes report
 
Bugzilla
http://127.0.0.1/bugzilla
  

The following will produce the correct URL in the changes report
 
Bugzilla
http://127.0.0.1/bugzilla/
  

> Issue Management URL not ending in a '/' result in an incorrect issue link on 
> the change report.
> 
>
> Key: MCHANGES-82
> URL: http://jira.codehaus.org/browse/MCHANGES-82
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: changes-report
>Affects Versions: 2.0-beta-2
>Reporter: Paul Spencer
>
> Issue Management URL not ending in a '/' result in an incorrect issue link on 
> the change report.  If the Url is "http://issues.foo.com";, then the link to 
> issue 1 is "http://ViewIssue.jspa?key=1";.  This problem is made worse by the 
> issue management example in http://maven.apache.org/pom.html.  In that 
> example the url is http://127.0.0.1/bugzilla.
> I believe the source of the problem is in 
> ChangesReportGenerator.parseIssueLink().  This method assumes the URL will 
> end in a "/", instead of checking for an ending "/"
>String url = this.url.substring( 0, this.url.lastIndexOf( "/" ) );

-- 
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: (MCHANGES-82) Issue Management URL not ending in a '/' result in an incorrect issue link on the change report.

2007-07-11 Thread Paul Spencer (JIRA)
Issue Management URL not ending in a '/' result in an incorrect issue link on 
the change report.


 Key: MCHANGES-82
 URL: http://jira.codehaus.org/browse/MCHANGES-82
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: changes-report
Affects Versions: 2.0-beta-2
Reporter: Paul Spencer


Issue Management URL not ending in a '/' result in an incorrect issue link on 
the change report.  If the Url is "http://issues.foo.com";, then the link to 
issue 1 is "http://ViewIssue.jspa?key=1";.  This problem is made worse by the 
issue management example in http://maven.apache.org/pom.html.  In that example 
the url is http://127.0.0.1/bugzilla.

I believe the source of the problem is in 
ChangesReportGenerator.parseIssueLink().  This method assumes the URL will end 
in a "/", instead of checking for an ending "/"
   String url = this.url.substring( 0, this.url.lastIndexOf( "/" ) );



-- 
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-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.

2007-06-27 Thread Paul Spencer (JIRA)

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

Paul Spencer commented on MNG-3075:
---

The  tag also has the problem.

   ...
  
http://developer.foo.com/projects/${project.artifactId}/${project.version}
  
   ...




> Project properties, project.artifactId and project.version, are incorrectly 
> translated when use defined in a parent POM.
> 
>
> Key: MNG-3075
> URL: http://jira.codehaus.org/browse/MNG-3075
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.6, 2.0.7
>Reporter: Paul Spencer
> Attachments: pom.xml, pom.xml, pom.xml
>
>
> I have defined the  and  tags in a parent POM.  
> The definitions in the parent POM use ${project.artifactId} and 
> ${project.version}.  The problem is the resulting POM has incorrect tags.
> As an example: When the master POM contains the following configuration, the 
> distribution site url for the "bad-effective-pom" project is 
> scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
>   
> 
>   foo-project-site
>   Project Site
>   
> scp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}
> 
>   
> As the level of POM inheritance increases, so do the problem.
> A test case will be attached to 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] Commented: (MNG-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.

2007-06-27 Thread Paul Spencer (JIRA)

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

Paul Spencer commented on MNG-3075:
---

I should have mentioned, the expected  distribution site url in the example is  
scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT

> Project properties, project.artifactId and project.version, are incorrectly 
> translated when use defined in a parent POM.
> 
>
> Key: MNG-3075
> URL: http://jira.codehaus.org/browse/MNG-3075
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.6, 2.0.7
>Reporter: Paul Spencer
> Attachments: pom.xml, pom.xml, pom.xml
>
>
> I have defined the  and  tags in a parent POM.  
> The definitions in the parent POM use ${project.artifactId} and 
> ${project.version}.  The problem is the resulting POM has incorrect tags.
> As an example: When the master POM contains the following configuration, the 
> distribution site url for the "bad-effective-pom" project is 
> scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
>   
> 
>   foo-project-site
>   Project Site
>   
> scp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}
> 
>   
> As the level of POM inheritance increases, so do the problem.
> A test case will be attached to 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: (MNG-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.

2007-06-27 Thread Paul Spencer (JIRA)

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

Paul Spencer updated MNG-3075:
--

Attachment: pom.xml

This POM set it's own SCM and Distribution Management configuration

> Project properties, project.artifactId and project.version, are incorrectly 
> translated when use defined in a parent POM.
> 
>
> Key: MNG-3075
> URL: http://jira.codehaus.org/browse/MNG-3075
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.6, 2.0.7
>Reporter: Paul Spencer
> Attachments: pom.xml, pom.xml, pom.xml
>
>
> I have defined the  and  tags in a parent POM.  
> The definitions in the parent POM use ${project.artifactId} and 
> ${project.version}.  The problem is the resulting POM has incorrect tags.
> As an example: When the master POM contains the following configuration, the 
> distribution site url for the "bad-effective-pom" project is 
> scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
>   
> 
>   foo-project-site
>   Project Site
>   
> scp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}
> 
>   
> As the level of POM inheritance increases, so do the problem.
> A test case will be attached to 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: (MNG-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.

2007-06-27 Thread Paul Spencer (JIRA)

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

Paul Spencer updated MNG-3075:
--

Attachment: pom.xml

This pom inherits the SCM and Distribution Management configuration from the 
parent POM. 

> Project properties, project.artifactId and project.version, are incorrectly 
> translated when use defined in a parent POM.
> 
>
> Key: MNG-3075
> URL: http://jira.codehaus.org/browse/MNG-3075
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.6, 2.0.7
>Reporter: Paul Spencer
> Attachments: pom.xml, pom.xml, pom.xml
>
>
> I have defined the  and  tags in a parent POM.  
> The definitions in the parent POM use ${project.artifactId} and 
> ${project.version}.  The problem is the resulting POM has incorrect tags.
> As an example: When the master POM contains the following configuration, the 
> distribution site url for the "bad-effective-pom" project is 
> scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
>   
> 
>   foo-project-site
>   Project Site
>   
> scp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}
> 
>   
> As the level of POM inheritance increases, so do the problem.
> A test case will be attached to 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: (MNG-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.

2007-06-27 Thread Paul Spencer (JIRA)

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

Paul Spencer updated MNG-3075:
--

Attachment: pom.xml

Parent POM

> Project properties, project.artifactId and project.version, are incorrectly 
> translated when use defined in a parent POM.
> 
>
> Key: MNG-3075
> URL: http://jira.codehaus.org/browse/MNG-3075
> Project: Maven 2
>  Issue Type: Bug
>Affects Versions: 2.0.6, 2.0.7
>Reporter: Paul Spencer
> Attachments: pom.xml, pom.xml, pom.xml
>
>
> I have defined the  and  tags in a parent POM.  
> The definitions in the parent POM use ${project.artifactId} and 
> ${project.version}.  The problem is the resulting POM has incorrect tags.
> As an example: When the master POM contains the following configuration, the 
> distribution site url for the "bad-effective-pom" project is 
> scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom
>   
> 
>   foo-project-site
>   Project Site
>   
> scp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}
> 
>   
> As the level of POM inheritance increases, so do the problem.
> A test case will be attached to this issue.

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




[jira] Created: (MNG-3075) Project properties, project.artifactId and project.version, are incorrectly translated when use defined in a parent POM.

2007-06-27 Thread Paul Spencer (JIRA)
Project properties, project.artifactId and project.version, are incorrectly 
translated when use defined in a parent POM.


 Key: MNG-3075
 URL: http://jira.codehaus.org/browse/MNG-3075
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.7, 2.0.6
Reporter: Paul Spencer


I have defined the  and  tags in a parent POM.  
The definitions in the parent POM use ${project.artifactId} and 
${project.version}.  The problem is the resulting POM has incorrect tags.

As an example: When the master POM contains the following configuration, the 
distribution site url for the "bad-effective-pom" project is 
scp://developer.foo.com/developer-foo-com/projects/bad-effective-pom/1.0-SNAPSHOT/bad-effective-pom

  

  foo-project-site
  Project Site
  
scp://developer.foo.com/developer-foo-com/projects/${project.artifactId}/${project.version}

  

As the level of POM inheritance increases, so do the problem.
A test case will be attached to 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] Commented: (MECLIPSE-165) Ability to exclude filtered resources from eclipse's source directories

2007-06-22 Thread Paul Spencer (JIRA)

[ 
http://jira.codehaus.org/browse/MECLIPSE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100364
 ] 

Paul Spencer commented on MECLIPSE-165:
---

I have mentioned this issue in a post on Maven's users mailing list. The post 
is titled "I use resource filtering with the Eclipse plugin but, need filtered 
directories excluded."  Basically I am asking for the ability to exclude 
filtered resources from the eclipse classpath.

Paul Spencer

> Ability to exclude filtered resources from eclipse's source directories
> ---
>
> Key: MECLIPSE-165
> URL: http://jira.codehaus.org/browse/MECLIPSE-165
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>  Components: PDE support
>Affects Versions: 2.3
>Reporter: Cédric Vidal
> Attachments: MECLIPSE-165.patch
>
>
> Resources should be in the classpath from Eclipse's point of view because 
> they end up being in the classpath from Maven 2's point of view, but whenever 
> resources are marked as being filtered by M2, Eclipse puts them unfiltered in 
> the classpath thus introducing an inconsistency between Maven 2 and Eclipse.
> Whether or not to include filtered resource directories in eclipse's sources 
> directories is therefore a real dilemna. While I'm sure a consistent solution 
> to this dilemna will eventually be found, it would be great to let the user 
> choose what to do in the meantime.
> The attached patch adresses this issue by adding a parameter, 
> 'excludeFilteredResourcesFromSourceDirs', which when set to true prevents 
> filtered resource directories from being added to eclipse's source 
> directories. The parameter defaults to false to avoid changing current 
> projects' behavior.
> Regards,
> Cédric Vidal
> http://www.B-Process.com
> PS: This parameter could be overriden on a per resource directory basis as 
> mentionned in MECLIPSE-162. This is not adressed by the attached patch though

-- 
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-3034) Import a profile into a POM

2007-06-05 Thread Paul Spencer (JIRA)

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

Paul Spencer commented on MNG-3034:
---

Jason,
This is a request for improvement.  The "problem" is that I am having to cut 
and paste one profile to many poms and then maintain each copy.  By adding a 
way to importing a profile, only one copy of the profile needs to be 
maintained.  Because the imported profile is in POM which is in the repository, 
reproducibility of the build is maintained be default.

Paul Spencer



> Import a profile into a POM
> ---
>
> Key: MNG-3034
> URL: http://jira.codehaus.org/browse/MNG-3034
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Profiles
>Affects Versions: 2.0.6
>Reporter: Paul Spencer
>
> I am finding that profiles are very powerful. As I make more use of them 
> across projects, many of which are unrelated, I find myself copying a profile 
> from one POM to another. Placing profiles in a POM the is extended is 
> impractical because each change to a profile in the POM will prompt a release 
> cycle of the POM and every project that extends the POM.
> Related thread:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg67252.html
> Below is how I would expect to use profile importing.
> ***
> * POM of project which imports the profiles cargo_tomcat_remote and
> * cargo_jetty_remote and selenium-integration-test.
> ***
> 
>   ...
>   com.foo.applications
>   webapp_1
>   ...
>   
> 
>   cargo_tomcat_remote
>   com.foo.profiles
>   cargo
>   1.0
>   
> ...
>   
> 
> 
>   cargo_jetty_remote
>   com.foo.profiles
>   cargo
>   1.0
>   
>   ...
> 
> 
>   selenium-integration-test
>   com.foo.profiles
>   selenium
>   1.0
>   
>   ...
> 
> 
> ***
> * POM of project which defines 2 profiles, cargo_tomcat_remote and
> * cargo_jetty_remote.
> ***
> 
>   ...
>   com.foo.profiles
>   cargo
>   1.0
>   ...
>   
> 
>   cargo_tomcat_remote
> ...
> 
> 
>   cargo_jetty_remote
>   
> ...
>   
> 
> 
> Paul Spencer

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




[jira] Created: (MNG-3034) Import a profile into a POM

2007-06-04 Thread Paul Spencer (JIRA)
Import a profile into a POM
---

 Key: MNG-3034
 URL: http://jira.codehaus.org/browse/MNG-3034
 Project: Maven 2
  Issue Type: Improvement
  Components: Profiles
Affects Versions: 2.0.6
Reporter: Paul Spencer


I am finding that profiles are very powerful. As I make more use of them across 
projects, many of which are unrelated, I find myself copying a profile from one 
POM to another. Placing profiles in a POM the is extended is impractical 
because each change to a profile in the POM will prompt a release cycle of the 
POM and every project that extends the POM.

Related thread:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg67252.html

Below is how I would expect to use profile importing.

***
* POM of project which imports the profiles cargo_tomcat_remote and
* cargo_jetty_remote and selenium-integration-test.
***

  ...
  com.foo.applications
  webapp_1
  ...
  

  cargo_tomcat_remote
  com.foo.profiles
  cargo
  1.0
  
...
  


  cargo_jetty_remote
  com.foo.profiles
  cargo
  1.0
  
  ...


  selenium-integration-test
  com.foo.profiles
  selenium
  1.0
  
  ...



***
* POM of project which defines 2 profiles, cargo_tomcat_remote and
* cargo_jetty_remote.
***

  ...
  com.foo.profiles
  cargo
  1.0
  ...
  

  cargo_tomcat_remote
...


  cargo_jetty_remote
  
...
  




Paul Spencer


-- 
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: (MECLIPSE-269) "Can't canonicalize system path" error using the goal eclispse:eclipse

2007-05-21 Thread Paul Spencer (JIRA)
"Can't canonicalize system path" error using the goal eclispse:eclipse
--

 Key: MECLIPSE-269
 URL: http://jira.codehaus.org/browse/MECLIPSE-269
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: maven-eclipse-plugin version 2.3
maven-war-plugin version 2.0.2 
Reporter: Paul Spencer
Priority: Minor


I get a "Can't canonicalize system path" error using the goal eclispse:eclipse 
when
the  of the maven-war-plugin starts with ${basedir}. If I 
remove the
${basedir}, the build is successful.

If, as it appears, the war plugin uses different rules related to the prefixing 
a path with ${basedir}, then I consider it a bug because the configuration of 
 is inconsistant with similar tags.

Per Wayne Fay, I have log this issue against the Eclipse plugin. 

[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Can't canonicalize system path: 
C:\cvs_apms\ipim-webapp\C:\cvs_apms\ipim-webapp\src\webapp

Embedded error: The filename, directory name, or volume label syntax is 
incorrect
[INFO] 
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Can't canonicalize 
system path: C:\cvs_apms\ipim-webapp\C:\cvs_apms\ipim-webapp\src\webapp
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
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:278)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Can't canonicalize 
system path: C:\cvs_apms\ipim-webapp\C:\cvs_apms\ipim-webapp\src\webapp
at 
org.apache.maven.plugin.ide.IdeUtils.getCanonicalPath(IdeUtils.java:77)
at 
org.apache.maven.plugin.ide.IdeUtils.toRelativeAndFixSeparator(IdeUtils.java:89)
at 
org.apache.maven.plugin.eclipse.writers.EclipseWtpComponentWriter.writeModuleTypeComponent(EclipseWtpComponentWriter.java:142)
at 
org.apache.maven.plugin.eclipse.writers.EclipseWtpComponentWriter.write(EclipseWtpComponentWriter.java:97)
at 
org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:671)
at 
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:402)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
Caused by: java.io.IOException: The filename, directory name, or volume label 
syntax is incorrect
at java.io.WinNTFileSystem.canonicalize0(Native Method)
at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:354)
at java.io.File.getCanonicalPath(File.java:513)
at 
org.apache.maven.plugin.ide.IdeUtils.getCanonicalPath(IdeUtils.java:73)
... 23 more
[INFO] 

Paul Spencer


-- 
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: (CONTINUUM-1279) Need to add "Build Information" to the build result reports and notification.

2007-05-19 Thread Paul Spencer (JIRA)
Need to add "Build Information" to the build result reports and notification.
-

 Key: CONTINUUM-1279
 URL: http://jira.codehaus.org/browse/CONTINUUM-1279
 Project: Continuum
  Issue Type: Improvement
  Components: Notification Subsystem, Web - Configuration
Affects Versions: 1.1-alpha-1
Reporter: Paul Spencer


Need to add "Build Information" to the build result reports and notification.  
The "Build Information" should include the goals, arguments, name*, and 
description* because these affects the how the project is built.  Currently the 
user can not determine the build configuration from the Results report or a 
Notification.


* See CONTINUUM-1278 for information on the Name and Description information.

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




[jira] Created: (CONTINUUM-1278) Need to add description and/or name to build defintion

2007-05-19 Thread Paul Spencer (JIRA)
Need to add description and/or name to build defintion
--

 Key: CONTINUUM-1278
 URL: http://jira.codehaus.org/browse/CONTINUUM-1278
 Project: Continuum
  Issue Type: Improvement
Affects Versions: 1.1-alpha-1
Reporter: Paul Spencer


When their are several "Build definition"s for a project, it can be difficult 
to know why each exists.  This can be eliminated by adding an name and/or 
description of the "Build Definition".  The name and description must be 
optional, or at least defaultes, to minimize the effort required when adding a 
project or build.

As an example the MyFaces Tomahawk project has many "Build Definition" for some 
of their projects.  In those cases each "Build Definition" builds against a 
different implementation of the JSF standard.  

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




[jira] Created: (MNG-2984) Allow more control around the configuration and use of optional dependencies

2007-05-11 Thread Paul Spencer (JIRA)
Allow more control around the configuration and use of optional dependencies


 Key: MNG-2984
 URL: http://jira.codehaus.org/browse/MNG-2984
 Project: Maven 2
  Issue Type: Improvement
  Components: Dependencies
Affects Versions: 2.0.6
Reporter: Paul Spencer


This request is based on the following posting to the users mailing list.

How can I include a dependency's optional dependency without
adding the optional dependency to the pom?

As an example, shale-test has an optional dependency on commons-digester.  Since
my application does not use commons-digester, I do not have it defined as
a dependency in the pom.  When the test that used shale-test failed I had to
determine the failure was due to a missing dependency that was defined in 
shale-test's
pom. Thus the following questions.

1) Is their a way I can include all of a dependencies optional dependencies
   without knowing what they are?

  
org.apache.shale
shale-test
1.1.0-SNAPSHOT
test
  
  


2) Is their a way I can include selected optional dependencies for a dependency?

  
org.apache.shale
shale-test
1.1.0-SNAPSHOT
test
  
  
commons-digester
commons-digester
  

  

3) Can optional dependencies be grouped to allow for the inclusion of a
   named group of optional dependencies, thus freeing the user from
   having to know and maintain a list of optional dependencies to
   include?

  
org.apache.shale
shale-test
1.1.0-SNAPSHOT
test
  
  



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




[jira] Created: (MCHANGES-77) Document the variables available to the announcement template.

2007-04-20 Thread Paul Spencer (JIRA)
Document the variables available to the announcement template.
--

 Key: MCHANGES-77
 URL: http://jira.codehaus.org/browse/MCHANGES-77
 Project: Maven 2.x Changes Plugin
  Issue Type: Improvement
Affects Versions: 2.0-beta-3
Reporter: Paul Spencer


 Document the variables available to the announcement template. 

The list currently includes:
   releases
   groupId
   artifactId
   version
   packaging
   url
   introduction
   developmentTeam
   finalName
   urlDownload


-- 
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: (CONTINUUM-705) HTTP Error 503 java%2Elang%2EClassNotFoundException%3A+file%3D16 when displaying page containing frames, i.e. javadocs

2006-05-23 Thread Paul Spencer (JIRA)
HTTP Error 503 java%2Elang%2EClassNotFoundException%3A+file%3D16 when 
displaying page containing frames, i.e. javadocs
--

 Key: CONTINUUM-705
 URL: http://jira.codehaus.org/browse/CONTINUUM-705
 Project: Continuum
Type: Bug

  Components: Web interface  
Versions: 1.0.3
 Environment: Windows XP
Reporter: Paul Spencer


The following is displayed in all 3 frames when displaying the javadocs from 
the maven 2 generated site in the "working directory"

HTTP ERROR: 503 java%2Elang%2EClassNotFoundException%3A+file%3D16

RequestURI=/continuum/servlet/file=16/target/site/apidocs/index.html

Powered by Jetty://

-- 
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-119) Release plugin is not updating changes.xml like it did in m1

2006-05-23 Thread Paul Spencer (JIRA)
Release plugin is not updating changes.xml like it did in m1


 Key: MRELEASE-119
 URL: http://jira.codehaus.org/browse/MRELEASE-119
 Project: Maven 2.x Release Plugin
Type: Bug

Versions: 2.0-beta-4
Reporter: Paul Spencer


The release plugin in m1 updated the version and date attributes of the release 
tag. It is not doing this in m2

Has this functionality been removed in M2?


-- 
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: (CONTINUUM-704) Make columns on the project summary page sortable.

2006-05-19 Thread Paul Spencer (JIRA)
Make columns on the project summary page sortable.
--

 Key: CONTINUUM-704
 URL: http://jira.codehaus.org/browse/CONTINUUM-704
 Project: Continuum
Type: Improvement

  Components: Web interface  
Reporter: Paul Spencer


Making the columns on the Project Summary page sortable would be  very useful.  
As an example you could sort by build status, which is the first column of 
icons, to see all of the failed builds group together.  I added an issue 
requesting the addition of build date column.  Sorting by this column will 
allow the user to see the order projects where build.

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



[jira] Created: (CONTINUUM-703) Display of last build date on Project Summary page

2006-05-19 Thread Paul Spencer (JIRA)
Display of last build date on Project Summary page
--

 Key: CONTINUUM-703
 URL: http://jira.codehaus.org/browse/CONTINUUM-703
 Project: Continuum
Type: Improvement

  Components: Web interface  
Reporter: Paul Spencer


Adding the date of the last build to the Project Summary pages would be very 
useful.  At the very least the user can tell how log it has been since a build 
was attempted for a project without having to view the builds history.

-- 
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: (MRELEASE-114) ${project.artifactId} was replaced with it's value during release:perform

2006-05-19 Thread Paul Spencer (JIRA)
[ http://jira.codehaus.org/browse/MRELEASE-114?page=comments#action_65623 ] 

Paul Spencer commented on MRELEASE-114:
---

The  tag inside the  tag is also affected by this bug.

> ${project.artifactId} was replaced with it's value during release:perform
> -
>
>  Key: MRELEASE-114
>  URL: http://jira.codehaus.org/browse/MRELEASE-114
>  Project: Maven 2.x Release Plugin
> Type: Bug

>  Environment: Windows XP, Java 1.4.2
> Reporter: Paul Spencer

>
>
> In release:perform, the variable ${project.artifactId} was replaced with it's 
> value in the connection and developerConnection tags in the pom. This did NOT 
> happen in other place in the pom!
> Before release:
> scm:cvs:pserver:[EMAIL 
> PROTECTED]:/bar:${project.artifactId}
> After release:
> scm:cvs:pserver:[EMAIL PROTECTED]:/bar:master-pom
> BTW: The issue http://jira.codehaus.org/browse/MRELEASE-16 may be
>  related to the above 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] Commented: (MRELEASE-114) ${project.artifactId} was replaced with it's value during release:perform

2006-05-19 Thread Paul Spencer (JIRA)
[ http://jira.codehaus.org/browse/MRELEASE-114?page=comments#action_65622 ] 

Paul Spencer commented on MRELEASE-114:
---

Fogot to set affected version to Release plugin 2.0-beta-4 

> ${project.artifactId} was replaced with it's value during release:perform
> -
>
>  Key: MRELEASE-114
>  URL: http://jira.codehaus.org/browse/MRELEASE-114
>  Project: Maven 2.x Release Plugin
> Type: Bug

>  Environment: Windows XP, Java 1.4.2
> Reporter: Paul Spencer

>
>
> In release:perform, the variable ${project.artifactId} was replaced with it's 
> value in the connection and developerConnection tags in the pom. This did NOT 
> happen in other place in the pom!
> Before release:
> scm:cvs:pserver:[EMAIL 
> PROTECTED]:/bar:${project.artifactId}
> After release:
> scm:cvs:pserver:[EMAIL PROTECTED]:/bar:master-pom
> BTW: The issue http://jira.codehaus.org/browse/MRELEASE-16 may be
>  related to the above 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] Created: (MRELEASE-115) Issue URL on pom is incorrect

2006-05-19 Thread Paul Spencer (JIRA)
Issue URL on pom is incorrect
-

 Key: MRELEASE-115
 URL: http://jira.codehaus.org/browse/MRELEASE-115
 Project: Maven 2.x Release Plugin
Type: Bug

Reporter: Paul Spencer
 Fix For: 2.0-beta-4


The issue URL refers to the wrong JIRA project. 

-- 
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-114) ${project.artifactId} was replaced with it's value during release:perform

2006-05-19 Thread Paul Spencer (JIRA)
${project.artifactId} was replaced with it's value during release:perform
-

 Key: MRELEASE-114
 URL: http://jira.codehaus.org/browse/MRELEASE-114
 Project: Maven 2.x Release Plugin
Type: Bug

 Environment: Windows XP, Java 1.4.2
Reporter: Paul Spencer


In release:perform, the variable ${project.artifactId} was replaced with it's 
value in the connection and developerConnection tags in the pom. This did NOT 
happen in other place in the pom!

Before release:
scm:cvs:pserver:[EMAIL 
PROTECTED]:/bar:${project.artifactId}

After release:
scm:cvs:pserver:[EMAIL PROTECTED]:/bar:master-pom

BTW: The issue http://jira.codehaus.org/browse/MRELEASE-16 may be
 related to the above 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] Commented: (MSITE-30) site:deploy incompatibilities with m1.02

2006-04-11 Thread Paul Spencer (JIRA)
[ http://jira.codehaus.org/browse/MSITE-30?page=comments#action_63309 ] 

Paul Spencer commented on MSITE-30:
---

Is this in part a WAGGON issue since it is in AbstractWaggon.createZip where 
the type compression, either ZIP or GZIP, is set?

A suggestion:
  Allow the plugin/Waggon to determine what is supported on the remote side, 
(zip, gzip, tar,...) and then use what is available.

Paul Spencer

> site:deploy incompatibilities with m1.02
> 
>
>  Key: MSITE-30
>  URL: http://jira.codehaus.org/browse/MSITE-30
>  Project: Maven 2.x Site Plugin
> Type: Bug

>  Environment: All
> Reporter: Paul Spencer
>  Fix For: 2.0

>
>
> Deploying a site in m2 has changed since m1. 
> 1)  m1 used the "tar" and "gunzip" command on the remote site, where m2 uses 
> the "unzip" command. This poses a problem for be since my remote site does 
> not support the  "unzip" command, thus making the "priority" of this issue 
> major
> 1.1)  Their may be desire to deploy without the use of tools like tar and zip 
> on some site. The deploy would esentailly be a recersive copy
> 2) No equivelent to m1 property maven.site.chmod.mode.  I use this to allow 
> other member is the group update and delete permission
> 3) No equivelent to m1 property maven.site.publish.clean
> Their are other properties for  the m1.02 not mentioned above, but I suspect 
> the they can be calculated from m2 files, i.e. pom.xml and settings.xml.
> Paul Spencer

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