[jira] (MNG-5598) Environment variables must be written in UPPER CASE
Markus KARG created MNG-5598:
Summary: Environment variables must be written in UPPER CASE
Key: MNG-5598
URL: https://jira.codehaus.org/browse/MNG-5598
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0.4
Environment: Windows
Reporter: Markus KARG
On Windows, it is valid and common practice to defined environment variables
with mixed case names, e. g. SystemDrive, SystemRoot, ProgramData, etc.
When writing this mixed case names in the POM.exe, these cannot be resolved but
will be used as string literals. For example, the popular exec plugin from
codehaus mojo project complains it cannot find the executable at LITERALLY
${env.MSDevDir}/Bin/MSDEV.exe, while actually that variable is defined in
exactly that mixed case name, and points to the existing executable. Once
MSDevDir is replaced in the (wrong!) UPPER CASE form of ${env.MSDEVDIR}, then
the executable is found, which is weird!
While the MavenPropertiesGuide
(http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide) actually only
shows examples using UPPER CASE environment variables, it does not clearly say
that this is an enforced restriction. Hence, either this is a bug in the Maven
software (i. e. it unintentionally expects UPPER CASE), or it is to be clearly
said in the properties guide that UPPER CASE is a wanted constrained of Maven.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342735#comment-342735
]
Michael Zav'yalov commented on MNG-5435:
But question, for my case - why the second build was successful? I would expect
more stable result...
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom .. SUCCESS [6.835s]
> [INFO] foo-module SUCCESS [1.327s]
> [INFO] bar-module SUCCESS [0.090s]
> [INFO] baz-module FAILURE [0.012s]
> This seems to avoid issue #1 as it doesn't complain about missing Antlr
> artifacts anymore but it gets stuck on the baz-module with the error:
> [ERROR] Failed to execute goal on project baz-module: Could not resolve
> dependencies for project com.acme:baz-module:jar:4.0.0-SNAPSHOT: The
> following artifacts could not be resolved:
> com.acme:foo-module:jar:4.0.0-SNAPSHOT,
> com.acme:bar-module:jar:4.0.0-SNAPSHOT: Could not find artifact
> com.acme:foo-module:jar:4.0.0-SNAPSHOT -> [Help 1]
> In our real projects there are many mo
[jira] (MPMD-181) Add flag to capture Benchmark information
[ https://jira.codehaus.org/browse/MPMD-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MPMD-181. Resolution: Fixed Assignee: Dennis Lundberg Patch applied with modifications in r1576238. Thanks! The name and property for the output file are now in sync. The code was adjusted to comply with our code style. I also added a couple of ITs. > Add flag to capture Benchmark information > - > > Key: MPMD-181 > URL: https://jira.codehaus.org/browse/MPMD-181 > Project: Maven PMD Plugin > Issue Type: New Feature > Components: PMD >Affects Versions: 3.0.1 >Reporter: Anthony Whitford >Assignee: Dennis Lundberg > Fix For: 3.1 > > Attachments: mpmd-181.diff > > > PMD 5 has a capability to capture Benchmark information. This information > can be useful to diagnose where time is being spent. > I would like to see this feature exposed from the plugin. It can be disabled > by default, but it would be really handy to diagnose slow runs. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-183) Multiple programming language support
[ https://jira.codehaus.org/browse/MPMD-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342741#comment-342741 ] Dennis Lundberg commented on MPMD-183: -- The plugin currently supports Java and Javascript. Can you give us an example project that has files for other languages in it, that we can use to test this out? It would also be good if you could try to show us what the future configuration for this should look like. > Multiple programming language support > - > > Key: MPMD-183 > URL: https://jira.codehaus.org/browse/MPMD-183 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.0.1 >Reporter: Andrey Utis > > Currently PMD supports multiple languages (with 5.1.0 it supports even more). > But the only way to run the PMD plugin for multiple languages is to run > multiple executions. It would be great to be able to configure multiple > languages within one execution. Example: a project that contains Java, > JavaScript, Velocity templates, and PL/SQL code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-182) upgrade to last 5.1.0
[ https://jira.codehaus.org/browse/MPMD-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MPMD-182: - Fix Version/s: 3.2 > upgrade to last 5.1.0 > - > > Key: MPMD-182 > URL: https://jira.codehaus.org/browse/MPMD-182 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Olivier Lamy > Fix For: 3.2 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5576) Allow continuous delivery friendly versions
[
https://jira.codehaus.org/browse/MNG-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342744#comment-342744
]
Jason van Zyl commented on MNG-5576:
I mean more that once you have built it there is no rebuild. More akin to
having used a snapshot and then turned it into a release artifact. Essentially
you build a stream of binaries and then select one based on its merit. At that
point you don't rebuild it. This is not really how Maven currently works.
> Allow continuous delivery friendly versions
> ---
>
> Key: MNG-5576
> URL: https://jira.codehaus.org/browse/MNG-5576
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.1.1
>Reporter: Jason van Zyl
> Fix For: 3.2.1
>
>
> Currently warnings will be emitted when there are expressions in versions, a
> few exceptions should be deemed valid to make continuous delivery easier. The
> use case is to allow easy versioning of an entire multi-module build that can
> take a version from an external source like SCM. These are the types of
> exceptions that will be allowed:
> 1.0.0.$\{changelist}
> 1.0.0.$\{revision}
> 1.0.0.$\{sha1}
> When a whole build is versioned like this we can avoid churning the POMs in
> the SCM which makes it a lot easier to see the actual changes in the project.
> Not a complete solution for continuous delivery but is a step in the right
> direction and doesn't interfere with currently behavior as it is currently
> allowed, just warned against.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-543) prepare-with-pom : inherited dependencies exclusion are lost in release-pom.xml
[ https://jira.codehaus.org/browse/MRELEASE-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342745#comment-342745 ] Sergei Ivanov commented on MRELEASE-543: One more case for placing a wildcard exclusion on each top-level dependency. If project's dependencies use version ranges for transitive dependencies, this seems to be somehow affecting the version resolution for direct dependencies, even when the direct dependencies have fixed versions in the release POM. Using wildcard exclusions would ensure that only the specific fixed versions of direct dependencies were included into the project based on the release POM. > prepare-with-pom : inherited dependencies exclusion are lost in > release-pom.xml > --- > > Key: MRELEASE-543 > URL: https://jira.codehaus.org/browse/MRELEASE-543 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare-with-pom >Affects Versions: 2.0 > Environment: Maven 2.2.1 >Reporter: Thomas Sauzedde > Attachments: sample-projects.tgz > > > Like in the provided sample projects, I have the following scenario : 3 > modules (sibling) with the following inheritage graph : > grandfather <=== father <=== child > - grandfather (pom module) has > - a dependencyManagement block with some exclusions > - a pluginManagement block > - father (pom module) adds a plugins block to configure the compiler plugin > - child is a basic (empty) jar module > when mvn release:prepare-with-pom is performed on "child" the checked-in > (svn) release-pom.xml has all the dependencies resolved BUT my exclusions > defined in "grandfather" are lost :-( > To reproduce this with the provided sample projects : > - perform a mvn:install on grandfather & father > - import "child" in your svn repo > - change the scm block on "child" in order to checkout/in from your svn > - perform a mvn release:prepare-with-pom > You will see that in your tagged release-pom.xml the exclusions are lost. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5599) Using -am and -amd does not include all necessary dependencies
Christopher Mosher created MNG-5599: --- Summary: Using -am and -amd does not include all necessary dependencies Key: MNG-5599 URL: https://jira.codehaus.org/browse/MNG-5599 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.2.1 Reporter: Christopher Mosher Attachments: mvn_amd_bug.tar.gz If I have a module APP1 that depends on two other modules LIB1 and LIB2, all in multi-mode project, and I try to rebuild LIB1 with -am and -amd, then when maven tries to build APP1 (due to -amd), it cannot find LIB2, and the build fails with "The POM for LIB2 is missing". See attached project for use case (test.sh). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-669) dependencySet does not resolve transient dependencies in reactor build
[ https://jira.codehaus.org/browse/MASSEMBLY-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph updated MASSEMBLY-669: Attachment: assembly_bug_v2.tar.gz updated example with corrected version ranges and different artifact versions > dependencySet does not resolve transient dependencies in reactor build > -- > > Key: MASSEMBLY-669 > URL: https://jira.codehaus.org/browse/MASSEMBLY-669 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.2-beta-5, 2.4 > Environment: linux >Reporter: Christoph > Attachments: assembly_bug.tar.gz, assembly_bug_v2.tar.gz > > > using an assembly descriptor with a dependencySet will fail to resolve > transient dependencies that are build in the same reactor. > having artifacts one, two, three. With a dependeny chain: three -> two -> one > Artifact three runs an assembly during package phase. It succeeds in finding > the artifact two in the reactor. But the transient dependency pointing to > artifact one can't be resolved. > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-assembly) on > project three: Failed to create assembly: Unable to resolve dependencies for > assembly 'foo': Failed to resolve dependencies for assembly: No versions are > present in the repository for the artifact with a range [0,] > [ERROR] de.gsi.cs.co.maven.assembly_bug:one:jar:null > A sample project structure is attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-669) dependencySet does not resolve transient dependencies in reactor build
[ https://jira.codehaus.org/browse/MASSEMBLY-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph reopened MASSEMBLY-669: - The example has been corrected but the problem persists. Now each project in the reactor uses it's own version. As it's only an example we have independent versioning on submodules. > dependencySet does not resolve transient dependencies in reactor build > -- > > Key: MASSEMBLY-669 > URL: https://jira.codehaus.org/browse/MASSEMBLY-669 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.2-beta-5, 2.4 > Environment: linux >Reporter: Christoph > Attachments: assembly_bug.tar.gz, assembly_bug_v2.tar.gz > > > using an assembly descriptor with a dependencySet will fail to resolve > transient dependencies that are build in the same reactor. > having artifacts one, two, three. With a dependeny chain: three -> two -> one > Artifact three runs an assembly during package phase. It succeeds in finding > the artifact two in the reactor. But the transient dependency pointing to > artifact one can't be resolved. > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-assembly) on > project three: Failed to create assembly: Unable to resolve dependencies for > assembly 'foo': Failed to resolve dependencies for assembly: No versions are > present in the repository for the artifact with a range [0,] > [ERROR] de.gsi.cs.co.maven.assembly_bug:one:jar:null > A sample project structure is attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-489) Failure to locate component descriptors in another project
[
https://jira.codehaus.org/browse/MASSEMBLY-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MASSEMBLY-489.
-
Resolution: Not A Bug
> Failure to locate component descriptors in another project
> --
>
> Key: MASSEMBLY-489
> URL: https://jira.codehaus.org/browse/MASSEMBLY-489
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.2-beta-5
> Environment: Apache Maven 3.0-beta-1 (r935667; 2010-04-19
> 19:00:39+0200)
> Java version: 1.6.0_20
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux" version: "2.6.31-22-generic" arch: "i386" Family: "unix"
>Reporter: Andreas Sewe
> Attachments: aggregator.tar.gz, aggregator.tar.gz
>
>
> The {{maven-assembly-plugin}} seems to search for component descriptors in
> the current project instead of in the one containing the assembly descriptors
> which do the referring. This behavior is probably a bug and makes it quite
> impossible to use such a modularized assembly descriptor from a different
> project.
> The attached multi-module project exemplifies this; just run "mvn install"
> from the aggregator project and you will get the following stack trace:
> {quote}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single
> (default) on project problematic-module: Error reading assemblies: Failed to
> locate component descriptor: src/main/resources/assemblies/component.xml
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:141)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:190)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:246)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:95)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:430)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:160)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:124)
> 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.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:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error reading
> assemblies: Failed to locate component descriptor:
> src/main/resources/assemblies/component.xml
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:356)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133)
> ... 19 more
> Caused by: org.apache.maven.plugin.assembly.io.AssemblyReadException: Failed
> to locate component descriptor: src/main/resources/assemblies/component.xml
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.mergeComponentsWithMainAssembly(DefaultAssemblyReader.java:452)
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssembly(DefaultAssemblyReader.java:366)
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyForDescriptorReference(DefaultAssemblyReader.java:257)
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:149)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:352)
> ... 21 more
> [ERROR]
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-489) Failure to locate component descriptors in another project
[
https://jira.codehaus.org/browse/MASSEMBLY-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342762#comment-342762
]
Karl Heinz Marbaise commented on MASSEMBLY-489:
---
First your example project does not work via {{mvn clean package}} it simply
fails with the following:
{code}
[INFO] Aggregator Project SUCCESS [ 0.141 s]
[INFO] Problematic Module FAILURE [ 1.697 s]
[INFO] Descriptor Project SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.228 s
[INFO] Finished at: 2014-03-11T19:51:14+01:00
[INFO] Final Memory: 16M/981M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack
(unpack-shared-resources) on project problematic-module: Unable to find
artifact. Could not find artifact
org.example:descriptor-module:jar:0.0.2-SNAPSHOT in nexus
(http://localhost:8081/nexus/content/groups/public)
[ERROR]
[ERROR] Try downloading the file manually from the project website.
[ERROR]
[ERROR] Then, install it using the command:
[ERROR] mvn install:install-file -DgroupId=org.example
-DartifactId=descriptor-module -Dversion=0.0.2-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file
[ERROR]
[ERROR] Alternatively, if you host your own repository you can deploy the file
there:
[ERROR] mvn deploy:deploy-file -DgroupId=org.example
-DartifactId=descriptor-module -Dversion=0.0.2-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
{code}
This gives me the impressions that this multi-module build is simply broken.
The most important thing is that the descriptor module is build after the
problematic module which means there is no dependency given between the modules
which is absolutly necessary.
A multi-module build must be workgin out of the box with an empty local
repository just simply {{mvn clean package}}.
First question. Are you aware of the [documentation about sharing
descriptors|https://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html]
?
After checking your example project [i have fixed several issues and got a
working
example|https://github.com/khmarbaise/massembly/tree/master/massembly-489]
without any problems.
This means i will close the issue. if you have any objections please don't
hesitate to reopen the bug and may be you can send pull-request to change the
example project in the way you like.
> Failure to locate component descriptors in another project
> --
>
> Key: MASSEMBLY-489
> URL: https://jira.codehaus.org/browse/MASSEMBLY-489
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.2-beta-5
> Environment: Apache Maven 3.0-beta-1 (r935667; 2010-04-19
> 19:00:39+0200)
> Java version: 1.6.0_20
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux" version: "2.6.31-22-generic" arch: "i386" Family: "unix"
>Reporter: Andreas Sewe
> Attachments: aggregator.tar.gz, aggregator.tar.gz
>
>
> The {{maven-assembly-plugin}} seems to search for component descriptors in
> the current project instead of in the one containing the assembly descriptors
> which do the referring. This behavior is probably a bug and makes it quite
> impossible to use such a modularized assembly descriptor from a different
> project.
> The attached multi-module project exemplifies this; just run "mvn install"
> from the aggregator project and you will get the following stack trace:
> {quote}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single
> (default) on project problematic-module: Error reading assemblies: Failed to
> locate component descriptor: src/main/resources/assemblies/component.xml
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:141)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218)
> at
> org.apache.m
[jira] (MASSEMBLY-628) Bogus warning when assembling to a directory
[ https://jira.codehaus.org/browse/MASSEMBLY-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342764#comment-342764 ] Karl Heinz Marbaise commented on MASSEMBLY-628: --- As i mentioned you need a separate execution block and separate descriptors and yes you can reuse the descriptors by component descriptors. [Take a look into the example.|https://github.com/khmarbaise/massembly/tree/master/massembly-628]. > Bogus warning when assembling to a directory > > > Key: MASSEMBLY-628 > URL: https://jira.codehaus.org/browse/MASSEMBLY-628 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: c:\Users\visola\Downloads\springsource\apache-maven-3.0.3 > Java version: 1.6.0_32, vendor: Sun Microsystems Inc. > Java home: c:\Program Files\Java\jdk1.6.0_32\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > maven-assembly-plugin:2.3 >Reporter: Vinicius Isola > Attachments: test.zip > > > When adding a "dir" format to the assembly file, it will output a bogus > warning like the following: > [WARNING] Assembly file: c:\Users\visola\temp\test\target\test-1.0.0 is not a > regular file (it may be a directory). It cannot be attached to the project > build for installation or deployment. > I think it is related to bug: http://jira.codehaus.org/browse/MASSEMBLY-289 > Attached is an example project that can reproduce the problem just running > "mvn clean install" -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-628) Bogus warning when assembling to a directory
[ https://jira.codehaus.org/browse/MASSEMBLY-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342764#comment-342764 ] Karl Heinz Marbaise edited comment on MASSEMBLY-628 at 3/11/14 3:16 PM: As i mentioned you need a separate execution block and separate descriptors and yes you can reuse the descriptors by component descriptors. [Take a look into the example.|https://github.com/khmarbaise/massembly/tree/master/massembly-628]. If you have further question please go via the users mailing list. was (Author: khmarbaise): As i mentioned you need a separate execution block and separate descriptors and yes you can reuse the descriptors by component descriptors. [Take a look into the example.|https://github.com/khmarbaise/massembly/tree/master/massembly-628]. > Bogus warning when assembling to a directory > > > Key: MASSEMBLY-628 > URL: https://jira.codehaus.org/browse/MASSEMBLY-628 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: c:\Users\visola\Downloads\springsource\apache-maven-3.0.3 > Java version: 1.6.0_32, vendor: Sun Microsystems Inc. > Java home: c:\Program Files\Java\jdk1.6.0_32\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > maven-assembly-plugin:2.3 >Reporter: Vinicius Isola > Attachments: test.zip > > > When adding a "dir" format to the assembly file, it will output a bogus > warning like the following: > [WARNING] Assembly file: c:\Users\visola\temp\test\target\test-1.0.0 is not a > regular file (it may be a directory). It cannot be attached to the project > build for installation or deployment. > I think it is related to bug: http://jira.codehaus.org/browse/MASSEMBLY-289 > Attached is an example project that can reproduce the problem just running > "mvn clean install" -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-644) Exclusions in dependencySet inside moduleSet->binaries have no effect
[
https://jira.codehaus.org/browse/MASSEMBLY-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MASSEMBLY-644:
--
Description:
I'm trying to create a distribution assembly of a multi-module project in a
separate distribution module which works quite nice, except that exclusions of
dependencies of modules seem to be ignored. This is strange, as the same
exclusions do work in an assembly inside a submodule.
This is the problematic descriptor:
{code}
lwjgl
zip
false
true
com.ardor3d:ardor3d-animation
com.ardor3d:ardor3d-awt
com.ardor3d:ardor3d-collada
com.ardor3d:ardor3d-core
com.ardor3d:ardor3d-effects
com.ardor3d:ardor3d-extras
com.ardor3d:ardor3d-lwjgl
com.ardor3d:ardor3d-math
com.ardor3d:ardor3d-savable
com.ardor3d:ardor3d-swt
com.ardor3d:ardor3d-terrain
com.ardor3d:ardor3d-ui
false
*:lwjgl*natives-*
*:jinput*natives-*
target/natives
natives
*jogl*
*nativewindow*
*newt*
*gluegen*
META-INF/
{code}
This assembly descriptor can be found here:
https://github.com/neothemachine/Ardor3D/blob/assembly/ardor3d-distribution/assembly-lwjgl.xml
It produces a zip which also contains "lwjgl-platform-2.8.4-natives-linux.jar"
and others which should be matched by the filter.
The submodule where the exclusions work can be found at:
https://github.com/neothemachine/Ardor3D/tree/assembly/ardor3d-examples
If you need any other information, please tell me.
was:
I'm trying to create a distribution assembly of a multi-module project in a
separate distribution module which works quite nice, except that exclusions of
dependencies of modules seem to be ignored. This is strange, as the same
exclusions do work in an assembly inside a submodule.
This is the problematic descriptor:
{{
lwjgl
zip
false
true
com.ardor3d:ardor3d-animation
com.ardor3d:ardor3d-awt
com.ardor3d:ardor3d-collada
com.ardor3d:ardor3d-core
com.ardor3d:ardor3d-effects
com.ardor3d:ardor3d-extras
com.ardor3d:ardor3d-lwjgl
com.ardor3d:ardor3d-math
com.ardor3d:ardor3d-savable
com.ardor3d:ardor3d-swt
com.ardor3d:ardor3d-terrain
com.ardor3d:ardor3d-ui
false
*:lwjgl*natives-*
*:jinput*natives-*
target/natives
natives
*jogl*
*nativewindow*
*newt*
*gluegen*
META-INF/
}}
This assembly descriptor can be found here:
https://github.com/neothemachine/Ardor3D/blob/ass
[jira] (SUREFIRE-1068) forkNumber in systemPropertyVariables requires prefix
[
https://jira.codehaus.org/browse/SUREFIRE-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pederson updated SUREFIRE-1068:
Description:
The {surefire.forkNumber} placeholder cannot be used alone in a
{{systemPropertyVariable}}. The workaround is to prefix the value.
For example, this doesn't work (the {{surefire.forkNumber}} system property
does not exist when running the test).
{code:xml}
${surefire.forkNumber}
{code}
But this does:
{code:xml}
0${surefire.forkNumber}
{code}
(note the leading *0*)
was:
If {{${surefire.forkNumber} }} is used alone in a {{systemPropertyVariable}} it
resolves as null. Workaround is to prefix the value.
For example, this doesn't work (the {{surefire.forkNumber}} system property
does not exist).
{code:xml}
${surefire.forkNumber}
{code}
But this does:
{code:xml}
0${surefire.forkNumber}
{code}
(note the leading *0*)
> forkNumber in systemPropertyVariables requires prefix
> -
>
> Key: SUREFIRE-1068
> URL: https://jira.codehaus.org/browse/SUREFIRE-1068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Eric Pederson
>Priority: Minor
>
> The {surefire.forkNumber} placeholder cannot be used alone in a
> {{systemPropertyVariable}}. The workaround is to prefix the value.
> For example, this doesn't work (the {{surefire.forkNumber}} system property
> does not exist when running the test).
> {code:xml}
>
> ${surefire.forkNumber}
>
> {code}
> But this does:
> {code:xml}
>
> 0${surefire.forkNumber}
>
> {code}
> (note the leading *0*)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1068) forkNumber in systemPropertyVariables requires prefix
Eric Pederson created SUREFIRE-1068:
---
Summary: forkNumber in systemPropertyVariables requires prefix
Key: SUREFIRE-1068
URL: https://jira.codehaus.org/browse/SUREFIRE-1068
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.16
Reporter: Eric Pederson
Priority: Minor
If {{${surefire.forkNumber} }} is used alone in a {{systemPropertyVariable}} it
resolves as null. Workaround is to prefix the value.
For example, this doesn't work (the {{surefire.forkNumber}} system property
does not exist).
{code:xml}
${surefire.forkNumber}
{code}
But this does:
{code:xml}
0${surefire.forkNumber}
{code}
(note the leading *0*)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1068) forkNumber in systemPropertyVariables requires prefix
[
https://jira.codehaus.org/browse/SUREFIRE-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pederson updated SUREFIRE-1068:
Description:
The {{$\{surefire.forkNumber\}}} placeholder cannot be used alone in a
{{systemPropertyVariable}}. The workaround is to prefix the value.
For example, this doesn't work (the {{surefire.forkNumber}} system property
does not exist when running the test).
{code:xml}
${surefire.forkNumber}
{code}
But this does:
{code:xml}
0${surefire.forkNumber}
{code}
(note the leading *0*)
was:
The {surefire.forkNumber} placeholder cannot be used alone in a
{{systemPropertyVariable}}. The workaround is to prefix the value.
For example, this doesn't work (the {{surefire.forkNumber}} system property
does not exist when running the test).
{code:xml}
${surefire.forkNumber}
{code}
But this does:
{code:xml}
0${surefire.forkNumber}
{code}
(note the leading *0*)
> forkNumber in systemPropertyVariables requires prefix
> -
>
> Key: SUREFIRE-1068
> URL: https://jira.codehaus.org/browse/SUREFIRE-1068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Eric Pederson
>Priority: Minor
>
> The {{$\{surefire.forkNumber\}}} placeholder cannot be used alone in a
> {{systemPropertyVariable}}. The workaround is to prefix the value.
> For example, this doesn't work (the {{surefire.forkNumber}} system property
> does not exist when running the test).
> {code:xml}
>
> ${surefire.forkNumber}
>
> {code}
> But this does:
> {code:xml}
>
> 0${surefire.forkNumber}
>
> {code}
> (note the leading *0*)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-740) Maven Release Plugin releases SNAPSHOT instead of STABLE version
[ https://jira.codehaus.org/browse/SCM-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342765#comment-342765 ] Cédric Jonas commented on SCM-740: -- Any news about this issue? Will there be a release including this fix soon? Or is a workaround available? Thanks! > Maven Release Plugin releases SNAPSHOT instead of STABLE version > > > Key: SCM-740 > URL: https://jira.codehaus.org/browse/SCM-740 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 > (and maybe older) >Reporter: Jan Novotný > Attachments: Wrong_base_directory_used1.patch > > > If you have following project structure: > - superproject [Git repository root] > - projectA [release target] > - projectB [release target] > in other words you release subproject of a larger Git repository separately, > you probably run at the same issue as we did. No recipe from above mentioned > sources solves your problems and during release:prepare phase still no commit > of stable pom.xml occurs. There is another bug in GitStatusConsumer class > that checks output of the git status --porcelain command and verifies > existency of the mentioned files on local filesystem. Regretfully it uses > working directory instead of git repository root as the base folder and thus > it constructs invalid path to the file where project folder directory is > duplicated. > Problem is better described here: > http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-669) dependencySet does not resolve transient dependencies in reactor build
[
https://jira.codehaus.org/browse/MASSEMBLY-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MASSEMBLY-669.
-
Resolution: Not A Bug
Unfortunately i have to say that one very important thing about your
assumptions is incorrect:
The senctence:
{{using an assembly descriptor with a dependencySet will fail to resolve
transient dependencies that are build in the same reactor}}
These artifacts are not build in the same reactor. This is only an aggregator
and *not* an multi-module build.
Apart from that if you take a look at the error message:
{{Unable to resolve dependencies for assembly 'foo': Failed to resolve
dependencies for assembly: No versions are present in the repository for the
artifact with a range [0,]}}
This shows that the build is trying to solve the artifacts from the repository
as a result of not finding them within the current reactor.
An indicator for a multi-module build is the verison number which is identical
for all modules etc. within the same folder structure (parent, modules etc.)
which is *not* the case with your example. You have the same parent but the
versions are different. The conclusion of this is that you neither have an
aggregator nor an multi-module buld.
You can find it out via first doing:
{{mvn install -N} from the root of your project.
{{mvn install}} from module one.
{{mvn install}} from module two and finally:
{{mvn package}} from module threeor after installing module two going to
the root and do {{mvn clean package}} which will works.
So the result of this is: It's not bug, cause you are not building in the same
reactor.
> dependencySet does not resolve transient dependencies in reactor build
> --
>
> Key: MASSEMBLY-669
> URL: https://jira.codehaus.org/browse/MASSEMBLY-669
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.2-beta-5, 2.4
> Environment: linux
>Reporter: Christoph
> Attachments: assembly_bug.tar.gz, assembly_bug_v2.tar.gz
>
>
> using an assembly descriptor with a dependencySet will fail to resolve
> transient dependencies that are build in the same reactor.
> having artifacts one, two, three. With a dependeny chain: three -> two -> one
> Artifact three runs an assembly during package phase. It succeeds in finding
> the artifact two in the reactor. But the transient dependency pointing to
> artifact one can't be resolved.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-assembly) on
> project three: Failed to create assembly: Unable to resolve dependencies for
> assembly 'foo': Failed to resolve dependencies for assembly: No versions are
> present in the repository for the artifact with a range [0,]
> [ERROR] de.gsi.cs.co.maven.assembly_bug:one:jar:null
> A sample project structure is attached.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-689) Upgrade documentation according to best practice
Karl Heinz Marbaise created MASSEMBLY-689:
-
Summary: Upgrade documentation according to best practice
Key: MASSEMBLY-689
URL: https://jira.codehaus.org/browse/MASSEMBLY-689
Project: Maven Assembly Plugin
Issue Type: Improvement
Components: site
Affects Versions: 2.4
Reporter: Karl Heinz Marbaise
Priority: Minor
Currently the docs say things like this:
{{It is common practice to create an assembly using the parent POM of a
multimodule build. At times, you may want to ensure that this assembly also
includes one or more of the module binaries.}} which is not best practice so it
should be replaced by better explanations and the best practice.
(http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5599) Using -am and -amd does not include all necessary dependencies
[ https://jira.codehaus.org/browse/MNG-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342767#comment-342767 ] Michael Osipov commented on MNG-5599: - I have observed the same problem. The reactor modules are ignored. > Using -am and -amd does not include all necessary dependencies > -- > > Key: MNG-5599 > URL: https://jira.codehaus.org/browse/MNG-5599 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.1 >Reporter: Christopher Mosher > Attachments: mvn_amd_bug.tar.gz > > > If I have a module APP1 that depends on two other modules LIB1 and LIB2, all > in multi-mode project, and I try to rebuild LIB1 with -am and -amd, then when > maven tries to build APP1 (due to -amd), it cannot find LIB2, and the build > fails with "The POM for LIB2 is missing". See attached project for use case > (test.sh). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5598) Environment variables must be written in UPPER CASE
[
https://jira.codehaus.org/browse/MNG-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342768#comment-342768
]
Michael Osipov commented on MNG-5598:
-
What is your problem actually? There is no {{POM.exe}}.
> Environment variables must be written in UPPER CASE
> ---
>
> Key: MNG-5598
> URL: https://jira.codehaus.org/browse/MNG-5598
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
> Environment: Windows
>Reporter: Markus KARG
>
> On Windows, it is valid and common practice to defined environment variables
> with mixed case names, e. g. SystemDrive, SystemRoot, ProgramData, etc.
> When writing this mixed case names in the POM.exe, these cannot be resolved
> but will be used as string literals. For example, the popular exec plugin
> from codehaus mojo project complains it cannot find the executable at
> LITERALLY ${env.MSDevDir}/Bin/MSDEV.exe, while actually that variable is
> defined in exactly that mixed case name, and points to the existing
> executable. Once MSDevDir is replaced in the (wrong!) UPPER CASE form of
> ${env.MSDEVDIR}, then the executable is found, which is weird!
> While the MavenPropertiesGuide
> (http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide) actually
> only shows examples using UPPER CASE environment variables, it does not
> clearly say that this is an enforced restriction. Hence, either this is a bug
> in the Maven software (i. e. it unintentionally expects UPPER CASE), or it is
> to be clearly said in the properties guide that UPPER CASE is a wanted
> constrained of Maven.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-644) Exclusions in dependencySet inside moduleSet->binaries have no effect
[
https://jira.codehaus.org/browse/MASSEMBLY-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342769#comment-342769
]
Karl Heinz Marbaise commented on MASSEMBLY-644:
---
The [documenation
describes|http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_moduleSet]
the format as follows:
{quote}
{{groupId:artifactId}} or may be fully qualified in the
form {{groupId:artifactId:type\[:classifier\]:version}}.
Additionally, wildcards can be used, as in *:maven-*
{quote}
BTW: Where did you find those things in the code? Can you give some detailed
locations?
Would you suggest to improve the docs? Yes than it would be nice to open a
separate JIRA issue. Apart from that i assume based on your explanations this
is not a bug so i can close the issue. If you have further information or any
objections please don't hesitate to reopen the issue.
> Exclusions in dependencySet inside moduleSet->binaries have no effect
> -
>
> Key: MASSEMBLY-644
> URL: https://jira.codehaus.org/browse/MASSEMBLY-644
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering, moduleSet
>Affects Versions: 2.4
>Reporter: Maik Riechert
>
> I'm trying to create a distribution assembly of a multi-module project in a
> separate distribution module which works quite nice, except that exclusions
> of dependencies of modules seem to be ignored. This is strange, as the same
> exclusions do work in an assembly inside a submodule.
> This is the problematic descriptor:
> {code}
>
>
> lwjgl
>
> zip
>
> false
>
>
> true
>
> com.ardor3d:ardor3d-animation
> com.ardor3d:ardor3d-awt
> com.ardor3d:ardor3d-collada
> com.ardor3d:ardor3d-core
> com.ardor3d:ardor3d-effects
> com.ardor3d:ardor3d-extras
> com.ardor3d:ardor3d-lwjgl
> com.ardor3d:ardor3d-math
> com.ardor3d:ardor3d-savable
> com.ardor3d:ardor3d-swt
> com.ardor3d:ardor3d-terrain
> com.ardor3d:ardor3d-ui
>
>
> false
>
>
>
>
> *:lwjgl*natives-*
>
> *:jinput*natives-*
>
>
>
>
>
>
>
>
> target/natives
> natives
>
> *jogl*
> *nativewindow*
> *newt*
> *gluegen*
> META-INF/
>
>
>
>
> {code}
> This assembly descriptor can be found here:
> https://github.com/neothemachine/Ardor3D/blob/assembly/ardor3d-distribution/assembly-lwjgl.xml
> It produces a zip which also contains
> "lwjgl-platform-2.8.4-natives-linux.jar" and others which should be matched
> by the filter.
> The submodule where the exclusions work can be found at:
> https://github.com/neothemachine/Ardor3D/tree/assembly/ardor3d-examples
> If you need any other information, please tell me.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-644) Exclusions in dependencySet inside moduleSet->binaries have no effect
[
https://jira.codehaus.org/browse/MASSEMBLY-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MASSEMBLY-644.
-
Resolution: Not A Bug
> Exclusions in dependencySet inside moduleSet->binaries have no effect
> -
>
> Key: MASSEMBLY-644
> URL: https://jira.codehaus.org/browse/MASSEMBLY-644
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering, moduleSet
>Affects Versions: 2.4
>Reporter: Maik Riechert
>
> I'm trying to create a distribution assembly of a multi-module project in a
> separate distribution module which works quite nice, except that exclusions
> of dependencies of modules seem to be ignored. This is strange, as the same
> exclusions do work in an assembly inside a submodule.
> This is the problematic descriptor:
> {code}
>
>
> lwjgl
>
> zip
>
> false
>
>
> true
>
> com.ardor3d:ardor3d-animation
> com.ardor3d:ardor3d-awt
> com.ardor3d:ardor3d-collada
> com.ardor3d:ardor3d-core
> com.ardor3d:ardor3d-effects
> com.ardor3d:ardor3d-extras
> com.ardor3d:ardor3d-lwjgl
> com.ardor3d:ardor3d-math
> com.ardor3d:ardor3d-savable
> com.ardor3d:ardor3d-swt
> com.ardor3d:ardor3d-terrain
> com.ardor3d:ardor3d-ui
>
>
> false
>
>
>
>
> *:lwjgl*natives-*
>
> *:jinput*natives-*
>
>
>
>
>
>
>
>
> target/natives
> natives
>
> *jogl*
> *nativewindow*
> *newt*
> *gluegen*
> META-INF/
>
>
>
>
> {code}
> This assembly descriptor can be found here:
> https://github.com/neothemachine/Ardor3D/blob/assembly/ardor3d-distribution/assembly-lwjgl.xml
> It produces a zip which also contains
> "lwjgl-platform-2.8.4-natives-linux.jar" and others which should be matched
> by the filter.
> The submodule where the exclusions work can be found at:
> https://github.com/neothemachine/Ardor3D/tree/assembly/ardor3d-examples
> If you need any other information, please tell me.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-388) sourceFileIncludes/Excludes are ineffective
[ https://jira.codehaus.org/browse/MJAVADOC-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342771#comment-342771 ] Benson Margulies commented on MJAVADOC-388: --- The problem is this line: List packageNames = getPackageNames( sourcePaths, files ); once packageNames it set, then the explicit file name list is ignored. > sourceFileIncludes/Excludes are ineffective > --- > > Key: MJAVADOC-388 > URL: https://jira.codehaus.org/browse/MJAVADOC-388 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Benson Margulies > > It is claimed that these options don't work. I will create an IT and either > fix this or close it. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-388) sourceFileIncludes/Excludes are ineffective
[ https://jira.codehaus.org/browse/MJAVADOC-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MJAVADOC-388: -- Attachment: MJAVADOC-388-it.patch > sourceFileIncludes/Excludes are ineffective > --- > > Key: MJAVADOC-388 > URL: https://jira.codehaus.org/browse/MJAVADOC-388 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Benson Margulies > Attachments: MJAVADOC-388-it.patch > > > It is claimed that these options don't work. I will create an IT and either > fix this or close it. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-388) sourceFileIncludes/Excludes are ineffective
[ https://jira.codehaus.org/browse/MJAVADOC-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342771#comment-342771 ] Benson Margulies edited comment on MJAVADOC-388 at 3/11/14 8:54 PM: The problem is this line: List packageNames = getPackageNames( sourcePaths, files ); This sets 'packageNames', unconditionally. Then, later on, if packageNames is sets, the code ignores the file list and just uses the package list. It's as if the author of the subsequent if statement thought that 'packageNames' corresponded to some explicit configuration instead of being calculated from the sourcePaths and the files. was (Author: bmargulies): The problem is this line: List packageNames = getPackageNames( sourcePaths, files ); once packageNames it set, then the explicit file name list is ignored. > sourceFileIncludes/Excludes are ineffective > --- > > Key: MJAVADOC-388 > URL: https://jira.codehaus.org/browse/MJAVADOC-388 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Benson Margulies > Attachments: MJAVADOC-388-it.patch > > > It is claimed that these options don't work. I will create an IT and either > fix this or close it. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-388) sourceFileIncludes/Excludes are ineffective
Benson Margulies created MJAVADOC-388: - Summary: sourceFileIncludes/Excludes are ineffective Key: MJAVADOC-388 URL: https://jira.codehaus.org/browse/MJAVADOC-388 Project: Maven Javadoc Plugin Issue Type: Bug Reporter: Benson Margulies It is claimed that these options don't work. I will create an IT and either fix this or close it. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
