[jira] Created: (SUREFIRE-647) Memory Leak

2010-09-20 Thread Stephen Coy (JIRA)
Memory Leak
---

 Key: SUREFIRE-647
 URL: http://jira.codehaus.org/browse/SUREFIRE-647
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.6
 Environment: Maven 2.2.1, 3.0RC1
Reporter: Stephen Coy
Priority: Critical
 Attachments: surefire dump.png

We have a module containing over 500 unit tests, most of which create Hibernate 
sessions with a largish data model.

Surefire 2.6 fails to complete these tests, even with:
 -Xmx512m
specified.

Surefire 2.5 (and earlier) completes these tests with no trouble at all, 
without jvmArg settings.

I performed a heapdump (which is too big to upload here) and it shows that 
org.apache.maven.surefire.util.TeeStream seems to be hanging on to data in 
memory. The 20 biggest objects by retained size were all instances of this. 
I've attached a screen dump


-- 
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-4803) Include few new helpful methods to ArtifactVersion interface

2010-09-20 Thread Brett Porter (JIRA)

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

Brett Porter closed MNG-4803.
-

Resolution: Won't Fix
  Assignee: Brett Porter

changing the interface would be problematic for compatibility, and new 
versioning is likely to happen from a new interface. I think this is best as 
part of a shared utility.

> Include few new helpful methods to  ArtifactVersion interface
> -
>
> Key: MNG-4803
> URL: http://jira.codehaus.org/browse/MNG-4803
> Project: Maven 2 & 3
>  Issue Type: Improvement
>Reporter: Prashant  Bhate
>Assignee: Brett Porter
>
> It is Useful to include following helpful methods to interface 
> ArtifactVersion and corresponding implementation in DefaultArtifactVersion 
> class
> getMajorVersion
> getNextMinorVersion
> Implementation is easy just do currentVersion+1
> It would help towards merging functionality of 
> org.apache.maven.shared.release.versions.VersionInfo into this
> see 
> http://maven.apache.org/maven-release/maven-release-manager/xref/org/apache/maven/shared/release/versions/VersionInfo.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: (MNG-4587) command line option "-update-snapshots" does not work for parent POMs (Maven 2 also affected)

2010-09-20 Thread Brett Porter (JIRA)

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

Brett Porter closed MNG-4587.
-

Resolution: Won't Fix
  Assignee: Brett Porter

as described at 
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-NonuniqueSnapshotDeployments,
 non-unique snapshots are not going to be supported in the future. I recommend 
changing to that behaviour.

> command line option "-update-snapshots" does not work for parent POMs (Maven 
> 2 also affected)
> -
>
> Key: MNG-4587
> URL: http://jira.codehaus.org/browse/MNG-4587
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.2.1
>Reporter: Peter Niederwieser
>Assignee: Brett Porter
>Priority: Critical
>
> Since I didn't get any response to my comment on MNG-4433, I've opened a new 
> issue. The following is from my original comment.
> I have exactly the same issue with 2.2.1. After changing and deploying parent 
> POM, I run build with -U (on a different machine). Excerpt from output:
> {noformat}
> [INFO] snapshot org.spockframework:spock-parent:0.4-groovy-1.7-SNAPSHOT: 
> checking for updates from central
> [17:48:33]: Downloading: 
> http://xxx/artifactory/repo/org/spockframework/spock-parent/0.4-groovy-1.7-SNAPSHOT/spock-parent-0.4-groovy-1.7-SNAPSHOT.pom
> [17:48:33]: Downloading: 
> http://xxx/artifactory/repo/org/spockframework/spock-maven/0.4-groovy-1.7-SNAPSHOT/spock-maven-0.4-groovy-1.7-SNAPSHOT.jar
> {noformat}
> Maven says that it is downloading spock-parent POM, but it doesn't end up in 
> the local repo. Compare to the output after manually deleting the old POM 
> from the local repo:
> {noformat}
> [INFO] snapshot org.spockframework:spock-parent:0.4-groovy-1.7-SNAPSHOT: 
> checking for updates from central
> Downloading: 
> http://xxx/artifactory/repo/org/spockframework/spock-parent/0.4-groovy-1.7-SNAPSHOT/spock-parent-0.4-groovy-1.7-SNAPSHOT.pom
> 8K downloaded  (spock-parent-0.4-groovy-1.7-SNAPSHOT.pom)
> {noformat}
> Here we get "8K downloaded", which we didn't get before. The local repo now 
> contains the correct POM, and the build succeeds.
> Here is what the local repo looked like before I manually deleted the old POM:
> {noformat}
> drwxr-xr-x  6 pniederw  admin   204 Mar  5 16:48 .
> drwxr-xr-x  3 pniederw  admin   102 Dec 14 13:47 ..
> -rw-r--r--  1 pniederw  admin   331 Mar  5 16:48 maven-metadata-central.xml
> -rw-r--r--  1 pniederw  admin40 Mar  5 16:48 
> maven-metadata-central.xml.sha1
> -rw-r--r--  1 pniederw  admin  9048 Mar  5 16:48 
> spock-parent-0.4-groovy-1.7-SNAPSHOT.pom
> -rw-r--r--  1 pniederw  admin40 Dec 14 13:47 
> spock-parent-0.4-groovy-1.7-SNAPSHOT.pom.sha1
> {noformat}
> As you can see, the POM's last modified date is recent, but nevertheless the 
> content is old. In fact it still matches the pom.sha1, which was last updated 
> in December! How is this possible?
> This is a very insidious bug, and you would help a lot of people by fixing it 
> ASAP.

-- 
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-4633) Make weave mode work reliably

2010-09-20 Thread Brett Porter (JIRA)

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

Brett Porter updated MNG-4633:
--

Fix Version/s: 3.x / Backlog

IIUC, this isn't blocking Maven 3?

> Make weave mode work reliably
> -
>
> Key: MNG-4633
> URL: http://jira.codehaus.org/browse/MNG-4633
> Project: Maven 2 & 3
>  Issue Type: Improvement
>Affects Versions: 3.0-beta-1
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: 3.x / Backlog
>
>
> m3 trunk currently contains two different concurrent-build implementations; 
> parallel and weave. The main target for m3 is for production quality 
> "parallel" to be  ready; there are numerous plugins that will need to adjust 
> to this functionality. 
> Alongside this activity weave mode will also be fine-tuned and evaluated; due 
> to the generally tighter concurrency in this model, weave mode is more likely 
> to reveal concurrency related issues in both maven, plugins, libraries and 
> the jdk. 
> This task is used to collect all commits related to making weave mode work 
> reliably. The final evaluation of weave mode will be taken at a later stage.
> In the event that Weave mode is to be abandoned, the class 
> LifecycleWeaveBuilder contains instructions on how/what can be removed from 
> m3 core.

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




[jira] Commented: (MSITE-505) Unable to use SVN SCM wagon to upload a site

2010-09-20 Thread Andrew Phillips (JIRA)

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

Andrew Phillips commented on MSITE-505:
---

See also 
http://mail-archives.apache.org/mod_mbox/maven-users/201009.mbox/%3c560995.77447...@web25505.mail.ukl.yahoo.com%3e

> Unable to use SVN SCM wagon to upload a site
> 
>
> Key: MSITE-505
> URL: http://jira.codehaus.org/browse/MSITE-505
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 3.0-beta-2
> Environment: Maven 3.0-beta-3 (r990787; 2010-08-30 14:44:03+0200)
> Maven site plugin 3.0-beta-3-SNAPSHOT
>Reporter: Andrew Phillips
> Attachments: mvn-X-output.txt, pom.xml
>
>
> Even though the SCM project is apparently able to correctly pick up the SVN 
> provider in the attached POM, the site plugin is unable to deploy to a site 
> with an 'scm:svn...' URL and warns that 
> [WARNING] No SCM providers configured.
> Here the abbreviated output of two commands - see the attachment for the full 
> output.
> > mvn scm:status
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building SCM deploy:site test 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-scm-plugin:1.4:status (default-cli) @ scm-deploy-test ---
> [INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
> [INFO] Working directory: XXX
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> > mvn site:deploy -X
> [DEBUG] The site will be deployed to url 'scm:svn:https://acme.com/svn/site' 
> with id 'scm-deploy-test-site'
> [DEBUG] repository protocol scm
> [DEBUG] getProxy 'protocol' : scm
> [DEBUG] getProxy 'protocol' : scm no ProxyInfo found
> [DEBUG] found proxyInfo null
> [DEBUG] authenticationInfo with id 'scm-deploy-test-site' : null
> [WARNING] No SCM providers configured.
> [DEBUG]  configureWagon 
> [DEBUG] configureWagon server XXX
> ...
> [DEBUG] configureWagon server XXX
> [DEBUG] connect with authenticationInfo and without proxyInfo
> scm:svn:https://acme.com/svn/site - Session: Opened  
>  Transfer error: org.apache.maven.scm.manager.NoSuchScmProviderException: No 
> such provider: 'svn'.
> scm:svn:https://acme.com/svn/site - Session: Disconnecting  
> scm:svn:https://acme.com/svn/site - Session: Disconnected
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [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: (MSITE-505) Unable to use SVN SCM wagon to upload a site

2010-09-20 Thread Andrew Phillips (JIRA)

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

Andrew Phillips commented on MSITE-505:
---

The POM includes commented-out experiments involving adding the SVN provider to 
the SCM and/or site plugins as plugin dependencies, and/or setting 
true. Unfortunately, neither of these helped.

One thing I noticed is that the site plugin's POM [1] contains dependencies on 
(amongst others) the WebDAV wagon, but not on any SVN SCM providers (WebDAV 
works fine for publishing sites).

[1] 
https://svn.apache.org/repos/asf/maven/plugins/branches/maven-site-plugin-3.x/pom.xml

> Unable to use SVN SCM wagon to upload a site
> 
>
> Key: MSITE-505
> URL: http://jira.codehaus.org/browse/MSITE-505
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 3.0-beta-2
> Environment: Maven 3.0-beta-3 (r990787; 2010-08-30 14:44:03+0200)
> Maven site plugin 3.0-beta-3-SNAPSHOT
>Reporter: Andrew Phillips
> Attachments: mvn-X-output.txt, pom.xml
>
>
> Even though the SCM project is apparently able to correctly pick up the SVN 
> provider in the attached POM, the site plugin is unable to deploy to a site 
> with an 'scm:svn...' URL and warns that 
> [WARNING] No SCM providers configured.
> Here the abbreviated output of two commands - see the attachment for the full 
> output.
> > mvn scm:status
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building SCM deploy:site test 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-scm-plugin:1.4:status (default-cli) @ scm-deploy-test ---
> [INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
> [INFO] Working directory: XXX
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> > mvn site:deploy -X
> [DEBUG] The site will be deployed to url 'scm:svn:https://acme.com/svn/site' 
> with id 'scm-deploy-test-site'
> [DEBUG] repository protocol scm
> [DEBUG] getProxy 'protocol' : scm
> [DEBUG] getProxy 'protocol' : scm no ProxyInfo found
> [DEBUG] found proxyInfo null
> [DEBUG] authenticationInfo with id 'scm-deploy-test-site' : null
> [WARNING] No SCM providers configured.
> [DEBUG]  configureWagon 
> [DEBUG] configureWagon server XXX
> ...
> [DEBUG] configureWagon server XXX
> [DEBUG] connect with authenticationInfo and without proxyInfo
> scm:svn:https://acme.com/svn/site - Session: Opened  
>  Transfer error: org.apache.maven.scm.manager.NoSuchScmProviderException: No 
> such provider: 'svn'.
> scm:svn:https://acme.com/svn/site - Session: Disconnecting  
> scm:svn:https://acme.com/svn/site - Session: Disconnected
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [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] Created: (MSITE-505) Unable to use SVN SCM wagon to upload a site

2010-09-20 Thread Andrew Phillips (JIRA)
Unable to use SVN SCM wagon to upload a site


 Key: MSITE-505
 URL: http://jira.codehaus.org/browse/MSITE-505
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0-beta-2
 Environment: Maven 3.0-beta-3 (r990787; 2010-08-30 14:44:03+0200)
Maven site plugin 3.0-beta-3-SNAPSHOT
Reporter: Andrew Phillips
 Attachments: mvn-X-output.txt, pom.xml

Even though the SCM project is apparently able to correctly pick up the SVN 
provider in the attached POM, the site plugin is unable to deploy to a site 
with an 'scm:svn...' URL and warns that 

[WARNING] No SCM providers configured.

Here the abbreviated output of two commands - see the attachment for the full 
output.

> mvn scm:status
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building SCM deploy:site test 1.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-scm-plugin:1.4:status (default-cli) @ scm-deploy-test ---
[INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
[INFO] Working directory: XXX
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 

> mvn site:deploy -X

[DEBUG] The site will be deployed to url 'scm:svn:https://acme.com/svn/site' 
with id 'scm-deploy-test-site'
[DEBUG] repository protocol scm
[DEBUG] getProxy 'protocol' : scm
[DEBUG] getProxy 'protocol' : scm no ProxyInfo found
[DEBUG] found proxyInfo null
[DEBUG] authenticationInfo with id 'scm-deploy-test-site' : null
[WARNING] No SCM providers configured.
[DEBUG]  configureWagon 
[DEBUG] configureWagon server XXX
...
[DEBUG] configureWagon server XXX
[DEBUG] connect with authenticationInfo and without proxyInfo
scm:svn:https://acme.com/svn/site - Session: Opened  
 Transfer error: org.apache.maven.scm.manager.NoSuchScmProviderException: No 
such provider: 'svn'.
scm:svn:https://acme.com/svn/site - Session: Disconnecting  
scm:svn:https://acme.com/svn/site - Session: Disconnected
[INFO] 
[INFO] BUILD FAILURE
[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] Created: (MNG-4830) Add helper component to build MavenExecutionRequest from cli args (String[] args)

2010-09-20 Thread Olivier Lamy (JIRA)
Add helper component to build MavenExecutionRequest from cli args (String[] 
args)
-

 Key: MNG-4830
 URL: http://jira.codehaus.org/browse/MNG-4830
 Project: Maven 2 & 3
  Issue Type: Improvement
  Components: Bootstrap & Build, Command Line
Affects Versions: 3.0-beta-3
Reporter: Olivier Lamy


currently executing maven programmatically is quite difficult because building 
easily a MavenExecutionRequest needs a lot of parameters, some methods to call 
etc...
Here a simple component which build MavenExecutionRequest  from String[] args 
(cli arguments).
Source code is here : 
[http://github.com/olamy/hudson-maven3-support/blob/master/maven3-listener/src/main/java/org/apache/maven/cli/MavenExecutionRequestBuilder.java].
Any objection I commit this in ASF ?


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




[jira] Commented: (MANTRUN-91) Cannot run javac from tasks

2010-09-20 Thread Paul Gier (JIRA)

[ 
http://jira.codehaus.org/browse/MANTRUN-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235812#action_235812
 ] 

Paul Gier commented on MANTRUN-91:
--

{quote}If I submit a patch that does A, would you include it? (Assuming it's 
done right.){quote}
Yes, as long as the standard formatting is followed and non of the current 
tests are affected.  If you can include a new integration test for this, that 
would be ideal.

> Cannot run javac from tasks
> ---
>
> Key: MANTRUN-91
> URL: http://jira.codehaus.org/browse/MANTRUN-91
> Project: Maven 2.x Antrun Plugin
>  Issue Type: Bug
>Reporter: Thomas Diesler
>
> Embedded error: The following error occurred while executing this line:
> /home/tdiesler/svn/jbossws/stack/native/trunk/modules/testsuite/native-tests/scripts/antrun-wstools.xml:65:
>  Unable to find a javac compiler;
> com.sun.tools.javac.Main is not on the classpath.
> Perhaps JAVA_HOME does not point to the JDK

-- 
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-4829) [regression] Checksum failures aren't logged

2010-09-20 Thread Benjamin Bentmann (JIRA)

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

Benjamin Bentmann closed MNG-4829.
--

   Resolution: Fixed
Fix Version/s: 3.0
 Assignee: Benjamin Bentmann

Fixed in [r998895|http://svn.apache.org/viewvc?view=revision&revision=998895].

> [regression] Checksum failures aren't logged
> 
>
> Key: MNG-4829
> URL: http://jira.codehaus.org/browse/MNG-4829
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.0-beta-3
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0
>
>
> For checksumPolicy=warn and broken artifacts, no warning is emitted during 
> the 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: (MNG-4829) [regression] Checksum failures aren't logged

2010-09-20 Thread Benjamin Bentmann (JIRA)
[regression] Checksum failures aren't logged


 Key: MNG-4829
 URL: http://jira.codehaus.org/browse/MNG-4829
 Project: Maven 2 & 3
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 3.0-beta-3
Reporter: Benjamin Bentmann


For checksumPolicy=warn and broken artifacts, no warning is emitted during the 
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] Issue Comment Edited: (MRELEASE-583) Better Snapshot Dependency Handling

2010-09-20 Thread Marcus Linke (JIRA)

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

Marcus Linke edited comment on MRELEASE-583 at 9/20/10 6:11 AM:


Hi nicola, I will do this if it is desired by the core developers too. They 
should merge the resulting patch into the current svn trunk and i don't how 
this procedure is exactly organized (maybe issue by issue?).

  was (Author: mlinke):
Hi nicola, I will do this if it is desired by the core developers too. They 
should merge the resulting patch into the current svn trunk and i don't how 
this procedure exactly organized (maybe issue by issue?).
  
> Better Snapshot Dependency Handling
> ---
>
> Key: MRELEASE-583
> URL: http://jira.codehaus.org/browse/MRELEASE-583
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: nicola sinapsi
> Fix For: 2.1
>
> Attachments: better-snapshot-dependency.patch
>
>
> The plugin has a simple snapshot dependency resolution mechanism.
> When a snapshot dependency is found, it allows for setting it to release... 
> but it does not allows to choice the release version to use:
> 
> Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set 
> to release? (yes/no) yes: : yes
> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: : 
> 
> in this case the versions are:
> current: 2.1.2-SNAPSHOT
> release: 2.1.2
> next: 2.1.3-SNAPSHOT
> The problem is that the only allowed development version is 2.1.3-SNAPSHOT 
> (the value between the parentheses), hence the only allowed release version 
> is 2.1.2.
> Notably, you cannot specify an OLDER relase (such as 2.1.1): this means you 
> are forced to release the dependency (you cannot use an already released 
> version).
> It would be better to ask for the release version to use, and then set the 
> snapshot as the release following the release version specified by the user:
> 
> Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set 
> to release? (yes/no) yes: : yes
> What is the release version? 2.1.2: : 2.3.0
> 
> in this case the versions are:
> current: 2.1.2-SNAPSHOT
> release: 2.3.0
> next: 2.3.1-SNAPSHOT
> The plugin suggests to set the release version to 2.1.2, but the user can 
> choice another version, eventually an already released 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: (MRELEASE-583) Better Snapshot Dependency Handling

2010-09-20 Thread Marcus Linke (JIRA)

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

Marcus Linke commented on MRELEASE-583:
---

Hi nicola, I will do this if it is desired by the core developers too. They 
should merge the resulting patch into the current svn trunk and i don't how 
this procedure exactly organized (maybe issue by issue?).

> Better Snapshot Dependency Handling
> ---
>
> Key: MRELEASE-583
> URL: http://jira.codehaus.org/browse/MRELEASE-583
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: nicola sinapsi
> Fix For: 2.1
>
> Attachments: better-snapshot-dependency.patch
>
>
> The plugin has a simple snapshot dependency resolution mechanism.
> When a snapshot dependency is found, it allows for setting it to release... 
> but it does not allows to choice the release version to use:
> 
> Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set 
> to release? (yes/no) yes: : yes
> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: : 
> 
> in this case the versions are:
> current: 2.1.2-SNAPSHOT
> release: 2.1.2
> next: 2.1.3-SNAPSHOT
> The problem is that the only allowed development version is 2.1.3-SNAPSHOT 
> (the value between the parentheses), hence the only allowed release version 
> is 2.1.2.
> Notably, you cannot specify an OLDER relase (such as 2.1.1): this means you 
> are forced to release the dependency (you cannot use an already released 
> version).
> It would be better to ask for the release version to use, and then set the 
> snapshot as the release following the release version specified by the user:
> 
> Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set 
> to release? (yes/no) yes: : yes
> What is the release version? 2.1.2: : 2.3.0
> 
> in this case the versions are:
> current: 2.1.2-SNAPSHOT
> release: 2.3.0
> next: 2.3.1-SNAPSHOT
> The plugin suggests to set the release version to 2.1.2, but the user can 
> choice another version, eventually an already released 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] Closed: (MNG-4824) multiple failures need additional whitespace

2010-09-20 Thread Benjamin Bentmann (JIRA)

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

Benjamin Bentmann closed MNG-4824.
--

   Resolution: Fixed
Fix Version/s: 3.0
 Assignee: Benjamin Bentmann

Improved in 
[r998878|http://svn.apache.org/viewvc?view=revision&revision=998878].

> multiple failures need additional whitespace
> 
>
> Key: MNG-4824
> URL: http://jira.codehaus.org/browse/MNG-4824
> Project: Maven 2 & 3
>  Issue Type: Improvement
>  Components: Logging
>Affects Versions: 3.0-beta-3
>Reporter: Brett Porter
>Assignee: Benjamin Bentmann
> Fix For: 3.0
>
>
> I got 3 resolution errors. On a smaller console width, they were very hard to 
> read:
> {code}
> [ERROR] The build could not read 3 projects -> [Help 1]
> [ERROR]   The project 
> org.codehaus.redback:redback-authorization-rbac:1.3-SNAPSHOT 
> (/Users/brett/scm/redback/redback-rbac/redback-authorization-rbac/pom.xml) 
> has 1 error
> [ERROR] Non-resolvable parent POM 
> org.codehaus.redback:redback-authorization-providers:1.3-SNAPSHOT for 
> org.codehaus.redback:redback-authorization-rbac:1.3-SNAPSHOT: Failed to 
> resolve POM for 
> org.codehaus.redback:redback-authorization-providers:1.3-SNAPSHOT due to The 
> following artifacts could not be resolved: 
> org.codehaus.redback:redback-authorization-providers:pom:1.3-SNAPSHOT: Could 
> not find artifact 
> org.codehaus.redback:redback-authorization-providers:pom:1.3-SNAPSHOT -> 
> [Help 2]
> [ERROR]   The project 
> org.codehaus.redback:redback-authentication-keys:1.3-SNAPSHOT 
> (/Users/brett/scm/redback/redback-keys/redback-authentication-keys/pom.xml) 
> has 1 error
> [ERROR] Non-resolvable parent POM 
> org.codehaus.redback:redback-authentication-providers:1.3-SNAPSHOT for 
> org.codehaus.redback:redback-authentication-keys:1.3-SNAPSHOT: Failed to 
> resolve POM for 
> org.codehaus.redback:redback-authentication-providers:1.3-SNAPSHOT due to The 
> following artifacts could not be resolved: 
> org.codehaus.redback:redback-authentication-providers:pom:1.3-SNAPSHOT: Could 
> not find artifact 
> org.codehaus.redback:redback-authentication-providers:pom:1.3-SNAPSHOT -> 
> [Help 2]
> [ERROR]   The project 
> org.codehaus.redback:redback-authentication-users:1.3-SNAPSHOT 
> (/Users/brett/scm/redback/redback-users/redback-authentication-users/pom.xml) 
> has 1 error
> [ERROR] Non-resolvable parent POM 
> org.codehaus.redback:redback-authentication-providers:1.3-SNAPSHOT for 
> org.codehaus.redback:redback-authentication-users:1.3-SNAPSHOT: Failed to 
> resolve POM for 
> org.codehaus.redback:redback-authentication-providers:1.3-SNAPSHOT due to The 
> following artifacts could not be resolved: 
> org.codehaus.redback:redback-authentication-providers:pom:1.3-SNAPSHOT: Could 
> not find artifact 
> org.codehaus.redback:redback-authentication-providers:pom:1.3-SNAPSHOT -> 
> [Help 2]
> {code}
> I suggest adding a number to the front of each, and a new line between them.

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




[jira] Commented: (MRELEASE-583) Better Snapshot Dependency Handling

2010-09-20 Thread nicola sinapsi (JIRA)

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

nicola sinapsi commented on MRELEASE-583:
-

for me the new version you are suggesting is ok.
only i do not know when i will have time to implement the changes.

if you can do it it would be great :)


> Better Snapshot Dependency Handling
> ---
>
> Key: MRELEASE-583
> URL: http://jira.codehaus.org/browse/MRELEASE-583
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: nicola sinapsi
> Fix For: 2.1
>
> Attachments: better-snapshot-dependency.patch
>
>
> The plugin has a simple snapshot dependency resolution mechanism.
> When a snapshot dependency is found, it allows for setting it to release... 
> but it does not allows to choice the release version to use:
> 
> Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set 
> to release? (yes/no) yes: : yes
> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: : 
> 
> in this case the versions are:
> current: 2.1.2-SNAPSHOT
> release: 2.1.2
> next: 2.1.3-SNAPSHOT
> The problem is that the only allowed development version is 2.1.3-SNAPSHOT 
> (the value between the parentheses), hence the only allowed release version 
> is 2.1.2.
> Notably, you cannot specify an OLDER relase (such as 2.1.1): this means you 
> are forced to release the dependency (you cannot use an already released 
> version).
> It would be better to ask for the release version to use, and then set the 
> snapshot as the release following the release version specified by the user:
> 
> Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set 
> to release? (yes/no) yes: : yes
> What is the release version? 2.1.2: : 2.3.0
> 
> in this case the versions are:
> current: 2.1.2-SNAPSHOT
> release: 2.3.0
> next: 2.3.1-SNAPSHOT
> The plugin suggests to set the release version to 2.1.2, but the user can 
> choice another version, eventually an already released 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] Closed: (MNG-4818) NPE in legacy.DefaultWagonManager.getArtifact

2010-09-20 Thread Benjamin Bentmann (JIRA)

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

Benjamin Bentmann closed MNG-4818.
--

   Resolution: Fixed
Fix Version/s: 3.0
 Assignee: Benjamin Bentmann

Fixed in [r998861|http://svn.apache.org/viewvc?view=revision&revision=998861]. 
Actually caused by a bad component which asked for injection into clashing 
private fields.

> NPE in legacy.DefaultWagonManager.getArtifact
> -
>
> Key: MNG-4818
> URL: http://jira.codehaus.org/browse/MNG-4818
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.0
> Environment: At revision 998131; 1.6.0_21 (32-bit); win7ent-x64
>Reporter: Matthew Daniel
>Assignee: Benjamin Bentmann
> Fix For: 3.0
>
> Attachments: bug.log
>
>
> 1. mvn archetype:create (with your favorite -DgroupId etc)
> 2. add some non-local dependency to the pom (I used commons-jexl:2.0.1)
> 3. mvn idea:idea
> 4. kaboom
> The problem is that the Logger is declared as @Requirement but it is 
> evidently not being provided (any path leading to a logging statement yields 
> the NPE)
> I regret that I don't know enough plexus-voodoo to even create a TestCase for 
> this.

-- 
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-583) Better Snapshot Dependency Handling

2010-09-20 Thread Marcus Linke (JIRA)

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

Marcus Linke commented on MRELEASE-583:
---

I suggest to merge the patches from MRELEASE-583, MRELEASE-588 and MRELEASE-350 
into one. After that the discussed changes from MRELEASE-583 (improved version 
prompting) could be implemented. But i dont know if this is desired by the core 
developers. Any comments?

> Better Snapshot Dependency Handling
> ---
>
> Key: MRELEASE-583
> URL: http://jira.codehaus.org/browse/MRELEASE-583
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: nicola sinapsi
> Fix For: 2.1
>
> Attachments: better-snapshot-dependency.patch
>
>
> The plugin has a simple snapshot dependency resolution mechanism.
> When a snapshot dependency is found, it allows for setting it to release... 
> but it does not allows to choice the release version to use:
> 
> Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set 
> to release? (yes/no) yes: : yes
> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: : 
> 
> in this case the versions are:
> current: 2.1.2-SNAPSHOT
> release: 2.1.2
> next: 2.1.3-SNAPSHOT
> The problem is that the only allowed development version is 2.1.3-SNAPSHOT 
> (the value between the parentheses), hence the only allowed release version 
> is 2.1.2.
> Notably, you cannot specify an OLDER relase (such as 2.1.1): this means you 
> are forced to release the dependency (you cannot use an already released 
> version).
> It would be better to ask for the release version to use, and then set the 
> snapshot as the release following the release version specified by the user:
> 
> Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set 
> to release? (yes/no) yes: : yes
> What is the release version? 2.1.2: : 2.3.0
> 
> in this case the versions are:
> current: 2.1.2-SNAPSHOT
> release: 2.3.0
> next: 2.3.1-SNAPSHOT
> The plugin suggests to set the release version to 2.1.2, but the user can 
> choice another version, eventually an already released 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] Closed: (MNG-4825) Relative path errors could be more explicit

2010-09-20 Thread Benjamin Bentmann (JIRA)

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

Benjamin Bentmann closed MNG-4825.
--

   Resolution: Fixed
Fix Version/s: 3.0
 Assignee: Benjamin Bentmann

Improved in 
[r998850|http://svn.apache.org/viewvc?view=revision&revision=998850].

> Relative path errors could be more explicit
> ---
>
> Key: MNG-4825
> URL: http://jira.codehaus.org/browse/MNG-4825
> Project: Maven 2 & 3
>  Issue Type: Improvement
>  Components: Logging
>Affects Versions: 3.0-beta-3
>Reporter: Brett Porter
>Assignee: Benjamin Bentmann
> Fix For: 3.0
>
>
> See the exceptions in MNG-4824.
> This was caused by a default relative path of '../pom.xml' which was not 
> correct. Maven 2.x ignored it and went to the repository, but as specified in 
> the compatibility notes Maven 3 fails. The exception should state that it was 
> a non-resolvable parent because  it is not in the repository and not found at 
> the relative path of '../pom.xml'

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




[jira] Commented: (MNG-4818) NPE in legacy.DefaultWagonManager.getArtifact

2010-09-20 Thread Matthew Daniel (JIRA)

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

Matthew Daniel commented on MNG-4818:
-

My sincere apologies, it appears that I left out "-DdownloadSources=true" from 
step 3.

The good(?) news is that yes, I experience this on 3.0-RC1 also.

Just for clarity, I'll repeat the correct reproduction steps:

1. mkdir \tmp\foo
2. cd \tmp\foo
3. mvn -DgroupId=my.group -DartifactId=myart -Dpackage=com.example.foo 
-Dpackaging=jar archetype:create
4. cd myart
5. edit pom.xml and add dependency (org.apache.commons:commons-jexl:2.0.1:jar) 
with no scope
6. rmdir /s /q %M2_LOCAL_REPO%\org\apache\commons\commons-jexl
7. mvn -e -DdownloadSources=true idea:idea


> NPE in legacy.DefaultWagonManager.getArtifact
> -
>
> Key: MNG-4818
> URL: http://jira.codehaus.org/browse/MNG-4818
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.0
> Environment: At revision 998131; 1.6.0_21 (32-bit); win7ent-x64
>Reporter: Matthew Daniel
> Attachments: bug.log
>
>
> 1. mvn archetype:create (with your favorite -DgroupId etc)
> 2. add some non-local dependency to the pom (I used commons-jexl:2.0.1)
> 3. mvn idea:idea
> 4. kaboom
> The problem is that the Logger is declared as @Requirement but it is 
> evidently not being provided (any path leading to a logging statement yields 
> the NPE)
> I regret that I don't know enough plexus-voodoo to even create a TestCase for 
> this.

-- 
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: (MRELEASE-406) release:perform ignores environment variables

2010-09-20 Thread James Nord (JIRA)

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

James Nord reopened MRELEASE-406:
-


Brett: Please read comment by me from 17/Mar/09 6:20 AM.

> release:perform ignores environment variables
> -
>
> Key: MRELEASE-406
> URL: http://jira.codehaus.org/browse/MRELEASE-406
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 2.0-beta-8
> Environment: WinXP Maven 2.0.9
>Reporter: James Nord
>Assignee: Brett Porter
>Priority: Blocker
> Attachments: mvn2.0.10.log, mvn2.0.10_debug.log, mvn2.1.0-RC3.log, 
> pom.xml, settings.xml
>
>
> Our settings.xml is shared across many sites and we use reository mirrors at 
> each of our sites.
> The mirrors are setup in the settings.xml as ${proxyURL}/repopath
> the users set an environment variable to point to the nexus cache at their 
> paticular site -
>  eg http://maven-proxy-east.mycorp.com/nexus/content/repositories
> This woks fine for normal working (compile, site deploy etc..)  but 
> release:perform fails as it tries to download from
> ${proxyURL}/central/org/apache/mave
> It would appear that environment variables are not passed to the forked 
> process doing the release.
> -- settings.xml snippet --
>   
>   central-mirror
>   Maven Central [nexus mirror]
>   ${proxyURL}/central
>   central
>   
> -- end settings.xml snippet --
> output from release:perfrom
> D:\workspaces\TestProject>set | grep proxyURL
> proxyURL=http://maven-proxy-east.mycorp.com/nexus/content/repositories
> D:\workspaces\TestProject>mvn release:perform
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'release'.
> [INFO] 
> 
> [INFO] Building Test Project
> [INFO]task-segment: [release:perform] (aggregator-style)
> [INFO] 
> 
> [INFO] [release:perform]
> [INFO] Checking out the project to perform the release ...
> [INFO] Executing: cmd.exe /X /C "svn --non-interactive checkout 
> https://svnserver.mycorp.com/repos/scratch/tags/testproj-0.0.1
> checkout"
> [INFO] Working directory: D:\workspaces\TestProject\target
> [INFO] Executing goals 'deploy site-deploy'...
> [WARNING] Maven will be executed in interactive mode, but no input stream has 
> been configured for this MavenInvoker inst
> ance.
> [INFO] [INFO] Scanning for projects...
> [INFO] [INFO] 
> 
> [INFO] [INFO] Building Test Project
> [INFO] [INFO]task-segment: [deploy, site-deploy]
> [INFO] [INFO] 
> 
> [INFO] Downloading: 
> ${proxyURL}/releases/org/apache/maven/plugins/maven-deploy-plugin/2.4/maven-deploy-plugin-2.4.pom
> [INFO] Downloading: 
> ${proxyURL}/central/org/apache/maven/plugins/maven-deploy-plugin/2.4/maven-deploy-plugin-2.4.pom
> [INFO] Downloading: 
> ${proxyURL}/releases/org/apache/maven/plugins/maven-deploy-plugin/2.4/maven-deploy-plugin-2.4.pom
> [INFO] Downloading: 
> ${proxyURL}/thirdparty/org/apache/maven/plugins/maven-deploy-plugin/2.4/maven-deploy-plugin-2.4.pom
> [INFO] Downloading: 
> ${proxyURL}/central/org/apache/maven/plugins/maven-deploy-plugin/2.4/maven-deploy-plugin-2.4.pom
> [INFO] Downloading: 
> ${proxyURL}/codehaus/org/apache/maven/plugins/maven-deploy-plugin/2.4/maven-deploy-plugin-2.4.pom
> [INFO] Downloading: 
> ${proxyURL}/java.net/org/apache/maven/plugins/maven-deploy-plugin/2.4/maven-deploy-plugin-2.4.pom
> [INFO] Downloading: 
> ${proxyURL}/jboss/org/apache/maven/plugins/maven-deploy-plugin/2.4/maven-deploy-plugin-2.4.pom
> [INFO] [INFO] 
> 
> [INFO] [ERROR] BUILD ERROR
> [INFO] [INFO] 
> 
> [INFO] [INFO] Error building POM (may not be this project's 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] Created: (MRELEASE-598) Repeatedly prompt for same release/next development versions of snapshot dependencies in multi-module projects

2010-09-20 Thread Marcus Linke (JIRA)
Repeatedly prompt for same release/next development versions of snapshot 
dependencies in multi-module projects
--

 Key: MRELEASE-598
 URL: http://jira.codehaus.org/browse/MRELEASE-598
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Marcus Linke


When having a huge multi-module project where the same dependencies are used in 
various submodules, the plugin prompts repeatedly the next development version 
for the same artifact/version combination over and over again. This is really 
annoying especially when having many submodules.
   
The plugin should reuse dependency version mappings once entered by the user 
for all subsequent/dependent modules. So if it finds a
unmapped snapshot artifact/classifier/version combination in a module it can 
prompt the user for it and
reuse this mapping for the whole process without prompting again. This behavior 
should work for all usecases, shouln't it?

-- 
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: (MLINKCHECK-2) links to reports give false positives if run from a profile

2010-09-20 Thread Grzegorz Slowikowski (JIRA)

[ 
http://jira.codehaus.org/browse/MLINKCHECK-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235792#action_235792
 ] 

Grzegorz Slowikowski commented on MLINKCHECK-2:
---

IMO linkcheck does not use  section from the profile. Compare 
"target/site" with "target/linkcheck/tmpsite".
The fix for http://jira.codehaus.org/browse/MLINKCHECK-1 
(http://svn.apache.org/viewvc?view=revision&revision=982571) looks strange and 
maybe it should be fixed/improved.

> links to reports give false positives if run from a profile
> ---
>
> Key: MLINKCHECK-2
> URL: http://jira.codehaus.org/browse/MLINKCHECK-2
> Project: Maven 2.x Linkcheck Plugin
>  Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Lukas Theussl
> Attachments: MLINKCHECK-2.zip
>
>
> Scenario: linkcheck and checkstyle are configured in a profile but not in the 
> main reporting section. Any link to checkstyle.html will then trigger a 
> linkcheck error in the report even though the page exists.

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