Nabble - Maven - Issues

Created: (MNG-4435) Maven uses artifact download credentials during deployment in some circumstances

2009-11-10T15:30:55Z

Maven uses artifact download credentials during deployment in some circumstances
--------------------------------------------------------------------------------

Key: MNG-4435
URL: http://jira.codehaus.org/browse/MNG-4435
Project: Maven 2
Issue Type: Bug
Components: Deployment
Affects Versions: 2.2.1
Reporter: Rich Seddon

If Maven downloads an artifact using authorization, this authorization seems to be cached, which can cause a subsequent deployment to succeed where it should have failed.

Steps to reproduce:

# Set up a build which will require downloading an artifact from a Nexus server which requires authentication, and configure your settings.xml appropriately.
# Create a project with a distribution management section which points to a repository in the above server. Make sure the repository id doesn't exist in your settings.xml
# Run "mvn deploy"

What happens:

If the credentials used to download artifacts from Nexus have deployment privileges in the Nexus repository the deployment will succeed.

Now run "mvn deploy" again. This time the deployment will fail with a 401 code.

This bug exists in both Maven 2.2.1 and the latest Maven 3.0 snapshots.

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

Commented: (MCHECKSTYLE-105) Update to Checkstyle 5.0

2009-11-10T14:08:55Z

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

Dennis Lundberg commented on MCHECKSTYLE-105:
---------------------------------------------

@Steve, no next version will require java 1.5. The release will come shortly.
See the road map for more info.

> 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

Issue Comment Edited: (MCHECKSTYLE-105) Update to Checkstyle 5.0

2009-11-10T11:35:58Z

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

Steve Gorczyca edited comment on MCHECKSTYLE-105 at 11/10/09 1:35 PM:
----------------------------------------------------------------------

I'm using the version posted by Martin Zeltner and have run into no issues. Is java 1.4 support really still a requirement moving forward?

was (Author: sgorczyca):
I'm using the version posted by Martin Zeltner and have run into no issues. Is java 1.4 support really a requirement moving forward?

Commented: (MCHECKSTYLE-105) Update to Checkstyle 5.0

2009-11-10T11:35:56Z

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

Steve Gorczyca commented on MCHECKSTYLE-105:
--------------------------------------------

I'm using the version posted by Martin Zeltner and have run into no issues. Is java 1.4 support really a requirement moving forward?

Commented: (MNG-4391) DependencyManagement should allow to manage use of re-named, woven, instrumented or compatible artifacts

2009-11-10T11:21:55Z

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

Paul Benedict commented on MNG-4391:
------------------------------------

Stevo, that is a very interesting idea.

> DependencyManagement should allow <replaceWith> to manage use of re-named, woven, instrumented or compatible artifacts
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4391
> URL: http://jira.codehaus.org/browse/MNG-4391
> Project: Maven 2
> Issue Type: Improvement
> Components: Dependencies
> Affects Versions: 2.2.1
> Reporter: Neale
>
> [if only this was a later version of JIRA I'd have not lost all of what I just typed, as I could use Mylyn instead of the web UI. here goes again...]
> The challenge of using a different artifact instead of the one that is specified in a POM that you are consuming is not an easy one.
> Examples where this hits uses is:
> - the artifact name and packaging changes that Spring made at 2.5.6A (which was a big improvement)
> - wanting to use SLF4J instead of Apache commons logging (i.e. use something that provides the same API, but is an entirely different project)
> - wanting to use your own derivation of a public artifact
> - wanting to use a woven/instrumented version of a public artifact
> The current approach to replacing, say org.springframework : spring-beans with org.springframework : org.springframework.beans is to do ('scuse the shorthand):
> {code:xml}
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>com.sun.jersey.contribs</groupId>
> <artifactId>jersey-spring</artifactId>
> <exclusions>
> org.springframework : spring-beans
> </exclusions>
> </dependency>
> ... repeat for every artifact that uses spring-beans, and then add more if adding another artifact
> </dependencies>
> </dependencyManagement>
> {code}
> to exclude it, and then globally include the replacement using:
> {code:xml}
> <dependencies>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactid>org.springframework.beans</groupId>
> <version>${spring.version}</version>
> </dependency>
> </dependencies>
> {code}
> This is error prone, and could be made far easier by an extension to dependencies, which would remove the need to know what artifacts (jersey-spring in the above example) use the artifact that you are replacing. Here's how it would look:
> {code:xml}
> <dependencyManagement>
> 
> <dependencies>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactid>org.springframework.beans</groupId>
> <version>${spring.version}</version>
> </dependency>
> 
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactid>spring-beans</groupId>
> <replaceWith> 
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactid>org.springframework.beans</groupId>
> </dependency>
> 
> </replaceWith>
> </dependency>
> </dependencies>
> {code}
> NOTE:
> - Nothing is specified in <dependencies> so no artifacts are globally added where they may not be needed. This means we can develop a project wide parent pom.xml.
> - Artifacts can have been split and merged
> - Derived artifacts, such as instrumented ones can easily be substituted, and could be selectively substituted using profiles.

Closed: (MNG-4433) [regression] command line option "-update-snapshots" does not work for parent POMs

2009-11-10T10:37:55Z

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

Benjamin Bentmann closed MNG-4433.
----------------------------------

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

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

> [regression] command line option "-update-snapshots" does not work for parent POMs
> ----------------------------------------------------------------------------------
>
> Key: MNG-4433
> URL: http://jira.codehaus.org/browse/MNG-4433
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 3.0-alpha-3
> Reporter: Benjamin Bentmann
> Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-4
>
>
> [As reported by Julien Henry|http://www.mail-archive.com/dev@.../msg82738.html], it appears -U is not working for parent POMs.

Created: (MPH-71) call help:evaluate in batch mode

2009-11-10T08:39:55Z

call help:evaluate in batch mode
--------------------------------

Key: MPH-71
URL: http://jira.codehaus.org/browse/MPH-71
Project: Maven 2.x Help Plugin
Issue Type: Wish
Affects Versions: 2.1
Reporter: Galak
Priority: Minor

The help:evaluate goal is designed to be called in interactive mode.
I would like to call this goal in batch mode, passing the expression to evaluate in a property (on the command line).

The final purpose is to evaluate predefined expressions inside a script
(unfortunately, the script is a batch file in my case...)

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

Created: (MNG-4434) Incorrect spam filter applied by dev@mojo.codehaus.org on my nawkboy@gmail.com account.

2009-11-10T08:30:55Z

Incorrect spam filter applied by dev@... on my nawkboy@... account.
---------------------------------------------------------------------------------------

Key: MNG-4434
URL: http://jira.codehaus.org/browse/MNG-4434
Project: Maven 2
Issue Type: Task
Reporter: James Carpenter

I sent a post to dev@... via a nawkboy@... account I use just for mailing lists. Shortly after signing onto the mailing list I sent the email below. Unfortunately, it appears it was blocked by a spam filter of some sort as it never showed up on the mailing list. Can someone please add my email to a whitelist and/or otherwise instruct the spam filter to let it through?

---------- Forwarded message ----------
From: James Carpenter <nawkboy@...>
Date: Mon, Nov 2, 2009 at 2:02 PM
Subject: Request to push a new release with MCOBERTURA-114 patch
To: dev@...

Assuming the maintainers are comfortable with the changes, when can I reasonably expect an official release version of the plugin which contains my changes submitted with MCOBERTURA-114?

Background:
It is occasionally useful to measure the code coverage for manual and/or automated tests which run against a test environment.

(Not to be confused with measuring code coverage of unit tests executed automatically by the build system.) For example, you may have a set of automated regression tests written using JMeter, Selenium, etc. which for some reason or another are not appropriate to run as part of the maven build.

To this end I have created a patch which greatly enhances the documentation needed to guide a user for this use case. I have also extended the instrument goal to support registering a module's cobertura.ser file as an attached artifact. This turns out to significantly clean up the child modules of a multi-module project, which would otherwise be cluttered with build-helper plugin configuration details.

For more details, I recommend you read the PDF attached to MCOBERTURA-114 which shows the html rendered version of the enhanced documentation.

I have also included some scans of hand-drawn diagrams I drew to complement the text. The documentation text in the patch does not currently link to or otherwise include the hand-drawn diagrams. I created the hand-drawn diagrams for use inside my company after I had finished creating the patch.

Related Link: http://jira.codehaus.org/browse/MCOBERTURA-114

Sincerely,
James Carpenter
email: jcarpenter621@...

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

Created: (MNG-4433) [regression] command line option "-update-snapshots" does not work for parent POMs

2009-11-10T08:15:55Z

[regression] command line option "-update-snapshots" does not work for parent POMs
----------------------------------------------------------------------------------

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

[As reported by Julien Henry|http://www.mail-archive.com/dev@.../msg82738.html], it appears -U is not working for parent POMs.

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

Created: (MNG-4432) reimplement parallel artifacts download

2009-11-10T02:31:55Z

reimplement parallel artifacts download
---------------------------------------

Key: MNG-4432
URL: http://jira.codehaus.org/browse/MNG-4432
Project: Maven 2
Issue Type: Improvement
Components: Dependencies
Affects Versions: 3.0-alpha-3
Reporter: Olivier Lamy

the current maven3 trunk (3.0-alpha-3) doesn't contains a nice feature which exists in 2.x : parallel download artifacts.
This made really faster starting with an empty repo.

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

Created: (MAVENUPLOAD-2661) Upload struts2-jQuery plugin

2009-11-10T00:26:56Z

Upload struts2-jQuery plugin
----------------------------

Key: MAVENUPLOAD-2661
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2661
Project: Maven Upload Requests
Issue Type: Wish
Reporter: Johannes Geppert

I'm a developer and project owner in struts2 jquery plugin project, please upload!

Developer johgep

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

Issue Comment Edited: (MNG-4414) "ERROR: M2_HOME is set to an invalid directory" Again ???

2009-11-09T23:15:55Z

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

Boda Béla edited comment on MNG-4414 at 11/10/09 1:14 AM:
----------------------------------------------------------

Yes that was the problem.

But why is it needed?
I simply removed that ckeck, and everything is fine.
I think it is a very bad way of checking if M2_HOME points to the appropriate directory, because I have multiple versions of maven on the PATH, so I have to rename the files, and don't want any redundand mvn.bats.

It would be better to check the lib\maven-2.2.1-uber.jar maybe. That is what metters, isn't it.

Thanks.

was (Author: bodabela):
Yes that was the problem.

But why is it needed?
I simply removed that ckeck, and everything is fine.
I think it is a very bad way of checking if M2_HOME points to the appropriate directory, because I have multiple versions of maven on the PATH, so I have to rename the files, and don't want any redundand mvn.bats.

It would be better to check the lib\maven-2.2.1-uber.jar maybe. That is what metters, doesn't it.

Thanks.

> "ERROR: M2_HOME is set to an invalid directory" Again ???
> ---------------------------------------------------------
>
> Key: MNG-4414
> URL: http://jira.codehaus.org/browse/MNG-4414
> Project: Maven 2
> Issue Type: Bug
> Components: Bootstrap & Build
> Affects Versions: 2.1.0, 2.2.1
> Environment: Windows Vista, JDK 1.5.0_11
> Reporter: Boda Béla
> Assignee: Benjamin Bentmann
> Attachments: mvn210.bat, mvn221.bat, settings.xml
>
>
> I would like to upgrade from 2.0.9 to 2.2.1, but I face the following problem.
> I simply set the M2_HOME variable in the mvn210.bat:
> SET M2_HOME=D:\java\maven\apache-maven-2.1.0
> I run mvn210.bat and get this error:
> "ERROR: M2_HOME is set to an invalid directory"
> I attached my configs. This is ordinary i think.
> The same configuration is working with 2.0.9.

Commented: (MNG-4414) "ERROR: M2_HOME is set to an invalid directory" Again ???

2009-11-09T23:13:55Z

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

Boda Béla commented on MNG-4414:
--------------------------------

Yes that was the problem.

But why is it needed?
I simply removed that ckeck, and everything is fine.
I think it is a very bad way of checking if M2_HOME points to the appropriate directory, because I have multiple versions of maven on the PATH, so I have to rename the files, and don't want any redundand mvn.bats.

It would be better to check the lib\maven-2.2.1-uber.jar maybe. That is what metters, doesn't it.

Thanks.

Created: (SUREFIRE-580) Allow "fail fast" or stop running on first failure

2009-11-09T22:29:55Z

Allow "fail fast" or stop running on first failure
--------------------------------------------------

Key: SUREFIRE-580
URL: http://jira.codehaus.org/browse/SUREFIRE-580
Project: Maven Surefire
Issue Type: New Feature
Components: Junit 4.x support
Reporter: Paul Curren

We have some slow Selenium builds. Waiting for indication of failure can take a long time. It would be helpful if there was an option to finish the test run on the first failure.

We could configure this on some of our slower builds so improve the speed of the feedback loop in the cases where there are failures.

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

Commented: (MRELEASE-497) Don't overwrite SVN auth cache

2009-11-09T21:19:55Z

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

Lenik commented on MRELEASE-497:
--------------------------------

I hate JIRA, all the operation buttons is on the left bar, when I want to add a comment, I just can't find where I shall click at! Why can't put a comment button just below this form?

I posted this issue last month, now tens of days passed, there is no one mentioned at all, I've already created the patch, but no one merge it!
I don't know how to create a developer account in apache, it looks like I can't commit to apache's SVN. Now I've created the patch, but I can't merge it neither!

When I post issues in bugs.eclipse.org, there are so many people contact to me, compared to jira.codehaus.org, it feels like codehaus is dead!

> Don't overwrite SVN auth cache
> ------------------------------
>
> Key: MRELEASE-497
> URL: http://jira.codehaus.org/browse/MRELEASE-497
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: perform, prepare, scm
> Environment: Windows XP, JDK 1.7, SVN 1.6.5
> Reporter: Lenik
> Priority: Critical
> Attachments: no-auth-cache.patch
>
>
> When release-plugin commit to SVN, it overwrites the auth cache with username/password defined in the pom.xml.
> I want to use a separate username `maven' for maven-related commits, and personal username `lenik' for personal development commits, when I start to using maven release plugin, it always overwrite the auth cache with user `maven' , and I must do a "Tortoise/Settings/Saved Data/Clear auth cache" before commit my personal changes.
> A recommend solution:
> add an option "--no-auth-cache" to svn commit command line will resolve this problem. with option --no-auth-cache, the existing auth cache is left unchanged after commited.
> if there is an auth-cache option in pom.xml, say <auth-cache>false</auth-cache> under <scm> element, it should be false be default.

Updated: (MNG-3004) Allow build lifecycle to execute projects in parallel

2009-11-09T18:42:55Z

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

Dan Fabulich updated MNG-3004:
------------------------------

Summary: Allow build lifecycle to execute projects in parallel (was: Allow build lifecycle to execute tasks in parallel)

> Allow build lifecycle to execute projects in parallel
> -----------------------------------------------------
>
> Key: MNG-3004
> URL: http://jira.codehaus.org/browse/MNG-3004
> Project: Maven 2
> Issue Type: Improvement
> Components: Bootstrap & Build, General, Performance
> Affects Versions: 2.0.6
> Reporter: Nigel Magnay
> Fix For: 2.3.x
>
> Attachments: parallel-builds.patch
>
>
> One of the great advantages with maven over scripted build environments is that it can calculate the dependencies of the build, and it could execute items that are independent of each other in parallel.
> Unfortunately it currently doesn't do this, which would be a big win over tools such as 'ant'. It also means that multicore machines have lots of idle capacity when running a serial build that could be utilised.
> I had a quick shot at seeing what might be required. Bear in mind this is the first time I have looked at maven internally, and I was just trying to feel my way around and build a POC. I got some of the way there, but my build threads don't seem to have the correct classpath - I think this is something to do with plexus / classworlds - but I don't know enough.
> It'd be great to get this feature in a future version, or a way of running my hack (figuring out why in a thread has not the plexus stuff) in the interim.

Created: (MEV-645) Bad Checksum: JTA 1.0.1B

2009-11-09T15:02:55Z

Bad Checksum: JTA 1.0.1B
------------------------

Key: MEV-645
URL: http://jira.codehaus.org/browse/MEV-645
Project: Maven Evangelism
Issue Type: Bug
Components: Checksum Failure
Reporter: Scott Parkerson

Found on URL:
https://springframework.svn.sourceforge.net/svnroot/springframework/repos/repo-ext/javax/transaction/jta/1.0.1B/jta-1.0.1B.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

Closed: (MCHECKSTYLE-122) Add Portuguese (Brazil) translation

2009-11-09T15:02:55Z

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

Dennis Lundberg closed MCHECKSTYLE-122.
---------------------------------------

Resolution: Fixed

Fixed in [r834272|http://svn.apache.org/viewvc?rev=834272&view=rev].

Thank you!

> Add Portuguese (Brazil) translation
> -----------------------------------
>
> Key: MCHECKSTYLE-122
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-122
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Improvement
> Affects Versions: 2.3
> Reporter: Taciano Tres
> Assignee: Dennis Lundberg
> Fix For: 2.4
>
> Attachments: checkstyle-report_pt_BR.properties
>
>
> I think it would be great if the messages were externalized so it could be translated for other languages than English. I can help in the pt_BR translation.

Updated: (MCHECKSTYLE-122) Add Portuguese (Brazil) translation

2009-11-09T14:59:55Z

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

Dennis Lundberg updated MCHECKSTYLE-122:
----------------------------------------

Affects Version/s: 2.3
Fix Version/s: 2.4
Assignee: Dennis Lundberg
Summary: Add Portuguese (Brazil) translation (was: Externalize messages for i18n)

Closed: (WAGON-290) Lightweight HTTPS wagon doesn't reset proxy settings correctly if they were not previously set

2009-11-09T13:49:55Z

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

Benjamin Bentmann closed WAGON-290.
-----------------------------------

Resolution: Fixed
Fix Version/s: 1.0-beta-7
Assignee: Benjamin Bentmann

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

> Lightweight HTTPS wagon doesn't reset proxy settings correctly if they were not previously set
> ----------------------------------------------------------------------------------------------
>
> Key: WAGON-290
> URL: http://jira.codehaus.org/browse/WAGON-290
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http-lightweight
> Affects Versions: 1.0-beta-6
> Reporter: Benjamin Bentmann
> Assignee: Benjamin Bentmann
> Fix For: 1.0-beta-7
>
>
> Basically the same as WAGON-232 but for the HTTPS protocol/wagon. The system properties get only reset if they were non-null before.

Created: (WAGON-290) Lightweight HTTPS wagon doesn't reset proxy settings correctly if they were not previously set

2009-11-09T13:43:55Z

Lightweight HTTPS wagon doesn't reset proxy settings correctly if they were not previously set
----------------------------------------------------------------------------------------------

Key: WAGON-290
URL: http://jira.codehaus.org/browse/WAGON-290
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http-lightweight
Affects Versions: 1.0-beta-6
Reporter: Benjamin Bentmann

Basically the same as WAGON-232 but for the HTTPS protocol/wagon. The system properties get only reset if they were non-null before.

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

Updated: (MANTTASKS-165) Ant tasks in antrun plugin - IT failing with Maven 3

2009-11-09T13:29:55Z

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

Paul Gier updated MANTTASKS-165:
--------------------------------

Description: When building the Maven ant tasks with Maven 3-alpha-3. The integration test (running ant tasks from within the antrun plugin) is failing because of a change in the Maven API, specifically the RuntimeInfo class. (was: When building the Maven ant tasks with Maven 3-alpha-3. The integration test is failing because of a change in the Maven API. )

> Ant tasks in antrun plugin - IT failing with Maven 3
> ----------------------------------------------------
>
> Key: MANTTASKS-165
> URL: http://jira.codehaus.org/browse/MANTTASKS-165
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Reporter: Paul Gier
> Attachments: build.log
>
>
> When building the Maven ant tasks with Maven 3-alpha-3. The integration test (running ant tasks from within the antrun plugin) is failing because of a change in the Maven API, specifically the RuntimeInfo class.

Updated: (MANTTASKS-165) Ant tasks in antrun plugin - IT failing with Maven 3

2009-11-09T13:27:55Z

Created: (MANTTASKS-165) Maven Ant Tasks IT failing with Maven 3

2009-11-09T13:21:55Z

Maven Ant Tasks IT failing with Maven 3
---------------------------------------

Key: MANTTASKS-165
URL: http://jira.codehaus.org/browse/MANTTASKS-165
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Reporter: Paul Gier
Attachments: build.log

When building the Maven ant tasks with Maven 3-alpha-3. The integration test is failing because of a change in the Maven API.

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

Commented: (SCM-333) Continuum ignores a new given password for a cvs account until the cvsroot is also changed

2009-11-09T13:01:55Z

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

Andrei Solntsev commented on SCM-333:
-------------------------------------

We also have this issue not only in Continuum, but in command+line Maven too.
We execute maven-scm-plugin during the build to download common resources from CVS. When user changes CVS password, cvs provider cannot login to cvs.

After debugging the source code, I found that CVS provider stores password in file ~/.cvspasswd, and doesn't refresh it.

> Continuum ignores a new given password for a cvs account until the cvsroot is also changed
> ------------------------------------------------------------------------------------------
>
> Key: SCM-333
> URL: http://jira.codehaus.org/browse/SCM-333
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-cvs
> Affects Versions: 1.0
> Reporter: Peter Kehren
> Fix For: 1.x
>
>
> I changed (only!) the password of a cvs account and set this new password in a project definition in continuum by the web interface. The next build of the project did not work, because of a wrong password (no access to cvs was reported). It seems, that continuum uses the old password although a new password was set. After changing the cvsroot (replaced ip number by dns entry; 100% NOT the reason for this error) the cvs system could be accessed; the new password was used.

Commented: (SUREFIRE-579) Maven Surefire Plugin don't run JUnit tests if TestNG in dependencies

2009-11-09T10:52:55Z

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

Jim Showalter commented on SUREFIRE-579:
----------------------------------------

We have encountered the same problem, but for JUnit with JMockit.

To reproduce the problem:

1) Sync to the tip of https://code.intuit.com/sf/projects/testutils.

2) In Eclipse, set M2_REPO and JDK_HOME so the .classpath works. (The JDK has to be version 1.6.x.)

3) Manually install version 0.989 of JMockit into M2_REPO/jmockit/jmockit/0.989/jmockit-0.989.jar. (I'm sorry this is a manual step, but the only version of JMockit in the java.net repo is 0.991, and it has the problem we're grappling with.)

4) In the TestUtils directory, run mvn clean install. You will see that 6 tests run with 0 failures and 0 errors.

5) Change the pom.xml dependency on JMockit to:

<dependency>
<groupId>mockit</groupId>
<artifactId>jmockit</artifactId>
<version>0.991</version>
<scope>test</scope>
</dependency>

6) Change the pom.xml javaagent entry to <argLine>-javaagent:"${settings.localRepository}/mockit/jmockit/0.991/jmockit-0.991.jar"</argLine>.

7) Rerun mvn clean install. You will see that 0 tests run with 0 failures and 0 errors. That's the problem--we can't get the tests to run at all when using version 0.991, and there is no other version in the repo.

Removing the javaagent entry has no effect (our understanding is that it should be possible to remove javaagent entirely and still have JMockit initialize correctly).

ErrorCodeUtilsTest is the only test that uses JMockit, so even if JMockit isn't initializing, it seems as if the other five tests should run.

The tests run in Eclipse even if we change the .classpath entry for JMockit to <classpathentry kind="var" path="M2_REPO/mockit/jmockit/0.991/jmockit-0.991.jar"/>.

> Maven Surefire Plugin don't run JUnit tests if TestNG in dependencies
> ---------------------------------------------------------------------
>
> Key: SUREFIRE-579
> URL: http://jira.codehaus.org/browse/SUREFIRE-579
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
> Affects Versions: 2.4.3
> Environment: Ubuntu Linux: Linux bcomp 2.6.31-11-generic #36-Ubuntu SMP Fri Sep 25 06:37:51 UTC 2009 i686 GNU/Linux
> $ java -version
> java version "1.6.0_15"
> Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
> Java HotSpot(TM) Server VM (build 14.1-b02, mixed mode)
> $ mvn --version
> Apache Maven 2.2.1 (r801777; 2009-08-06 23:16:01+0400)
> Java version: 1.6.0_15
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.15/jre
> Default locale: ru_RU, platform encoding: UTF-8
> OS name: "linux" version: "2.6.31-11-generic" arch: "i386" Family: "unix"
> Reporter: Bulat Nigmatullin
> Priority: Minor
> Attachments: sjt.zip
>
>
> I have a project with a lot of JUnit test. Recently I've added new
> dependency wich have TestNG in it's dependencies. From that moment
> Surefire plugins don't run JUnit test anymore. It seems to me that
> Surefire tries to find TestNG tests but not find them and don't search
> for JUnit tests. Is this behaviour correct and how can i fix this?
> I have the following line in log:
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running TestSuite
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.117
> sec
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> Example project in attachments.

Commented: (MAVENUPLOAD-2651) Please re-upload javax.ws.rs:jsr311-api:*:1.1 on http://repo2.maven.org/maven2/ from http://download.java.net/maven/2/

2009-11-09T09:39:55Z

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

Jakub Podlesak commented on MAVENUPLOAD-2651:
---------------------------------------------

Carlos,

As you suggested, we have just deployed a new jsr311-api artifacts version,
1.1.1, accessible from:

http://download.java.net/maven/2/javax/ws/rs/jsr311-api/1.1.1/

Could you please take these artifacts and upload them to the central maven repo?

Thanks in advance!

~Jakub

> Please re-upload javax.ws.rs:jsr311-api:*:1.1 on http://repo2.maven.org/maven2/ from http://download.java.net/maven/2/
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: MAVENUPLOAD-2651
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2651
> Project: Maven Upload Requests
> Issue Type: Wish
> Reporter: Jakub Podlesak
>
> Due to reasons described by Paul Sandoz (JSR-311 co-spec lead) in [1], we had to update the above mentioned artifacts.
> Could you please update them on the central maven repository?
> ----- Quote from [1]: -----
> Previously when we distributed jsr311-api version 1.1 to the java.net maven repo we naively thought that the spec was done and dusted. However, we had to make some changes to accommodate integration with Servlet 3.0.
> We do not anticipate any more changes. The maintenance review for 1.1 closes on the 1st of Nov. But i need to make switch in the Jersey source now to prepare for the release (i will send another email on that).
> ----- End Quote -----
> Thanks,
> ~Jakub
> [1]http://markmail.org/search/?q=list%3Anet.java.dev.jersey.users+change+to+depend+on+jsr311-api+version+1.1#query:list%3Anet.java.dev.jersey.users%20change%20to%20depend%20on%20jsr311-api%20version%201.1+page:1+mid:ywxiyanw5stm53di+state:results

Closed: (MNG-4221) Push all repository/artifact related code into a legacy module and create a backward compat layer for external consumers

2009-11-09T08:28:55Z

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

Benjamin Bentmann closed MNG-4221.
----------------------------------

Resolution: Fixed

Dependency relation between maven-compat and maven-core has been reversed.

> Push all repository/artifact related code into a legacy module and create a backward compat layer for external consumers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4221
> URL: http://jira.codehaus.org/browse/MNG-4221
> Project: Maven 2
> Issue Type: Task
> Affects Versions: 3.0-alpha-2
> Reporter: Jason van Zyl
> Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
>

Commented: (MNG-2017) Dependencies with scope system and version range make the build fail

2009-11-09T07:48:55Z

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

Paul Benedict commented on MNG-2017:
------------------------------------

Can I be the devil's advocate and ask why a system dependency should be treated differently?

> Dependencies with scope system and version range make the build fail
> --------------------------------------------------------------------
>
> Key: MNG-2017
> URL: http://jira.codehaus.org/browse/MNG-2017
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 2.0.2
> Reporter: Carlos Sanchez
> Priority: Minor
> Fix For: 3.x
>
>
> Same as MNG-1363 but this time for direct dependencies, it shouldn't try to resolve versions for system scope deps
> <dependency>
> <groupId>com.sun</groupId>
> <artifactId>tools</artifactId>
> <scope>system</scope>
> <version>[1.4,)</version>
> <systemPath>${java.home}/../lib/tools.jar</systemPath>
> </dependency>
> No versions are present in the repository for the artifact with a range [1.4,)
> com.sun:tools:jar:null
> from the specified remote repositories:
> central (http://test.maven.codehaus.org/maven2)
> [INFO] ----------------------------------------------------------------------------
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: No versions are present in the repository for the artifact with a range [1.4,)
> com.sun:tools:jar:null
> from the specified remote repositories:
> central (http://test.maven.codehaus.org/maven2)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> 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.artifact.versioning.OverConstrainedVersionException: No versions are present in the repository for the artifact with a range [1.4,)
> com.sun:tools:jar:null
> from the specified remote repositories:
> central (http://test.maven.codehaus.org/maven2)
> at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:265)
> at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182)
> at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1120)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:369)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more

Created: (MNG-4431) Separate mirror settings for repositories vs. pluginRepositories

2009-11-09T06:02:55Z

Separate mirror settings for repositories vs. pluginRepositories
----------------------------------------------------------------

Key: MNG-4431
URL: http://jira.codehaus.org/browse/MNG-4431
Project: Maven 2
Issue Type: New Feature
Components: Dependencies, Settings
Reporter: Paul Gier

I want to have a way to track what artifacts are downloaded because of project dependencies vs. what is downloaded because of plugins and their dependencies. One way to do this would be to have a separate mirror setting for pluginRepositories. That way all plugin dependencies would be downloaded from one URL and project dependencies would be downloaded from a different URL.

The dependencies plugin is currently not sufficient to accomplish this because the go-offline goal does not download all plugin dependencies [MDEP-82|http://jira.codehaus.org/browse/MDEP-82].

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

Created: (MNGSITE-101) Update 5 min tutorial to use archetype:generate

2009-11-09T05:28:55Z

Update 5 min tutorial to use archetype:generate
-----------------------------------------------

Key: MNGSITE-101
URL: http://jira.codehaus.org/browse/MNGSITE-101
Project: Maven 2 Project Web Site
Issue Type: Improvement
Reporter: Haikal Saadh
Priority: Minor
Attachments: 5min-tutorial-patch.diff

(because archetype:create is deprecated)

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

Commented: (SCM-333) Continuum ignores a new given password for a cvs account until the cvsroot is also changed

2009-11-09T04:05:55Z

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

Geert Pante commented on SCM-333:
---------------------------------

We're having the same issue, also in Continuum.

We're using cvs native provider. When we start a release:prepare from continuum, we always pass in a CVS user name and passwd. But when that passwd is changed, and we pass the new passwd, CVS rejects the login.

We fixed it by removing the cvs user login from .cvspasswd in continuum's home dir.
Changing DNS name by IP number had also the same effect, since this will also result in ignoring the .cvspasswd entry.

I think that CVS will ask for a user login if it's not in .cvspasswd, or the one in .cvspasswd is incorrect. Apparently the native cvs provider only handles the first case.

Greets, Geert.

Updated: (MPMD-106) Externalize messages for i18n

2009-11-09T02:58:55Z

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

Taciano Tres updated MPMD-106:
------------------------------

Attachment: pmd-report_pt_BR.properties
cpd-report_pt_BR.properties

Attaching the properties files with translated messages to pt_BR.

> Externalize messages for i18n
> -----------------------------
>
> Key: MPMD-106
> URL: http://jira.codehaus.org/browse/MPMD-106
> Project: Maven 2.x PMD Plugin
> Issue Type: Improvement
> Components: CPD, PMD
> Reporter: Taciano Tres
> Attachments: cpd-report_pt_BR.properties, pmd-report_pt_BR.properties
>
>
> I think it would be great if the messages were externalized so it could be translated for other languages than English. I can help in the pt_BR translation.

Updated: (MCHECKSTYLE-122) Externalize messages for i18n

2009-11-09T02:40:56Z

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

Taciano Tres updated MCHECKSTYLE-122:
-------------------------------------

Attachment: checkstyle-report_pt_BR.properties

Attaching the properties file with pt_BR messages translations.

> Externalize messages for i18n
> -----------------------------
>
> Key: MCHECKSTYLE-122
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-122
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Improvement
> Reporter: Taciano Tres
> Attachments: checkstyle-report_pt_BR.properties
>
>
> I think it would be great if the messages were externalized so it could be translated for other languages than English. I can help in the pt_BR translation.

Commented: (MCHECKSTYLE-122) Externalize messages for i18n

2009-11-09T02:37:55Z

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

Taciano Tres commented on MCHECKSTYLE-122:
------------------------------------------

I was talking about rules names, descriptions and sample codes. I was hoping that someone from Checkstyle Maven Plug-in have some direct contact with the Checkstyle team ... :-)

Anyway, I'll attach the 'patch' you suggested.

> Externalize messages for i18n
> -----------------------------
>
> Key: MCHECKSTYLE-122
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-122
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Improvement
> Reporter: Taciano Tres
>
> I think it would be great if the messages were externalized so it could be translated for other languages than English. I can help in the pt_BR translation.