Nabble - Maven - Issues

Commented: (MGPG-18) NPE in GpgSigner

2009-11-21T17:46:55Z

[ http://jira.codehaus.org/browse/MGPG-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198926#action_198926 ]

Geoffrey Wiseman commented on MGPG-18:
--------------------------------------

Glad it was helpful.

> NPE in GpgSigner
> ----------------
>
> Key: MGPG-18
> URL: http://jira.codehaus.org/browse/MGPG-18
> Project: Maven 2.x GPG Plugin
> Issue Type: Bug
> Affects Versions: 1.0-alpha-4
> Reporter: Geoffrey Wiseman
> Priority: Minor
>
> If I run "mvn package gpg:sign", this works. If I run "mvn gpg:sign", I get the following stack trace:
> {code}
> java.lang.NullPointerException
> at org.apache.maven.plugin.gpg.GpgSigner.generateSignatureForArtifact(GpgSigner.java:119)
> at org.apache.maven.plugin.gpg.GpgSignAttachedMojo.execute(GpgSignAttachedMojo.java:228)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> {code}
> After running this through a debugger, I can see that this is because the 'file' object (project.getArtifact().getFile()) is null, which seems to be the case any time the artifact wasn't generated in this invocation of Maven. At the very least, this should result in a good error message, although it would be nice if "gpg:sign" would work on an artifact that was previously-generated.

--
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: (MSHADE-53) Shade createDependencyReducedPom ignores artifacts with classifier

2009-11-21T13:52:55Z

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

Benjamin Bentmann closed MSHADE-53.
-----------------------------------

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

Fixed in [r883007|http://svn.apache.org/viewvc?view=revision&revision=883007], SNAPSHOT deployed

> Shade createDependencyReducedPom ignores artifacts with classifier
> ------------------------------------------------------------------
>
> Key: MSHADE-53
> URL: http://jira.codehaus.org/browse/MSHADE-53
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
> Affects Versions: 1.2.1
> Environment: Maven 2.0.9
> JDK 1.5.0_12
> Reporter: Jonas Vikstrom
> Assignee: Benjamin Bentmann
> Fix For: 1.2.2
>
> Attachments: ShadeMojo.java.patch
>
>
> When adding a jar to be shaded that has a classifier, it is ignored and will still be in the modified pom.
> Example as follows:
> {code:title=pom.xml|borderStyle=solid}
> ...
> <dependencies>
> 
> <dependency>
> <groupId>org.company.foo</groupId>
> <artifactId>my-ejb</artifactId>
> <version>0.0.1</version>
> <classifier>client</classifier>
> </dependency>
> <dependency>
> <groupId>org.company.foo</groupId>
> <artifactId>domain</artifactId>
> <version>0.0.1</version>
> </dependency>
> ....
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-shade-plugin</artifactId>
> <version>1.2.1</version>
> <executions>
> <execution>
> <phase>package</phase>
> <goals>
> <goal>shade</goal>
> </goals>
> <configuration>
> <shadedArtifactAttached>false</shadedArtifactAttached>
> <createDependencyReducedPom>true</createDependencyReducedPom>
> <artifactSet>
> <includes>
> <include>org.company.foo:my-ejb:client</include>
> <include>org.company.foo:domain</include>
> </includes>
> </artifactSet>
> <excludeTransitive>true</excludeTransitive>
> </configuration>
> </execution>
> </executions>
> </plugin>
> ....
> {code}
> It will shade the two jars, but _my-ejb_ *will stil be in the modified pom*
> Since it annoys me I've fixed the issue, you can find it in the attached patch.
> Usecase: You package an ejb and ejb-client with the usual plugin. And since the dependency tree for said client inherents the one for the main jar, it is preferable to wrap it in a separate module, with for instance the domain-module and with its own sets of dependencies.
> /Jonas

Closed: (MSHADE-64) Relocating does not work, when an annotation references an enum

2009-11-21T12:49:55Z

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

Benjamin Bentmann closed MSHADE-64.
-----------------------------------

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

Fixed in [r882989|http://svn.apache.org/viewvc?view=revision&revision=882989], SNAPSHOT deployed.

> Relocating does not work, when an annotation references an enum
> ---------------------------------------------------------------
>
> Key: MSHADE-64
> URL: http://jira.codehaus.org/browse/MSHADE-64
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
> Affects Versions: 1.2.1
> Reporter: Alexander von Zitzewitz
> Assignee: Benjamin Bentmann
> Priority: Critical
> Fix For: 1.2.2
>
> Attachments: pom.xml
>
>
> You could reproduce the problem with the attached pom.
> The enum class javax.xml.bind.annotation.XmlAccessOrder is referenced by the annotation javax.xml.bind.annotation.XmlAccessorType. While the enum itself is moved correctly the reference from annotation to enum is not. This makes the relocation of this package impossible.

Created: (MAVENUPLOAD-2668) Please sync functional-collections

2009-11-21T08:19:55Z

Please sync functional-collections
----------------------------------

Key: MAVENUPLOAD-2668
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2668
Project: Maven Upload Requests
Issue Type: Wish
Reporter: James Wang

Please sync my repository in google code :

"com.googlecode.functional-collections","/home/maven/repository-staging/to-ibiblio/maven-svn","svn","James Wang","java2enterprise@...",,"http://functional-collections.googlecode.com/svn/maven2/releases/"

Thanks.

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

Commented: (MGPG-18) NPE in GpgSigner

2009-11-21T07:02:55Z

[ http://jira.codehaus.org/browse/MGPG-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198900#action_198900 ]

Jakub Holý commented on MGPG-18:
--------------------------------

This is really confusing for a new user and can easily discourage him/her from using this plugin.

Thanks a lot Geoffrey for providing the work-around!!! /Jakub

Updated: (MJAR-127) Deprecate jarsigner related goals in favor of dedicated maven-jarsigner-plugin

2009-11-21T05:34:55Z

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

Benjamin Bentmann updated MJAR-127:
-----------------------------------

Summary: Deprecate jarsigner related goals in favor of dedicated maven-jarsigner-plugin (was: Deprecate jarsigner related goals in favor of deciated maven-jarsigner-plugin)

> Deprecate jarsigner related goals in favor of dedicated maven-jarsigner-plugin
> ------------------------------------------------------------------------------
>
> Key: MJAR-127
> URL: http://jira.codehaus.org/browse/MJAR-127
> Project: Maven 2.x Jar Plugin
> Issue Type: Task
> Components: sign
> Reporter: Benjamin Bentmann
> Assignee: Benjamin Bentmann
> Fix For: 2.3
>
>
> As outlined in MJAVADOC-228, the current approach of using jarsigner has some problems and so we opted to move the functionality into a dedicated [maven-jarsigner-plugin|http://maven.apache.org/plugins/maven-jarsigner-plugin/] which already had its first release. As such, we will no longer support the jarsigner related goals in the JAR Plugin but point users to the new plugin.

Closed: (MENFORCER-87) enhance requireNoRepositories to permit allowing any Snapshot only repos

2009-11-21T04:42:55Z

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

Stephen Connolly closed MENFORCER-87.
-------------------------------------

Resolution: Fixed
Fix Version/s: 1.0-beta-2

Implemented in r882889.

> enhance requireNoRepositories to permit allowing any Snapshot only repos
> ------------------------------------------------------------------------
>
> Key: MENFORCER-87
> URL: http://jira.codehaus.org/browse/MENFORCER-87
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
> Affects Versions: 1.0-beta-1
> Reporter: Stephen Connolly
> Assignee: Stephen Connolly
> Priority: Minor
> Fix For: 1.0-beta-2
>
>
> Add two parameters
> allowSnapshotRepositories
> allowSnapshotPluginRepositories
> which default to false, but when true will ignore repositories which are disabled for releases

Created: (MAVENUPLOAD-2667) Please sync with my repository

2009-11-21T04:17:55Z

Please sync with my repository
------------------------------

Key: MAVENUPLOAD-2667
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2667
Project: Maven Upload Requests
Issue Type: Wish
Reporter: James Wang

Hi,

I'm James Wang, developer of guice-junit4 (guice-junit4.googlecode.com) and I want to sync my repo to the Central Maven Repo.

"com.googlecode.guice-junit4","/home/maven/repository-staging/to-ibiblio/maven-svn","svn","James Wang","java2enterprise@...",,"http://guice-junit4.googlecode.com/svn/maven2/releases/"

Thanks.

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

Created: (MENFORCER-87) enhance requireNoRepositories to permit allowing any Snapshot only repos

2009-11-21T04:17:55Z

enhance requireNoRepositories to permit allowing any Snapshot only repos
------------------------------------------------------------------------

Key: MENFORCER-87
URL: http://jira.codehaus.org/browse/MENFORCER-87
Project: Maven 2.x Enforcer Plugin
Issue Type: Improvement
Components: Standard Rules
Affects Versions: 1.0-beta-1
Reporter: Stephen Connolly
Priority: Minor

Add two parameters

allowSnapshotRepositories
allowSnapshotPluginRepositories

which default to false, but when true will ignore repositories which are disabled for releases

--
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: (MENFORCER-86) Add a banRepositories rule

2009-11-21T03:56:55Z

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

Stephen Connolly closed MENFORCER-86.
-------------------------------------

Resolution: Duplicate
Fix Version/s: 1.0-beta-1

Aha! The project site does not give details, but this feature is already available as of 1.0-beta-1

<requireNoRepositories>

Sorted

> Add a banRepositories rule
> --------------------------
>
> Key: MENFORCER-86
> URL: http://jira.codehaus.org/browse/MENFORCER-86
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
> Reporter: Stephen Connolly
> Fix For: 1.0-beta-1
>
>
> This rule is needed so that we can enforce the "no repositories" requirement of Maven Central Repository.
> I would see something like (these would be defaults>
> <banRepositories>
> <allowSnapshots>true</allowSnapshots> 
> <allowReleases>false</allowReleases> 
> <ignoreRepositories>
> 
> </ignoreRepositories>
> </banRepositories>

Created: (MNG-4462) Forbid fully qualified pathnames in system path

2009-11-20T17:05:55Z

Forbid fully qualified pathnames in system path
-----------------------------------------------

Key: MNG-4462
URL: http://jira.codehaus.org/browse/MNG-4462
Project: Maven 2
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Paul Benedict

This issue is the companion of MNG-4456 to be completed, if desired, sometime in future releases.

--
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: (MCHANGES-180) Update to Maven Reporting Impl 2.0.4.3

2009-11-20T13:31:55Z

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

Dennis Lundberg closed MCHANGES-180.
------------------------------------

Resolution: Fixed

Updated to 2.0.4.3 in [r882720|http://svn.apache.org/viewvc?rev=882720&view=rev].

> Update to Maven Reporting Impl 2.0.4.3
> --------------------------------------
>
> Key: MCHANGES-180
> URL: http://jira.codehaus.org/browse/MCHANGES-180
> Project: Maven 2.x Changes Plugin
> Issue Type: Task
> Reporter: Dennis Lundberg
> Assignee: Dennis Lundberg
> Fix For: 2.2
>
>
> To keep the Doxia-related dependencies in sync Maven Reporting Impl should be updated to version 2.0.4.2. That version uses Doxia 1.0.

Updated: (MCHANGES-180) Update to Maven Reporting Impl 2.0.4.3

2009-11-20T13:26:55Z

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

Dennis Lundberg updated MCHANGES-180:
-------------------------------------

Summary: Update to Maven Reporting Impl 2.0.4.3 (was: Update to Maven Reporting Impl 2.0.4.2)

Reopened: (MCHANGES-180) Update to Maven Reporting Impl 2.0.4.2

2009-11-20T13:26:55Z

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

Dennis Lundberg reopened MCHANGES-180:
--------------------------------------

> Update to Maven Reporting Impl 2.0.4.2
> --------------------------------------
>
> Key: MCHANGES-180
> URL: http://jira.codehaus.org/browse/MCHANGES-180
> Project: Maven 2.x Changes Plugin
> Issue Type: Task
> Reporter: Dennis Lundberg
> Assignee: Dennis Lundberg
> Fix For: 2.2
>
>
> To keep the Doxia-related dependencies in sync Maven Reporting Impl should be updated to version 2.0.4.2. That version uses Doxia 1.0.

Closed: (MNG-4456) Deprecate fully qualified pathnames in system path

2009-11-20T11:09:55Z

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

Benjamin Bentmann closed MNG-4456.
----------------------------------

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

Added warning in [r882677|http://svn.apache.org/viewvc?view=revision&revision=882677].

> Deprecate fully qualified pathnames in system path
> --------------------------------------------------
>
> Key: MNG-4456
> URL: http://jira.codehaus.org/browse/MNG-4456
> Project: Maven 2
> Issue Type: Improvement
> Affects Versions: 2.2.1
> Environment: Any.
> Reporter: Jim Showalter
> Assignee: Benjamin Bentmann
> Priority: Minor
> Fix For: 3.0-alpha-5
>
>
> You could output a deprecation warning whenever a fully qualified path is specified, but not warn if the path starts with a variable.
> For example, this would generate no warning:
> <dependency>
> <groupId>com.sun</groupId>
> <artifactId>tools</artifactId>
> <version>1.6.0</version>
> <scope>system</scope>
> <systemPath>${java.home}/../lib/tools.jar</systemPath>
> </dependency>
> but this would:
> <dependency>
> <groupId>yuck</groupId>
> <artifactId>ugh</artifactId>
> <version>4.2.8</version>
> <scope>system</scope>
> <systemPath>C:/dumb/way/to/set/up/maven/dependency</systemPath>
> </dependency>
> That way at least users are warned when they're doing something dumb, and if they change to the variable-based form, they stand a fighting chance of having portable builds.

Updated: (MNG-4456) Deprecate fully qualified pathnames in system path

2009-11-20T10:58:55Z

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

Benjamin Bentmann updated MNG-4456:
-----------------------------------

Affects Version/s: 2.2.1

> Deprecate fully qualified pathnames in system path
> --------------------------------------------------
>
> Key: MNG-4456
> URL: http://jira.codehaus.org/browse/MNG-4456
> Project: Maven 2
> Issue Type: Improvement
> Affects Versions: 2.2.1
> Environment: Any.
> Reporter: Jim Showalter
> Priority: Minor
>
> You could output a deprecation warning whenever a fully qualified path is specified, but not warn if the path starts with a variable.
> For example, this would generate no warning:
> <dependency>
> <groupId>com.sun</groupId>
> <artifactId>tools</artifactId>
> <version>1.6.0</version>
> <scope>system</scope>
> <systemPath>${java.home}/../lib/tools.jar</systemPath>
> </dependency>
> but this would:
> <dependency>
> <groupId>yuck</groupId>
> <artifactId>ugh</artifactId>
> <version>4.2.8</version>
> <scope>system</scope>
> <systemPath>C:/dumb/way/to/set/up/maven/dependency</systemPath>
> </dependency>
> That way at least users are warned when they're doing something dumb, and if they change to the variable-based form, they stand a fighting chance of having portable builds.

Closed: (MNG-4461) [regression] No transfer progress during artifact deployment

2009-11-20T10:21:55Z

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

Benjamin Bentmann closed MNG-4461.
----------------------------------

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

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

> [regression] No transfer progress during artifact deployment
> ------------------------------------------------------------
>
> Key: MNG-4461
> URL: http://jira.codehaus.org/browse/MNG-4461
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories, Logging
> Affects Versions: 3.0-alpha-4
> Reporter: Benjamin Bentmann
> Assignee: Benjamin Bentmann
> Priority: Minor
> Fix For: 3.0-alpha-5
>
>
> As reported by Juven, we get no transfer progress here:
> {noformat}
> [INFO] --- maven-deploy-plugin:2.4:deploy (default-deploy) @ test ---
> [INFO] Retrieving previous metadata from maven-core-it
> [INFO] Uploading repository metadata for: 'artifact org.apache.maven.its.mng:test'
> [INFO] Uploading project information for test 0.1
> {noformat}
> compared to Maven 2.x
> {noformat}
> [INFO] [deploy:deploy]
> Uploading: file:///M:\z/repo/org/apache/maven/its/mng/test/0.1/test-0.1.jar
> 1K uploaded (test-0.1.jar)
> [INFO] Retrieving previous metadata from maven-core-it
> [INFO] Uploading repository metadata for: 'artifact org.apache.maven.its.mng:test'
> [INFO] Uploading project information for test 0.1
> {noformat}

Created: (MNG-4461) [regression] No transfer progress during artifact deployment

2009-11-20T09:51:55Z

[regression] No transfer progress during artifact deployment
------------------------------------------------------------

Key: MNG-4461
URL: http://jira.codehaus.org/browse/MNG-4461
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Logging
Affects Versions: 3.0-alpha-4
Reporter: Benjamin Bentmann
Priority: Minor

As reported by Juven, we get no transfer progress here:
{noformat}
[INFO] --- maven-deploy-plugin:2.4:deploy (default-deploy) @ test ---
[INFO] Retrieving previous metadata from maven-core-it
[INFO] Uploading repository metadata for: 'artifact org.apache.maven.its.mng:test'
[INFO] Uploading project information for test 0.1
{noformat}
compared to Maven 2.x
{noformat}
[INFO] [deploy:deploy]
Uploading: file:///M:\z/repo/org/apache/maven/its/mng/test/0.1/test-0.1.jar
1K uploaded (test-0.1.jar)
[INFO] Retrieving previous metadata from maven-core-it
[INFO] Uploading repository metadata for: 'artifact org.apache.maven.its.mng:test'
[INFO] Uploading project information for test 0.1
{noformat}

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

Closed: (MNG-4460) NPE from the classworlds launcher while trying to use custom component.xml

2009-11-20T08:03:55Z

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

Benjamin Bentmann closed MNG-4460.
----------------------------------

Resolution: Not A Bug
Assignee: Benjamin Bentmann

From the mojo:
{code:java}
Date now = new Date();
projectProperties.put("project.date",now);
{code}
Putting non-string objects into properties violates the contract of [java.util.Properties|http://java.sun.com/javase/6/docs/api/java/util/Properties.html].

> NPE from the classworlds launcher while trying to use custom component.xml
> --------------------------------------------------------------------------
>
> Key: MNG-4460
> URL: http://jira.codehaus.org/browse/MNG-4460
> Project: Maven 2
> Issue Type: Bug
> Affects Versions: 2.2.1
> Environment: Windows XP
> Reporter: Liz Sommers
> Assignee: Benjamin Bentmann
> Attachments: build.log, components.xml, ProjectDateMojo.java
>
>
> All of this code works with Maven 2.0.8-2.0.9
> I have included the components.xml file i am using and the first mojo it calls so that you can see that it is working correctly. Resources never gets executed.
> I am not sure if the problem is with the launcher or with the resource plugin, but it should be obvious to you if you look at the build.log
> I am putting the pom here because there isn't another attachement available
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>mil.disa.packages</groupId>
> <artifactId>FAKE-PACKAGE</artifactId>
> <packaging>package</packaging>
> <version>4.2.0.2-RC03</version>
> <name>FAKE-PACKAGE</name>
> <url>http://maven.apache.org</url>
>
> <parent>
> <groupId>mil.disa.ap.segments</groupId>
> <artifactId>packageParent</artifactId>
> <version>1.8</version>
> </parent>
>
> <properties>
> <package-release-version> 4.2.0.2 </package-release-version>
> <package-name>FAKE</package-name>
> <package-prefix>FAKE</package-prefix>
> </properties>
> <scm>
> <connection>scm:svn:http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk</connection>
> <developerConnection>scm:svn:http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk</developerConnection>
> <url>http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk</url>
> </scm>
>
> <build>
> <resources>
> <resource>
> <excludes>
> <exclude>**/pkginfo</exclude>
> <exclude>**/ReleaseNotes</exclude>
> </excludes>
> <directory>FAKE</directory>
> </resource>
> <resource>
> <includes>
> <include>**/pkginfo</include>
> <include>**/ReleaseNotes</include>
> </includes>
> <directory>FAKE</directory>
> <filtering>true</filtering>
> </resource>
> </resources>
> </build>
> <dependencies>
> </dependencies>
> </project>

Created: (MNG-4460) NPE from the classworlds launcher while trying to use custom component.xml

2009-11-20T07:56:55Z

NPE from the classworlds launcher while trying to use custom component.xml
--------------------------------------------------------------------------

Key: MNG-4460
URL: http://jira.codehaus.org/browse/MNG-4460
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.2.1
Environment: Windows XP
Reporter: Liz Sommers
Attachments: build.log, components.xml, ProjectDateMojo.java

All of this code works with Maven 2.0.8-2.0.9

I have included the components.xml file i am using and the first mojo it calls so that you can see that it is working correctly. Resources never gets executed.

I am not sure if the problem is with the launcher or with the resource plugin, but it should be obvious to you if you look at the build.log

I am putting the pom here because there isn't another attachement available

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>mil.disa.packages</groupId>
<artifactId>FAKE-PACKAGE</artifactId>
<packaging>package</packaging>
<version>4.2.0.2-RC03</version>
<name>FAKE-PACKAGE</name>
<url>http://maven.apache.org</url>

<parent>
<groupId>mil.disa.ap.segments</groupId>
<artifactId>packageParent</artifactId>
<version>1.8</version>
</parent>

<properties>
<package-release-version> 4.2.0.2 </package-release-version>
<package-name>FAKE</package-name>
<package-prefix>FAKE</package-prefix>
</properties>
<scm>
<connection>scm:svn:http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk</connection>
<developerConnection>scm:svn:http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk</developerConnection>
<url>http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk</url>
</scm>

<build>
<resources>
<resource>
<excludes>
<exclude>**/pkginfo</exclude>
<exclude>**/ReleaseNotes</exclude>
</excludes>
<directory>FAKE</directory>
</resource>
<resource>
<includes>
<include>**/pkginfo</include>
<include>**/ReleaseNotes</include>
</includes>
<directory>FAKE</directory>
<filtering>true</filtering>
</resource>
</resources>

</build>
<dependencies>
</dependencies>
</project>

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

Closed: (MSITE-435) Plugin running in batch mode fails to upload site via scp due to failure to resolve credentials from settings.xml

2009-11-20T06:58:55Z

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

Abraham Kiggundu closed MSITE-435.
----------------------------------

Resolution: Not A Bug

Issue resolved by further investigation as per comments

> Plugin running in batch mode fails to upload site via scp due to failure to resolve credentials from settings.xml
> -----------------------------------------------------------------------------------------------------------------
>
> Key: MSITE-435
> URL: http://jira.codehaus.org/browse/MSITE-435
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
> Affects Versions: 2.0-beta-7
> Environment: software platform
> Reporter: Abraham Kiggundu
>
> When the site:deploy plugin is ran in interactive mode it prompts you for your username and password. On a Hudson build server we run maven in batch mode.
> The command line below:
> mvn site:deploy --batch-mode
> will always fail the build due to the following error
> Cannot connect. Reason: Auth cancel
> the only temporary workaround to fix this at the moment is to have the user credentials in your pom as below
> <site>
> <id>docs</id>
> <name>Release Documentation Website</name>
> <url>scp://[USER]:[PASSWORD]@[MACHINE]/{location uri}/</url>
> </site>
> In contradiction the distribution management works fine with the following pom setup
> <distributionManagement>
> <repository>
> <id>id</id>
> <name>the id</name>
> <url>scp://[USER]@[MACHINE]/{location uri}/</url>
> </repository>
> </distributionManagement>
> and never prompts you for user credentials always grabing them from the settings .xml

Commented: (MSITE-435) Plugin running in batch mode fails to upload site via scp due to failure to resolve credentials from settings.xml

2009-11-20T06:58:55Z

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

Abraham Kiggundu commented on MSITE-435:
----------------------------------------

I took a deeper look into this and realised the server <id></id> in my settings.xml was not matching the site <id></id> value. Once I corrected this all was fine without placing the credentials in the url.

Closed: (MNG-4459) [regression] Effective settings as visible to plugins contain plain text passwords

2009-11-20T06:41:55Z

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

Benjamin Bentmann closed MNG-4459.
----------------------------------

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

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

> [regression] Effective settings as visible to plugins contain plain text passwords
> ----------------------------------------------------------------------------------
>
> Key: MNG-4459
> URL: http://jira.codehaus.org/browse/MNG-4459
> Project: Maven 2
> Issue Type: Bug
> Components: Settings
> Affects Versions: 3.0-alpha-4
> Reporter: Benjamin Bentmann
> Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-5
>
>
> When we introduced MNG-553, the passwords were only decrypted at the transport layer and the {{Settings}} instance kept in memory was kept encrypted. E.g. to save plugins from accidentally dumping the plain text passwords on the console or such.
> This does currently not hold for 3.0-alpha-4 as {{org.apache.maven.plugin:maven-help-plugin:2.0:effective-settings}} shows.

Created: (MSITE-435) Plugin running in batch mode fails to upload site via scp due to failure to resolve credentials from settings.xml

2009-11-20T06:41:55Z

Plugin running in batch mode fails to upload site via scp due to failure to resolve credentials from settings.xml
-----------------------------------------------------------------------------------------------------------------

Key: MSITE-435
URL: http://jira.codehaus.org/browse/MSITE-435
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 2.0-beta-7
Environment: software platform
Reporter: Abraham Kiggundu

When the site:deploy plugin is ran in interactive mode it prompts you for your username and password. On a Hudson build server we run maven in batch mode.

The command line below:
mvn site:deploy --batch-mode

will always fail the build due to the following error
Cannot connect. Reason: Auth cancel

the only temporary workaround to fix this at the moment is to have the user credentials in your pom as below
<site>
<id>docs</id>
<name>Release Documentation Website</name>
<url>scp://[USER]:[PASSWORD]@[MACHINE]/{location uri}/</url>
</site>

In contradiction the distribution management works fine with the following pom setup
<distributionManagement>
<repository>
<id>id</id>
<name>the id</name>
<url>scp://[USER]@[MACHINE]/{location uri}/</url>
</repository>
</distributionManagement>

and never prompts you for user credentials always grabing them from the settings .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

Created: (MNG-4459) [regression] Effective settings as visible to plugins contain plain text passwords

2009-11-20T05:37:55Z

[regression] Effective settings as visible to plugins contain plain text passwords
----------------------------------------------------------------------------------

Key: MNG-4459
URL: http://jira.codehaus.org/browse/MNG-4459
Project: Maven 2
Issue Type: Bug
Components: Settings
Affects Versions: 3.0-alpha-4
Reporter: Benjamin Bentmann

When we introduced MNG-553, the passwords were only decrypted at the transport layer and the {{Settings}} instance kept in memory was kept encrypted. E.g. to save plugins from accidentally dumping the plain text passwords on the console or such.

This does currently not hold for 3.0-alpha-4 as {{org.apache.maven.plugin:maven-help-plugin:2.0:effective-settings}} shows.

--
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: (MENFORCER-86) Add a banRepositories rule

2009-11-20T04:12:55Z

Add a banRepositories rule
--------------------------

Key: MENFORCER-86
URL: http://jira.codehaus.org/browse/MENFORCER-86
Project: Maven 2.x Enforcer Plugin
Issue Type: New Feature
Components: Standard Rules
Reporter: Stephen Connolly

This rule is needed so that we can enforce the "no repositories" requirement of Maven Central Repository.

I would see something like (these would be defaults>

<banRepositories>
<allowSnapshots>true</allowSnapshots> 
<allowReleases>false</allowReleases> 
<ignoreRepositories>

</ignoreRepositories>
</banRepositories>

--
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-4457) dependency:resolve decides to take older (incompatible) version for transitive dep

2009-11-20T03:15:55Z

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

Paolo Compieta edited comment on MNG-4457 at 11/20/09 5:14 AM:
---------------------------------------------------------------

1) ok
2) ok
3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest

I still see this last case as a problem:
- A resolves 1.3.0 via B via DepMgmt, 2 hops
- B has 1.4.1, 1 hop

So, should B win? (case: m2WrongTransitiveDepResolve.zip)
If no, i agree to close this issue.

was (Author: paolo.compieta):
1) ok
2) ok
3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest

I still see this last case as a problem:
- A resolves 1.3.0 via B via DepMgmt, 2 hops
- B has 1.4.1, 1 hop
So, should B win? (case: m2WrongTransitiveDepResolve.zip)
If no, i agree to close this issue.

> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXp
> Maven 2.0.9/2.2.1
> Reporter: Paolo Compieta
> Assignee: Brian Fox
> Attachments: m2FairTransitiveDepResolve.zip, m2WrongTransitiveDepResolve.zip
>
>
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo

Commented: (MNG-4457) dependency:resolve decides to take older (incompatible) version for transitive dep

2009-11-20T03:13:55Z

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

Paolo Compieta commented on MNG-4457:
-------------------------------------

1) ok
2) ok
3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest

I still see this last case as a problem:
- A resolves 1.3.0 via B via DepMgmt, 2 hops
- B has 1.4.1, 1 hop
So, should B win? (case: m2WrongTransitiveDepResolve.zip)
If no, i agree to close this issue.

Commented: (MRELEASE-504) Check if working copy is up-to-date

2009-11-20T02:22:55Z

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

Stefan Seelmann commented on MRELEASE-504:
------------------------------------------

As a pre-requirement I think SCM must support remote commands: http://jira.codehaus.org/browse/SCM-381

> Check if working copy is up-to-date
> -----------------------------------
>
> Key: MRELEASE-504
> URL: http://jira.codehaus.org/browse/MRELEASE-504
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
> Affects Versions: 2.0-beta-9
> Reporter: Stefan Seelmann
>
> It would be nice if the release:prepare goal could check if the working copy is up-to-date.
> For svn the local and the remote revision number could be compared.
> For git the it should also be possible to compare commit IDs.
> My current problem that release:prepare fails if there is a newer revision in the SVN repository:
> -----------------------------------------------------------
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: File '/firstmodule/trunk/pom.xml' is out of date
> -----------------------------------------------------------

Created: (MRELEASE-504) Check if working copy is up-to-date

2009-11-20T02:18:55Z

Check if working copy is up-to-date
-----------------------------------

Key: MRELEASE-504
URL: http://jira.codehaus.org/browse/MRELEASE-504
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: prepare
Affects Versions: 2.0-beta-9
Reporter: Stefan Seelmann

It would be nice if the release:prepare goal could check if the working copy is up-to-date.

For svn the local and the remote revision number could be compared.
For git the it should also be possible to compare commit IDs.

My current problem that release:prepare fails if there is a newer revision in the SVN repository:
-----------------------------------------------------------
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/firstmodule/trunk/pom.xml' is out of date
-----------------------------------------------------------

--
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-481) prepare goal no longer errors on subversion files

2009-11-20T01:51:55Z

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

Stefan Seelmann commented on MRELEASE-481:
------------------------------------------

This seems to be related with http://jira.codehaus.org/browse/SCM-480.

> prepare goal no longer errors on subversion files
> ---------------------------------------------------
>
> Key: MRELEASE-481
> URL: http://jira.codehaus.org/browse/MRELEASE-481
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Affects Versions: 2.0-beta-8
> Reporter: Paul Hammant
> Fix For: 2.0-beta-10
>
>
> Snow Leopard / Maven 2.2.0 / Svn 1.6.3 (via macports)
> release:prepare used to error telling you that you had files not checked in.
> It no longer does, or no longer does by default :-(
> -ph

Updated: (SUREFIRE-321) Run tests in alphabetical order

2009-11-19T20:18:55Z

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

Simon van der Sluis updated SUREFIRE-321:
-----------------------------------------

Attachment: SUREFIRE-243.patch

Looks like the affected class has changed slightly in 243.

Here's an updated patch.

> Run tests in alphabetical order
> -------------------------------
>
> Key: SUREFIRE-321
> URL: http://jira.codehaus.org/browse/SUREFIRE-321
> Project: Maven Surefire
> Issue Type: Improvement
> Affects Versions: 2.3
> Reporter: Daniel Beland
> Priority: Minor
> Fix For: 2.x
>
> Attachments: SUREFIRE-243.patch, SUREFIRE-321.patch
>
>
> It would be nice if the tests were run in alphabetical order (with complete package name).
> So all tests in a package run in order and same things for each packages.
> It just makes it easier to know where we currently are in the tests and makes it easier to estimate how long it will take before the tests finish to run.

Commented: (SUREFIRE-321) Run tests in alphabetical order

2009-11-19T16:44:55Z

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

Simon van der Sluis commented on SUREFIRE-321:
----------------------------------------------

Some more motivation to implement this:

In one of our software projects we have a unit (or it might be some) test that contaminates a spring application context but doesn't call setDirty() (or use the annotated equivalent). We have another unit test that is sensitive to this contamination, so the order they are run in determines if one of the tests passes or fails.

I've being trying to identify the test which contaminates the spring application context. I've tried using both the surefire includes and excludes mechanisms to run various subsets of the tests.

BUT

Depending on which tests are included (or excluded) affects the order in which the tests are run.

So I have no way of knowing if I've excluded the test(s) at fault or if it's the re-ordering that fixesd (or hides) the problem.

With over 500 units tests spread over more than 100 test classes it's far to time consuming to try all the possible combinations.

If the test classes were run in alphabetical order, I could make the sensitive test run last, and add the other tests package by package (or class by class) to determine which one(s) caused the problem.

> Run tests in alphabetical order
> -------------------------------
>
> Key: SUREFIRE-321
> URL: http://jira.codehaus.org/browse/SUREFIRE-321
> Project: Maven Surefire
> Issue Type: Improvement
> Affects Versions: 2.3
> Reporter: Daniel Beland
> Priority: Minor
> Fix For: 2.x
>
> Attachments: SUREFIRE-321.patch
>
>
> It would be nice if the tests were run in alphabetical order (with complete package name).
> So all tests in a package run in order and same things for each packages.
> It just makes it easier to know where we currently are in the tests and makes it easier to estimate how long it will take before the tests finish to run.

Commented: (MINVOKER-97) Add possibility to inherit settings.xml from calling process

2009-11-19T15:24:55Z

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

Olivier Lamy commented on MINVOKER-97:
--------------------------------------

so we have to merge 2 settings file. Which one is the dominant ?

> Add possibility to inherit settings.xml from calling process
> ------------------------------------------------------------
>
> Key: MINVOKER-97
> URL: http://jira.codehaus.org/browse/MINVOKER-97
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
> Affects Versions: 1.4
> Reporter: Konstantin Titorenko
> Assignee: Olivier Lamy
> Fix For: 1.6
>
>
> Invoker will use default settings xml even if differetn settings xml is specified in calling maven process. It would be very usefull to add posibility to "inherit" settings.xml to invoker:run goal (settingsFile parameter is not enough, since it seems imposible to determine settings file from in calling maven process)

Updated: (MINVOKER-97) Add possibility to inherit settings.xml from calling process

2009-11-19T15:10:55Z

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

Olivier Lamy updated MINVOKER-97:
---------------------------------

Fix Version/s: 1.6