[jira] Commented: (MRELEASE-477) Add a commitBeforeTag option for release:prepare to allow skipping scm-commit-release

2009-10-19 Thread Mike Dillon (JIRA) 

[ 
http://jira.codehaus.org/browse/MRELEASE-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195310#action_195310
 ] 

Mike Dillon commented on MRELEASE-477:
--

The release plugin checks out the "tag" that was created and builds it. From 
the perspective of the build, the code that is seen and the fact that it is 
unmodified from the repository is 100% equivalent. It seems like your objection 
is that the "tag" differs from the revision that it was tagged off of in the 
source code line. I can't see how this is an issue for a pre-tagging workflow 
like maven-release-plugin supports.

> Add a commitBeforeTag option for release:prepare to allow skipping 
> scm-commit-release
> -
>
> Key: MRELEASE-477
> URL: http://jira.codehaus.org/browse/MRELEASE-477
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Reporter: Mike Dillon
>
> As detailed in this thread, there can be reproducibility problems with 
> committing to the source branch (e.g. trunk) before tagging:
> http://www.nabble.com/Limitation-of-the-release-plugin--to20822478.html
> In the now default case where remoteTagging is true, the commit to the source 
> branch is necessary to get the source into the right state before doing the 
> remote copy. However, when remoteTagging is false, the extra commit means 
> that between the user's initial checkout and the automatic commit to the 
> source branch, other changes could have been committed which will mean that 
> the new tag will not have been created from a single, consistent revision of 
> the source branch.
> My proposed fix for this is to add a commitBeforeTag option that would cause 
> scm-commit-release to be skipped during release:prepare. It would be an error 
> to have commitBeforeTag=false when remoteTagging=true since the commit before 
> tag must be done in the remote tagging scenario.
> I can provide a patch if this approach is acceptable.

-- 
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-477) Add a commitBeforeTag option for release:prepare to allow skipping scm-commit-release

2009-10-19 Thread Mark Struberg (JIRA) 

[ 
http://jira.codehaus.org/browse/MRELEASE-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195309#action_195309
 ] 

Mark Struberg commented on MRELEASE-477:


Maybe this comment sounds a bit harsh, but I think this may introduce bigger 
problems than having a tag 1 minute before a release got finished (or 
rollbacked). Please consider that any1 is free to tag something in the SCM and 
we are talking about SCMs and not about money transfers on a bank accounting 
system.

Doing a generic commit on the project before doing the tagging feels pretty 
wrong since this surely is a error prone. Just imagine some test will modify a 
local resource (which must not happen). You will never ever recognize that your 
test is modifying the build and thus is not predictable!

I think the fact that SVN allows 'tags on the fly' shows that there is 
something fundamentally wrong with the way SVN evolved the last years!
And we shall not copy bad practice.

> Add a commitBeforeTag option for release:prepare to allow skipping 
> scm-commit-release
> -
>
> Key: MRELEASE-477
> URL: http://jira.codehaus.org/browse/MRELEASE-477
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Reporter: Mike Dillon
>
> As detailed in this thread, there can be reproducibility problems with 
> committing to the source branch (e.g. trunk) before tagging:
> http://www.nabble.com/Limitation-of-the-release-plugin--to20822478.html
> In the now default case where remoteTagging is true, the commit to the source 
> branch is necessary to get the source into the right state before doing the 
> remote copy. However, when remoteTagging is false, the extra commit means 
> that between the user's initial checkout and the automatic commit to the 
> source branch, other changes could have been committed which will mean that 
> the new tag will not have been created from a single, consistent revision of 
> the source branch.
> My proposed fix for this is to add a commitBeforeTag option that would cause 
> scm-commit-release to be skipped during release:prepare. It would be an error 
> to have commitBeforeTag=false when remoteTagging=true since the commit before 
> tag must be done in the remote tagging scenario.
> I can provide a patch if this approach is acceptable.

-- 
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: (MAVENUPLOAD-2613) New Framework for creating WebApplications with AJAX written entirely in Java.

2009-10-19 Thread Carlos Sanchez (JIRA) 

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

Carlos Sanchez closed MAVENUPLOAD-2613.
---

Resolution: Incomplete
  Assignee: Carlos Sanchez

> New Framework for creating WebApplications with AJAX written entirely in Java.
> --
>
> Key: MAVENUPLOAD-2613
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2613
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Martin Hermann
>Assignee: Carlos Sanchez
>
> http://webguitoolkit.googlecode.com/files/webguitoolkit-ui-01.03.00-SNAPSHOT-bundle.jar
> http://webguitoolkit.googlecode.com/files/webguitoolkit-archetype-01.03.00-SNAPSHOT-bundle.jar
> http://code.google.com/p/webguitoolkit/
> http://code.google.com/p/webguitoolkit/people/list
> I'm a developer in WebGuiToolkit (marher74), please upload! 
> We want to use the groupId org.webguitoolkit.ui for both bundles.
> Peter Zaretzke, one of the other developers., owns the domain 
> webguitoolkit.org.
> See: 
> http://reports.internic.net/cgi/whois?whois_nic=webguitoolkit.org&type=domain

-- 
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: (MAVENUPLOAD-2604) Upload JFreeChart 1.0.13 and JCommon 1.0.16 dependent project

2009-10-19 Thread Carlos Sanchez (JIRA) 

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

Carlos Sanchez closed MAVENUPLOAD-2604.
---

Resolution: Incomplete
  Assignee: Carlos Sanchez

> Upload JFreeChart 1.0.13 and JCommon 1.0.16 dependent project
> -
>
> Key: MAVENUPLOAD-2604
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2604
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Javier Moran
>Assignee: Carlos Sanchez
> Attachments: jcommon-1.0.16-bundle.jar, jfreechart-1.0.13-bundle.jar
>
>


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

[jira] Created: (MREACTOR-15) mvn reactor:make-scm-changes doesn't work in windows with subversion

2009-10-19 Thread Roger Pack (JIRA) 
mvn reactor:make-scm-changes doesn't work in windows with subversion


 Key: MREACTOR-15
 URL: http://jira.codehaus.org/browse/MREACTOR-15
 Project: Maven 2.x Reactor Plugin
  Issue Type: Bug
Affects Versions: 1.0
 Environment: windows xp, subversion 1.6.2 command line
Reporter: Roger Pack
Priority: Minor


In my project, if I update a file, call it

root
  /updatemigrationdb
  pom.xml

If I update pom.xml and have uncommitted changes there, in linux I get

[INFO] Reactor Summary:
[INFO] 
[INFO] Migration updatemigrationdb ... SUCCESS [3.741s]
[INFO] Migration TapeWriter .. SUCCESS [4.361s]
[INFO] 
[INFO] 
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 8 seconds
[INFO] Finished at: Mon Oct 19 17:22:49 MDT 2009
[INFO] Final Memory: 43M/731M
[INFO] 
[INFO] 
[INFO] BUILD SUCCESSFUL

however, on windows I get

C:\dev\trunk>mvn reactor:make-scm-changes
...
[INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
[INFO] Working directory: C:\dev\trunk
[INFO] Going to make dependents for:
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] No folders matched:
...

The output of said command line is
C:\dev\trunk>cmd /X /C "svn --non-interactive status"
M   pom.xml
M   updatemigrationdb\pom.xml
(i.e. ?   cmd.exe\nM   pom.xml\nM   updatemigrationdb\\pom.xml\n")

Thanks!
-r

-- 
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-2634) upload new release 1.15 to org.mentaframework

2009-10-19 Thread Fernando Boaglio (JIRA) 
upload new release 1.15 to org.mentaframework
-

 Key: MAVENUPLOAD-2634
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2634
 Project: Maven Upload Requests
  Issue Type: Task
Reporter: Fernando Boaglio


The Mentawai goal is to be a simple, flexible, joyful and productive Java web 
framework. 

This is a new release with a lot of improvements .

TIA 

-- 
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: (SCM-494) Let providers indicate whether a commit is required before a tag

2009-10-19 Thread Mike Dillon (JIRA) 

[ 
http://jira.codehaus.org/browse/SCM-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195259#action_195259
 ] 

Mike Dillon commented on SCM-494:
-

It there anything I can do to help expedite this ticket? I've provided a patch 
already, but please let me know if there is something else I can do that will 
get this patch applied. If there is a problem with the approach I've suggested, 
let's discuss so we can get the right solution implemented and released.

> Let providers indicate whether a commit is required before a tag
> 
>
> Key: SCM-494
> URL: http://jira.codehaus.org/browse/SCM-494
> Project: Maven SCM
>  Issue Type: Improvement
>  Components: maven-scm-api
>Reporter: Mike Dillon
>Priority: Minor
> Attachments: requiresCommitBeforeTag.diff
>
>
> As part of looking into creating a patch for MRELEASE-477, I realized that 
> SCM providers would need to indicate whether they are able to create a "tag" 
> directly from a modified working copy. Subversion can do this, but not all 
> providers can. I'm providing a patch that adds a requiresCommitBeforeTag() 
> method to ScmProvider, similar to the requiresEditMode() method. It looks 
> like there is a request for a general "capabilities" API in SCM-23; this 
> would fit into such an API if it existed, but that issue doesn't have a patch 
> attached :)
> I haven't provided a test of this since it's only a flag that is not used 
> inside maven-scm (I'm planning to provide a patch for maven-release to use it 
> there). I could see it being used in scm:tag to allow a generic check for a 
> dirty working copy in a local-to-remote tag operation, but it seems like 
> these things are better handled by the provider themselves.

-- 
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: (MCHANGELOG-89) Dependency Conflict plexus-utils

2009-10-19 Thread Benjamin Bentmann (JIRA) 

[ 
http://jira.codehaus.org/browse/MCHANGELOG-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=186246#action_186246
 ] 

Benjamin Bentmann edited comment on MCHANGELOG-89 at 10/19/09 10:07 AM:


-Simply declare plexus-utils:1.5.6 as a plugin dependency in your POM and you 
have a workaround.- (impossible for reporting plugins).

  was (Author: bentmann):
Simply declare plexus-utils:1.5.6 as a plugin dependency in your POM and 
you have a workaround.
  
> Dependency Conflict plexus-utils
> 
>
> Key: MCHANGELOG-89
> URL: http://jira.codehaus.org/browse/MCHANGELOG-89
> Project: Maven 2.x Changelog Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: Maven 3.x
>Reporter: Lammert Westerhoff
>Assignee: Benjamin Bentmann
> Fix For: 2.2
>
>
> The maven-changelog-plugin is using the maven-scm-provider-svnexe for svn 
> repositories. The maven-scm-provider-svnexe is ugin plexus-utils 1.5.6. 
> Because of a nearer dependency from maven-model the plugin will use 
> plexus-utils 1.0.4, causing the plugin to fail.
> See below the dependencies and the stacktrace.
> {noformat}
> [DEBUG] Resolving plugin: org.apache.maven.plugins:maven-changelog-plugin 
> with version: 2.1
> [DEBUG] In verifyVersionedPlugin for: 
> org.apache.maven.plugins:maven-changelog-plugin
> [DEBUG] 
> org.apache.maven.plugins:maven-changelog-plugin:maven-plugin:2.1:runtime 
> (selected for runtime)
> [DEBUG]   org.apache.maven:maven-project:jar:2.0:runtime (selected for 
> runtime)
> [DEBUG] org.apache.maven:maven-profile:jar:2.0:runtime (selected for 
> runtime)
> [DEBUG]   org.apache.maven:maven-model:jar:2.0:runtime (selected for 
> runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected 
> for runtime)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected 
> for runtime)
> [DEBUG]   
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:runtime 
> (selected for runtime)
> [DEBUG] junit:junit:jar:3.8.1:runtime (selected for runtime)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2:runtime (selected for 
> runtime)
> [DEBUG] org.apache.maven:maven-model:jar:2.0:runtime (selected for 
> runtime)
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0:runtime (selected 
> for runtime)
> [DEBUG]   org.apache.maven:maven-repository-metadata:jar:2.0:runtime 
> (selected for runtime)
> [DEBUG]   org.apache.maven:maven-artifact:jar:2.0:runtime (selected for 
> runtime)
> [DEBUG]   
> org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected 
> for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for 
> runtime)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0:runtime (selected for 
> runtime)
> [DEBUG] 
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:runtime 
> (selected for runtime)
> [DEBUG]   junit:junit:jar:3.8.1:runtime (selected for runtime)
> [DEBUG]   classworlds:classworlds:jar:1.1-alpha-2:runtime (selected for 
> runtime)
> [DEBUG]   org.apache.maven.reporting:maven-reporting-api:jar:2.0:runtime 
> (selected for runtime)
> [DEBUG] doxia:doxia-sink-api:jar:1.0-alpha-4:runtime (selected for 
> runtime)
> [DEBUG]   org.apache.maven:maven-model:jar:2.0:runtime (selected for runtime)
> [DEBUG]   org.apache.maven.reporting:maven-reporting-impl:jar:2.0:runtime 
> (selected for runtime)
> [DEBUG] commons-validator:commons-validator:jar:1.1.4:runtime (selected 
> for runtime)
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for 
> runtime)
> [DEBUG] oro:oro:jar:2.0.7:runtime (selected for runtime)
> [DEBUG] doxia:doxia-core:jar:1.0-alpha-4:runtime (selected for runtime)
> [DEBUG]   doxia:doxia-sink-api:jar:1.0-alpha-4:runtime (removed - nearer 
> found: 1.0-alpha-5)
> [DEBUG]   doxia:doxia-sink-api:jar:1.0-alpha-5:runtime (selected for runtime)
> [DEBUG]   org.apache.maven:maven-settings:jar:2.0:runtime (selected for 
> runtime)
> [DEBUG]   org.apache.maven.scm:maven-scm-api:jar:1.0:runtime (selected for 
> runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime (removed - 
> nearer found: 1.0.4)
> [DEBUG]   org.apache.maven.scm:maven-scm-manager-plexus:jar:1.0:runtime 
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime (removed - 
> nearer found: 1.0.4)
> [DEBUG] 
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:runtime (removed 
> - nearer found: 1.0-alpha-8)
> [DEBUG]   org.apache.maven.scm:maven-scm-provider-bazaar:jar:1.0:runtime 
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime (removed - 
> nearer found: 1.0.4)
> [DEBUG] regexp:regexp

[jira] Created: (MECLIPSE-610) 2.0.1 breaks silently

2009-10-19 Thread Urs Keller (JIRA) 
2.0.1 breaks silently


 Key: MECLIPSE-610
 URL: http://jira.codehaus.org/browse/MECLIPSE-610
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
  Components: AJDT support
Affects Versions: 2.7, 2.8
Reporter: Urs Keller


The version is handled as a float. A configuration with 2.0.1 will break it, 
but there is no warning what so ever.
org.apache.maven.plugin.eclipse.EclipsePlugin.createEclipseWriterConfig(IdeDependency[]):
 Line 1238:

float ajdtVersionFloat;
try
{
ajdtVersionFloat = Float.parseFloat( ajdtVersion );
}
catch ( NumberFormatException e )
{
ajdtVersionFloat = 0.0f;
}


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

[jira] Closed: (MNG-4396) [regression] Ant plugin fails with Maven-3

2009-10-19 Thread Benjamin Bentmann (JIRA) 

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

Benjamin Bentmann closed MNG-4396.
--

   Resolution: Fixed
Fix Version/s: 3.0-alpha-3
 Assignee: Benjamin Bentmann

Fixed by updating to classworlds 2.2.1+ and plexus 1.4.0+

> [regression] Ant plugin fails with Maven-3
> --
>
> Key: MNG-4396
> URL: http://jira.codehaus.org/browse/MNG-4396
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3
>Reporter: Niall Pemberton
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
> Attachments: output.txt, pom.xml
>
>
> Apache Commons has an ant plugin which is used to generate custom download 
> and issue tracking pages for the 30+ components:
> * http://commons.apache.org/commons-build-plugin/
> * 
> http://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/trunk/
> This works fine with maven 2.x but when I tried to run the goals using 
> maven-3 built from the latest source today it fails. I'm attaching the output 
> (run with -X) . There is a small test project which can be used to show this 
> problem here:
> * 
> http://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/trunk/src/test-project/
> There are two goals:
> * mvn commons:download-page
> * mvn commons:jira-page
> These should each create an xml document in the xdocs directory

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

[jira] Commented: (MJAVADOC-252) javadoc link : nonproxyhosts not used

2009-10-19 Thread Vincent Siveton (JIRA) 

[ 
http://jira.codehaus.org/browse/MJAVADOC-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195227#action_195227
 ] 

Vincent Siveton commented on MJAVADOC-252:
--

@Martijn, the patch doesn't affect NTLM proxy. You could use 
 for this proxy, feel free to try it and create a new issue 
if it doesn't work

> javadoc link : nonproxyhosts not used
> -
>
> Key: MJAVADOC-252
> URL: http://jira.codehaus.org/browse/MJAVADOC-252
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.6
> Environment: maven-2.0.10
> jdk 1.6_014
>Reporter: Maxime Gréau
>Assignee: Vincent Siveton
>Priority: Minor
> Fix For: 2.6.1
>
> Attachments: link_nonproxy_2.0.10.patch, link_nonproxy_2.2.0.patch
>
>
> - Prerequisite : 
> 
> - web access via http proxy
> - javadoc-plugin configuration with true
> - $MVN_HOME/conf/settings.xml with configuration above ( internal-host is 
> host to access the internal javadoc web sites )
>  
> 
>   true
>   http
>   myproxyhost
>   myproxyport
>   internal-host
> 
> 
> Launch the mvn site-deploy command. 
> If you have a dependency with an internal javadoc web site, the plugin tried 
> to link this javadoc with the http proxy and logged:
> "Error fetching link: http://internal-host//apidocs/package-list. Ignored 
> it."
> This is a bug because this javadoc isn't accessible via http proxy.
> So I attached 2 patches :
> - the first one (link_nonproxy_2.0.10.patch) is compatible (and tested) with 
> mvn 2.0.9 and 2.0.10 but included a method directly copied from 
> ProxyUtils.java (wagon-provider-api-1.0-beta-6.jar)
> - the second (link_nonproxy_2.2.0.patch) used 2 classes from 
> wagon-provider-api-1.0-beta-6.jar dependency so it requires mvn 2.2

-- 
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-4396) [regression] Ant plugin fails with Maven-3

2009-10-19 Thread Benjamin Bentmann (JIRA) 

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

Benjamin Bentmann updated MNG-4396:
---

Summary: [regression] Ant plugin fails with Maven-3  (was: Ant plugin fails 
with Maven-3)

> [regression] Ant plugin fails with Maven-3
> --
>
> Key: MNG-4396
> URL: http://jira.codehaus.org/browse/MNG-4396
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3
>Reporter: Niall Pemberton
> Attachments: output.txt, pom.xml
>
>
> Apache Commons has an ant plugin which is used to generate custom download 
> and issue tracking pages for the 30+ components:
> * http://commons.apache.org/commons-build-plugin/
> * 
> http://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/trunk/
> This works fine with maven 2.x but when I tried to run the goals using 
> maven-3 built from the latest source today it fails. I'm attaching the output 
> (run with -X) . There is a small test project which can be used to show this 
> problem here:
> * 
> http://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/trunk/src/test-project/
> There are two goals:
> * mvn commons:download-page
> * mvn commons:jira-page
> These should each create an xml document in the xdocs directory

-- 
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: (MINVOKER-95) Add a selector script to allow for flexible skipping specific projects

2009-10-19 Thread Stephen Connolly (JIRA) 

[ 
http://jira.codehaus.org/browse/MINVOKER-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195220#action_195220
 ] 

Stephen Connolly commented on MINVOKER-95:
--

I'm working on this one... just cannot add myself as the assignee yet!

> Add a selector script to allow for flexible skipping specific projects
> --
>
> Key: MINVOKER-95
> URL: http://jira.codehaus.org/browse/MINVOKER-95
> Project: Maven 2.x Invoker Plugin
>  Issue Type: New Feature
>Reporter: Stephen Connolly
>Priority: Minor
>
> The selector properties are great for skipping executions on common criteria.
> This feature would provide for a script which would be able to flag a project 
> for skipped execution based on complex criteria which cannot be encoded 
> within the current selector properties.
> For example, an integration test may require that a specific version of an 
> application server is installed on the system, using a selector script, you 
> could then have the script verify that the application server is installed 
> and then crack open some of the app-server's jar files and verify that the 
> manifest has the required version.

-- 
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: (MINVOKER-95) Add a selector script to allow for flexible skipping specific projects

2009-10-19 Thread Stephen Connolly (JIRA) 
Add a selector script to allow for flexible skipping specific projects
--

 Key: MINVOKER-95
 URL: http://jira.codehaus.org/browse/MINVOKER-95
 Project: Maven 2.x Invoker Plugin
  Issue Type: New Feature
Reporter: Stephen Connolly
Priority: Minor


The selector properties are great for skipping executions on common criteria.

This feature would provide for a script which would be able to flag a project 
for skipped execution based on complex criteria which cannot be encoded within 
the current selector properties.

For example, an integration test may require that a specific version of an 
application server is installed on the system, using a selector script, you 
could then have the script verify that the application server is installed and 
then crack open some of the app-server's jar files and verify that the manifest 
has the required version.

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

[jira] Commented: (SUREFIRE-562) Exorbitant long site-build since surefire 2.4

2009-10-19 Thread Bugittaa Pahasti (JIRA) 

[ 
http://jira.codehaus.org/browse/SUREFIRE-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195216#action_195216
 ] 

Bugittaa Pahasti commented on SUREFIRE-562:
---

This renders site generation practically unusable. Is there any workarounds?

> Exorbitant long site-build since surefire 2.4
> -
>
> Key: SUREFIRE-562
> URL: http://jira.codehaus.org/browse/SUREFIRE-562
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: report plugin
>Affects Versions: 2.4, 2.4.1, 2.4.2, 2.4.3
>Reporter: Jörg Hohwiller
>
> When I have maven-surefire-report-plugin and maven-surefire-plugin in version 
> 2.3, 
> my site-generation works quite okay.
> However when I update to 2.4, 2.4.1, 2.4.2 or 2.4.3 the site-build takes an 
> exorbitant long time.
> When you watch the log, you get the impression that there is an infinity-loop 
> because it
> builds the same modules again and again. However it is not an infinity loop 
> but I think that for every
> module also all dependent modules are build (and therefore tested) 
> recursively even if they had 
> already been build before.
> This way 2.4 scales from O(n) to O(n^2) where n is the number of modules when 
> you have
> common inter-project dependencies.
> Maybe some feature in 2.4 like improve coverage measure with cobertura or 
> whatever
> introduced this bug.
> Infos about mvn site:stage with surefire 2.3:
> Total time: 18 minutes 19 seconds
> Size of logfile (mvn output): 3.567.441 bytes
> grep "Building util-core" site.log | wc -l: 44
> Infos about mvn site:stage with surefire 2.4.3:
> Total time: 70 minutes 29 seconds
> Size of logfile (mvn output): 58.442.755 bytes
> grep "Building util-core" site.log | wc -l: 130
> FYI: util-core is the name of a module that all other modules depend on 
> directly or transitive.
> Besides in the 2.3 build only 1 of the 44 lines with "[INFO] Building 
> util-core" is followed with
> [INFO]task-segment: [site:stage]
> All other 43 are followed by some --- and then
> [INFO] No goals needed for project - skipping
> The extra lines in the 2.4 build are followed with some  and then
> [INFO] [resources:resources]
> ...
> Please also note that the maven logfile is totaly unreadable since you have 
> no clue where a recursive invocation starts and ends. This is more an MNG 
> issue, however...

-- 
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: (MCHECKSTYLE-105) Update to Checkstyle 5.0

2009-10-19 Thread JIRA 

[ 
http://jira.codehaus.org/browse/MCHECKSTYLE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195213#action_195213
 ] 

Sébastien PRUNIER commented on MCHECKSTYLE-105:
---

2.4-SNAPSHOT tested with a custom configuration file, it works fine. No problem 
for me.

> Update to Checkstyle 5.0
> 
>
> Key: MCHECKSTYLE-105
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-105
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Felix Röthenbacher
> Fix For: 2.4
>
> Attachments: patch.diff, update-to-5.0-812221.patch, 
> update-to-5.0.patch, update-to-5.0beta2.patch
>
>
> Checkstyle 5.0-beta01 adds support for generics, etc.
> See
> http://checkstyle.sourceforge.net/5.x/releasenotes.html
> for a list of new features.
> Note: Prerequisite is that checkstyle-all jar, version 5.0-beta01 is 
> available from a public Maven repository.
> Patch updates plugin to changed API / implementation.

-- 
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: (MEAR-114) Properties in task not taken into consideration when defining an execution id for an auto generating application.xml

2009-10-19 Thread Anthony BOUQUET (JIRA) 

[ 
http://jira.codehaus.org/browse/MEAR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195205#action_195205
 ] 

Anthony BOUQUET commented on MEAR-114:
--

Sorry for the test tag. It souldn't be there ! I didn't know how to remove it 
after having posted this message.

I will build the project again asap.

Anyway it's only a sample with a war project wich is used to build the ear 
project.
If we try to run multiple executions (I use this for multiples customers), the 
defined context root fails and it take only the default contextRoot wich is in 
fact the artefactID of the war project.


> Properties in  task not taken into consideration when defining an 
> execution id for an auto generating application.xml
> -
>
> Key: MEAR-114
> URL: http://jira.codehaus.org/browse/MEAR-114
> Project: Maven 2.x Ear Plugin
>  Issue Type: Bug
>Affects Versions: 2.3.2
> Environment: Windows XP, M2Eclipse, Eclipse Galileo
>Reporter: Anthony BOUQUET
>
> {code:xml} 
>  
>   
>   
>   
>   
>   
> com.logic.silogisme.pidi
>   
> TransfertOT-WAR
>   
> my-custom-context-root
>   
>   
>   
>   
>  
> {code} 
> But this doesn't work (it produce an application.xml with default contextRoot)
> {code:xml}
> 
>execution-1
>   
>   
>   
>   
> com.logic.silogisme.pidi
>   
> TransfertOT-WAR
>   
> my-custom-context-root
>   
>   
>   
>   
> {code}
> This is problematic if we want to use multiple executions .

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