[jira] (MNG-3695) Allow dependencies' scopes to be managed without explicit versions

2014-07-03 Thread Paul Benedict (JIRA) 

 [ 
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}
>   
> javax.mail
> mail
> provided
>   
> {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.(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

2014-07-03 Thread Paul Benedict (JIRA) 

 [ 
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

2014-07-03 Thread Paul Benedict (JIRA) 

 [ 
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

2014-07-03 Thread Paul Benedict (JIRA) 

 [ 
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

2014-07-03 Thread Paul Benedict (JIRA) 

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

2014-07-03 Thread Paul Benedict (JIRA) 

 [ 
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

2014-07-03 Thread Paul Benedict (JIRA) 

 [ 
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.:
> 
> ...
>  
>   
> ${jboss.home}/server/default/deploy/my.ear/my-exploded-ejb.jar
>  
> ...
> 
> 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

2014-07-03 Thread Robert Scholte (JIRA) 

 [ 
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}
>  
>   
>   central
>   Maven Plugin Repository
>   http://repo1.maven.org/maven2
>   default
> 
>   
>   {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

2014-07-03 Thread Robert Scholte (JIRA) 

 [ 
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 .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 
>  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  section.
> The  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  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

2014-07-03 Thread Karl-Heinz Marbaise (JIRA) 

 [ 
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

2014-07-03 Thread Herve Boutemy (JIRA) 

 [ 
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\trunk>C:\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(MojoExecuto

[jira] (MNG-5605) ssh-wagon hangs

2014-07-03 Thread Arnaud Brunet (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

2014-07-03 Thread Karl-Heinz Marbaise (JIRA) 

[ 
https://jira.codehaus.org/browse/MASSEMBLY-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)