[jira] (MNG-3695) Allow dependencies' scopes to be managed without explicit versions
[
https://jira.codehaus.org/browse/MNG-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Benedict updated MNG-3695:
---
Fix Version/s: (was: Issues to be reviewed for 4.x)
Allow dependencies' scopes to be managed without explicit versions
--
Key: MNG-3695
URL: https://jira.codehaus.org/browse/MNG-3695
Project: Maven
Issue Type: New Feature
Components: Dependencies
Affects Versions: 2.0.9
Reporter: Mark Hobson
Currently, a dependency's version or a dependency's version and scope can be
managed in dependency management, but a dependency's scope alone cannot be
managed. For example, we cannot express the following:
{noformat}dependencies
dependency
groupIdjavax.mail/groupId
artifactIdmail/artifactId
scopeprovided/scope
/dependency
/dependencies{noformat}
Of course it does work if we also specify a version, but there are times when
we want to merely control the scope and not change the resolved version.
When we try the above example we get:
{noformat}[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been included
transitively during the resolution process.
Here is the information we do have for this artifact:
o GroupID: javax.mail
o ArtifactID: mail
o Version: MISSING
o Type:jar
[INFO]
[INFO] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{javax.mail:mail:null:jar}: The version cannot be empty.
at
org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
at
org.apache.maven.artifact.DefaultArtifact.init(DefaultArtifact.java:122)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact(DefaultArtifactFactory.java:58)
at
org.apache.maven.project.DefaultMavenProjectBuilder.createManagedVersionMap(DefaultMavenProjectBuilder.java:452)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:912)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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){noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-841) Support customization of default excludes
[ https://jira.codehaus.org/browse/MNG-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-841: -- Fix Version/s: (was: Issues to be reviewed for 4.x) Support customization of default excludes - Key: MNG-841 URL: https://jira.codehaus.org/browse/MNG-841 Project: Maven Issue Type: Improvement Components: POM Affects Versions: 2.0-alpha-3 Environment: WinXP SP2, Java 1.5, Maven 2.0-alpha-3 Reporter: John Fallows Our company uses a home-grown version control system that has it's own per-directory admin subdirectory, similar in purpose to the administration subdirectories used by other version control systems, eg. CVS, .svn, etc. These directories are excluded from processing by default in Maven2, and we would like to add our custom admin subdirectory to the default exclusion list. Recommended solution from Maven Users Mailing List: Brett Porter wrote: # What you really need is to be able to configure it in a root POM shared by all projects, I think. Hopefully, any such entry in pom.xml would not completely replace the default excludes list, but merely entend the built-in definition. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2557) Various enhancements to profiles
[ https://jira.codehaus.org/browse/MNG-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-2557: --- Fix Version/s: (was: Issues to be reviewed for 4.x) Various enhancements to profiles Key: MNG-2557 URL: https://jira.codehaus.org/browse/MNG-2557 Project: Maven Issue Type: Improvement Components: Profiles Affects Versions: 2.0.4 Reporter: Jimisola Laursen The current support for profiles is somewhat limited and this issue report proposes some enhancements to profiles for ease and flexibility of use. Enhancement #1: Make it possible to have profiles that mutually exclude each other. A profile should be able to exclude one or more other profiles. Example of usage: We have a couple of profiles for databas settings (MSSQL, PostgreSQL and Derby). Only one of these profiles should be able to be active at the same time. Today, we can't express this in the profiles section. Enhancement #2: Make it possible to deactivate profiles from the command line. Example of usage: User and/or project has a set of profiles that are activate per default. The user wants to temporary disable on or more of these (by temporary I mean for one execution). Possible syntax might be: mvn -PsomeProfile=inactive|false|no or perhaps a separate command line switch. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1569) Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare
[ https://jira.codehaus.org/browse/MNG-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-1569: --- Fix Version/s: (was: Issues to be reviewed for 4.x) Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare -- Key: MNG-1569 URL: https://jira.codehaus.org/browse/MNG-1569 Project: Maven Issue Type: New Feature Components: Design, Patterns Best Practices Affects Versions: 2.0 Reporter: John Casey Priority: Trivial We need to have the ability to look at a mojo descriptor and see how it will change the build environment. This requires two things: 1. Cut off the loophole allowing unauthorized mutation of build state by making build state read-only to the mojo 2. Provide an API/annotation-set to allow explicit export of values from a mojo, where they will be incorporated into the build state. This should enable things like determining whether a mojo generates sources, or collecting the source directories (even generated ones) by scanning the plugins configured for the build. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2719) Request for Summary element in POM
[ https://jira.codehaus.org/browse/MNG-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-2719: --- Fix Version/s: (was: Issues to be reviewed for 4.x) Request for Summary element in POM -- Key: MNG-2719 URL: https://jira.codehaus.org/browse/MNG-2719 Project: Maven Issue Type: New Feature Components: POM Reporter: Ole Ersoy Priority: Minor If a summary element were added it would make RPM Spec file generation more efficient, since spec files require both a description and a summary. A summary element can also be handy for for other tools that want to generate reports giving a summary, as well as a longer description of the project. If this sounds reasonable I will update the XML Schema for maven with the summary element and submit. Cheers, - Ole -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-4622) Throw Validation Error if pom contains a dependency with two different versions.
[ https://jira.codehaus.org/browse/MNG-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-4622: --- Fix Version/s: (was: Issues to be reviewed for 4.x) Throw Validation Error if pom contains a dependency with two different versions. Key: MNG-4622 URL: https://jira.codehaus.org/browse/MNG-4622 Project: Maven Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Shane Isbell Throw a validation error if a pom contains the same dependency with two different versions. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2598) profile element in POM should support overriding project.build.directory
[
https://jira.codehaus.org/browse/MNG-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Benedict updated MNG-2598:
---
Fix Version/s: (was: Issues to be reviewed for 4.x)
profile element in POM should support overriding project.build.directory
Key: MNG-2598
URL: https://jira.codehaus.org/browse/MNG-2598
Project: Maven
Issue Type: Improvement
Components: Profiles
Affects Versions: 2.0.4
Reporter: Ian Springer
I am trying to set up a 'dev' build profile that, when enabled, will cause my
j2ee artifacts to be built directly to exploded j2ee deployment dirs, instead
of target/classes/. The purpose is to make the everyday development process
more efficient by skipping a number of time-consuming intermediate mvn steps
(i.e. jarring artifacts, copying the jars to the local repo, then unjarring
the artifacts to their deploy locations).
The intuitive way to achieve this is to override 'project.build.directory'
and/or 'project.build.outputDirectory' in a profile; e.g.:
profile
...
build
outputDirectory${jboss.home}/server/default/deploy/my.ear/my-exploded-ejb.jar
/build
...
/profile
Unfortunately, profiles currently do not allow one to override either
'project.build.directory' or 'project.build.outputDirectory'. Please change
Maven to allow profiles to override these props. Otherwise, I can't see any
other way to achieve what my team needs to do to have a practical build/dev
infrastructure.
Thanks,
Ian
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEPLOY-182) deployAtEnd bypassed in case of pluginRepository definition
[
https://jira.codehaus.org/browse/MDEPLOY-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-182.
--
Resolution: Duplicate
Assignee: Robert Scholte
deployAtEnd bypassed in case of pluginRepository definition
---
Key: MDEPLOY-182
URL: https://jira.codehaus.org/browse/MDEPLOY-182
Project: Maven Deploy Plugin
Issue Type: Bug
Affects Versions: 2.5, 2.6
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 05:51:28-0800)
Java version: 1.7.0_45, vendor: Oracle Corporation
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Ryan Parrish
Assignee: Robert Scholte
Priority: Minor
h2. Summary
If there is a pluginRepository defined in the POM, and the installAtEnd
configuration is true, the actual local repo installation at the end of the
build is skipped.
Expectation is that the local repo installation at the end of the build would
work regardless of pluginRepository configuration.
h2. Steps
# In the
[trunk/2.6-SNAPSHOT|http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin]
project, run {{mvn install}} the install-at-end-pass integration test. The
install happens successfully at the end of the build (see console output
attached).
# Add a pluginRepository definition to install-at-end-pass/pom.xml, such as
{code}
pluginRepositories
pluginRepository
idcentral/id
nameMaven Plugin Repository/name
urlhttp://repo1.maven.org/maven2/url
layoutdefault/layout
/pluginRepository
/pluginRepositories
{code}
# Re-run the {{mvn install}}. Observe that the install to local repo is not
performed (see attached install-at-end-pass_withpluginrepo.txt console
output).
h2. Workaround
Define the pluginRepositories in settings.xml, not in the current POM
lineage. The installAtEnd works as expected in this case.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEPLOY-173) Enhance the Maven Deploy Plugin to support Flat POM
[ https://jira.codehaus.org/browse/MDEPLOY-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEPLOY-173. -- Resolution: Won't Fix Assignee: Robert Scholte This is not just a deploy-plugin issue, but also an install-plugin issue. Hence this is not the right place to solve this. Instead you should use the [flatten-maven-plugin|http://mojo.codehaus.org/flatten-maven-plugin/] Enhance the Maven Deploy Plugin to support Flat POM --- Key: MDEPLOY-173 URL: https://jira.codehaus.org/browse/MDEPLOY-173 Project: Maven Deploy Plugin Issue Type: New Feature Components: deploy:deploy Reporter: Jack Jia Assignee: Robert Scholte *Problem* The pom.xml has dual purpose. 1. Building and distributing a jar 2. Used by another project for dependency management. For #1 build and distribution, pom.xml makes good sense with many sections and hierarchies. In this case the main objective is dealing with sources and various aspects of build. For #2, lets say project B needs the jar produced by project A ( #1), the only things B needs from A are, 1. jar files 2. dependencies of this jar file For #2 use-case, none of the sections or hierarchies of pom.xml make sense, except for dependencies.sections and GAV. Unfortunately maven simply copies the same pom.xml used for build to the repository for distribution. This problem gets complicated when there are pom hierarchies and dependencyManagement sections In such cases, to resolve the dependencies of an artifact, maven needs to use more than one pom.xml. This results in complex release and patch process and potential build time issues. *Solution* Enhance the maven deploy plugin to deploy a flattened pom that contains only GAV and dependencies section. The dependencies section contains, properly resolved direct dependencies of the artifact, which are the same of pom hierarchy direct dependencies. flattened pom means it cannot have any parent or any other sections that are not necessary while deploying the artifact. Note that we may need to add removeMetadata method to org.apache.maven.artifact.Artifact interface to remove the original pom metadata and then add the flattened pom metadata. I have created jira issue http://jira.codehaus.org/browse/MNG-5544 for this function *Acceptance Criteria* 1. mvn deploy could deploy flatten pom onto maven repo and its flatten pom's dependencies version should be the same as versions of pom hierachy. 2. flatten pom only contains GAV and dependencies section. 3. flatten pom only contains original direct dependencies, not including transitive dependencies. 4. flatten pom won't inherit from any parent pom. 5. flatten pom is only for artifact whose packaging is jar. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-192) Update all entries @since with the correct version 1.4
[ https://jira.codehaus.org/browse/MENFORCER-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MENFORCER-192: -- Fix Version/s: 1.4 Update all entries @since with the correct version 1.4 -- Key: MENFORCER-192 URL: https://jira.codehaus.org/browse/MENFORCER-192 Project: Maven Enforcer Plugin Issue Type: Task Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: 1.4 All code parts which use @since or something similar should be checked and updated accordingly. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-695) java.lang.NullPointerException in org.apache.maven.plugins.site.SiteStageDeployMojo.getTopMostParentWithSameStagingSiteURL
[
https://jira.codehaus.org/browse/MSITE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSITE-695:
Fix Version/s: (was: 3.4)
backlog
java.lang.NullPointerException in
org.apache.maven.plugins.site.SiteStageDeployMojo.getTopMostParentWithSameStagingSiteURL
--
Key: MSITE-695
URL: https://jira.codehaus.org/browse/MSITE-695
Project: Maven Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 3.2, 3.3
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
Maven home: C:\Java\apache-maven-3.0.5\bin\..
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_25\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
and
C:\vcs\svn\apache\log4j2\trunkC:\Java\apache-maven-3.1.0\bin\mvn.bat -version
Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-27
22:15:32-0400)
Maven home: C:\Java\apache-maven-3.1.0\bin\..
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_25\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary Gregory
Priority: Blocker
Fix For: backlog
Checkout log4j 2 from:
https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk
The HEAD of trunk is currently revision 1504131.
Run:
mvn clean site
Get:
{noformat}[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.724s
[INFO] Finished at: Wed Jul 17 12:43:47 EDT 2013
[INFO] Final Memory: 22M/213M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy (default-cli) on
project log4j: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy failed.
NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy
(default-cli) on project log4j: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: java.lang.NullPointerException
at
[jira] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349158#comment-349158 ] Arnaud Brunet commented on MNG-5605: Using wagon-ssh 2.6 and maven 3.2.1, I have this issue. ssh-wagon hangs --- Key: MNG-5605 URL: https://jira.codehaus.org/browse/MNG-5605 Project: Maven Issue Type: Bug Components: Deployment Affects Versions: 3.2.1 Reporter: Frank Cornelis Priority: Blocker When releasing (using maven-release-plugin) via Maven 3.1.1 everything works as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-703) Creating assembly (within package phase) of a multi module project before running tests fails
[
https://jira.codehaus.org/browse/MASSEMBLY-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349159#comment-349159
]
Karl-Heinz Marbaise commented on MASSEMBLY-703:
---
Created [Github Project from
it|https://github.com/khmarbaise/massembly/tree/master/massembly-703] and
unfortunately i can reproduce the problem. That's bad.
Creating assembly (within package phase) of a multi module project before
running tests fails
-
Key: MASSEMBLY-703
URL: https://jira.codehaus.org/browse/MASSEMBLY-703
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.3, 2.4
Reporter: Jörg Eichhorn
Attachments: maven_build.log, maven-multimodule-test.tar.gz
When running a maven multi module project fails, when running tests after the
package phase:
Running: {{mvn clean package test}}Â
instead of: {{mvn clean test package}}
the build fails with the following error (see detail trace in attached file
{{maven_build.log}}:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-assembly) on
project child2: Failed to create assembly: Error adding file
'test:child1:jar:1.0-SNAPSHOT' to archive:
/Users/joerg/src/maven-multimodule-test/child1/target/classes isn't a file.
- [Help 1]
{code}
Please find the attached sample project (file:
{{maven-multimodule-test.tar.gz}}) to reproduce the problem.
Project structure:
* Parent (Packaging: pom)
** Child1 (Packaging: jar)
** Child2 (Packaging: jar; Assembly to create distribution tar.gz)
*** Dependency to Child1
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
