[jira] [Commented] (MASSEMBLY-849) Add nonFilteredFileExtensions to avoid filtering of binary files
[ https://issues.apache.org/jira/browse/MASSEMBLY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16498441#comment-16498441 ] Brian Brooks commented on MASSEMBLY-849: +1 just wasted a couple of days dealing with an EXE corrupted by maven-assembly-plugin filtering a binary file. Seems like filtering binaries should be off bey default and require explicit configuration to enable such filtering. What is the use case for filtering a binary file? > Add nonFilteredFileExtensions to avoid filtering of binary files > > > Key: MASSEMBLY-849 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-849 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: filtering >Affects Versions: 3.0.0 >Reporter: Dennis Kieselhorst >Priority: Major > > nonFilteredFileExtensions should be added to assembly-plugin similar to the > param that exists in resources-plugin: > https://maven.apache.org/plugins/maven-resources-plugin/examples/binaries-filtering.html > Currently I have to double the fileSets with includes/excludes and filtered > true/false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MASSEMBLY-849) Add nonFilteredFileExtensions to avoid filtering of binary files
[ https://issues.apache.org/jira/browse/MASSEMBLY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16498441#comment-16498441 ] Brian Brooks edited comment on MASSEMBLY-849 at 6/1/18 7:28 PM: +1 just wasted a couple of days dealing with an EXE corrupted by maven-assembly-plugin filtering a binary file. Seems like filtering binaries should be off by default and require explicit configuration to enable such filtering. What is the use case for filtering a binary file? was (Author: bbrooks): +1 just wasted a couple of days dealing with an EXE corrupted by maven-assembly-plugin filtering a binary file. Seems like filtering binaries should be off bey default and require explicit configuration to enable such filtering. What is the use case for filtering a binary file? > Add nonFilteredFileExtensions to avoid filtering of binary files > > > Key: MASSEMBLY-849 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-849 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: filtering >Affects Versions: 3.0.0 >Reporter: Dennis Kieselhorst >Priority: Major > > nonFilteredFileExtensions should be added to assembly-plugin similar to the > param that exists in resources-plugin: > https://maven.apache.org/plugins/maven-resources-plugin/examples/binaries-filtering.html > Currently I have to double the fileSets with includes/excludes and filtered > true/false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-430) default excludes of Abstract*Test not working
[ https://issues.apache.org/jira/browse/SUREFIRE-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16105448#comment-16105448 ] Brian Brooks commented on SUREFIRE-430: --- Here is an updated permalink to the 2.4 Surefire release announcement http://maven.40175.n5.nabble.com/ANN-Maven-Surefire-Plugin-2-4-for-Maven-2-Released-tp207727.html > default excludes of Abstract*Test not working > - > > Key: SUREFIRE-430 > URL: https://issues.apache.org/jira/browse/SUREFIRE-430 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.4 > Environment: maven 2.0.7/2.08 >Reporter: Robert-Jan Peters >Priority: Critical > > The default excludes of Abstract Tests is not backward compatible. > version 2.3.1 >excludes = >new ArrayList( Arrays.asList( new String[] { > "**/Abstract*Test.java", > "**/Abstract*TestCase.java", "**/*$*" } ) > ); > version 2.4 >excludes = > new ArrayList( Arrays.asList( new String[] { "**/*$*" > } ) ); -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MENFORCER-248) Upgrading maven-enforcer-plugin to 1.4.1 breaks maven-assembly-plugin
[ https://issues.apache.org/jira/browse/MENFORCER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16101967#comment-16101967 ] Brian Brooks edited comment on MENFORCER-248 at 7/26/17 5:29 PM: - [~khmarbaise] We got bit by bug MENFORCER-248 as well when trying to upgrade to maven-enforcer-plugin 1.4.1 and maven-assembly-plugin 3.0.0. I see in https://issues.apache.org/jira/browse/MENFORCER-248?focusedCommentId=15169367&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15169367 that you said upgrading would fix this issue. Which upgraded components resolve MENFORCER-248? was (Author: bbrooks): [~khmarbaise] We got bit by bug MENFORCER-248 as well when trying to upgrade to maven-enforcer-plugin 1.4.1 and maven-assembly-plugin 3.0.0. I see in https://issues.apache.org/jira/browse/MENFORCER-248?focusedCommentId=15169367&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15169367 that you said upgraded would fix this issue. Which upgraded components resolve MENFORCER-248? > Upgrading maven-enforcer-plugin to 1.4.1 breaks maven-assembly-plugin > - > > Key: MENFORCER-248 > URL: https://issues.apache.org/jira/browse/MENFORCER-248 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Reporter: Blazej Checinski >Assignee: Karl Heinz Marbaise > Fix For: 1.4.1 > > Attachments: extjars.xml, pom.xml > > > After upgrading m-e-p from 1.4 to 1.4.1 the maven-assembly-plugin generates > the following error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single (assemble) on > project extjars: Execution assemble of goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. > NullPointerException -> [Help 1] > Downgrading to m-e-p 1.4 makes the assembly work again. > Sample pom & assembly that expose the error attached. > When called via: > mvn -Dplugins.maven-enforcer-plugin.version=1.4 > a zip file is generated as expected, when called via > mvn -Dplugins.maven-enforcer-plugin.version=1.4.1 > (or without argument) you will get the NPE. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MENFORCER-248) Upgrading maven-enforcer-plugin to 1.4.1 breaks maven-assembly-plugin
[ https://issues.apache.org/jira/browse/MENFORCER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16101967#comment-16101967 ] Brian Brooks commented on MENFORCER-248: [~khmarbaise] We got bit by bug MENFORCER-248 as well when trying to upgrade to maven-enforcer-plugin 1.4.1 and maven-assembly-plugin 3.0.0. I see in https://issues.apache.org/jira/browse/MENFORCER-248?focusedCommentId=15169367&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15169367 that you said upgraded would fix this issue. Which upgraded components resolve MENFORCER-248? > Upgrading maven-enforcer-plugin to 1.4.1 breaks maven-assembly-plugin > - > > Key: MENFORCER-248 > URL: https://issues.apache.org/jira/browse/MENFORCER-248 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Reporter: Blazej Checinski >Assignee: Karl Heinz Marbaise > Fix For: 1.4.1 > > Attachments: extjars.xml, pom.xml > > > After upgrading m-e-p from 1.4 to 1.4.1 the maven-assembly-plugin generates > the following error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single (assemble) on > project extjars: Execution assemble of goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. > NullPointerException -> [Help 1] > Downgrading to m-e-p 1.4 makes the assembly work again. > Sample pom & assembly that expose the error attached. > When called via: > mvn -Dplugins.maven-enforcer-plugin.version=1.4 > a zip file is generated as expected, when called via > mvn -Dplugins.maven-enforcer-plugin.version=1.4.1 > (or without argument) you will get the NPE. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MJAR-240) maven-jar-plugin index.html - bad links in left column Examples section
Brian Brooks created MJAR-240: - Summary: maven-jar-plugin index.html - bad links in left column Examples section Key: MJAR-240 URL: https://issues.apache.org/jira/browse/MJAR-240 Project: Maven JAR Plugin Issue Type: Bug Components: site Reporter: Brian Brooks Priority: Trivial At the site https://maven.apache.org/plugins/maven-jar-plugin/index.html in the leftColumn div there are some bad links # In leftColumn {{Creating an Executable JAR File}} {code} Creating an Executable JAR File {code} # In leftColumn {{Using Your Own Manifest File}}. Clicking on that hyperlink results in an HTTP 404 error. {code} Using Your Own Manifest File {code} # in [Usage|https://maven.apache.org/plugins/maven-jar-plugin/index.html#Usage] section hyperlink {{plugin's wiki page}} {code} http://docs.codehaus.org/display/MAVENUSER/JAR+Plugin";>plugin's wiki page {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MANTRUN-205) maven-antrun-plugin pages at maven.apache.org still have bad url codehaus references
Brian Brooks created MANTRUN-205: Summary: maven-antrun-plugin pages at maven.apache.org still have bad url codehaus references Key: MANTRUN-205 URL: https://issues.apache.org/jira/browse/MANTRUN-205 Project: Maven Antrun Plugin Issue Type: Bug Reporter: Brian Brooks Priority: Trivial Some of the maven-antrun-plugin web pages have old codehaus.org links: # http://maven.apache.org/plugins/maven-antrun-plugin/index.html bad link ## old: http://docs.codehaus.org/display/MAVENUSER/Antrun+Plugin ## new: ? maybe somewhere around https://cwiki.apache.org/confluence/display/MAVEN/? # http://maven.apache.org/plugins/maven-antrun-plugin/issue-tracking.html bad link ## old: http://jira.codehaus.org/browse/MANTRUN ## new: https://issues.apache.org/jira/projects/MANTRUN # http://maven.apache.org/plugins/maven-antrun-plugin/usage.html bad link ## old: http://mojo.codehaus.org/build-helper-maven-plugin/ ## new: http://www.mojohaus.org/build-helper-maven-plugin/ # http://maven.apache.org/plugins/maven-antrun-plugin/dependency-management.html bad link ## old: http://plexus.codehaus.org/plexus-containers/plexus-component-annotations/ ## new: http://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MRELEASE-947) wiki page url for maven-release-plugin is wrong - post codehaus termination
Brian Brooks created MRELEASE-947: - Summary: wiki page url for maven-release-plugin is wrong - post codehaus termination Key: MRELEASE-947 URL: https://issues.apache.org/jira/browse/MRELEASE-947 Project: Maven Release Plugin Issue Type: Bug Components: documentation Reporter: Brian Brooks Priority: Minor On the page https://maven.apache.org/maven-release/maven-release-plugin/ This link is invalid http://docs.codehaus.org/display/MAVENUSER/Release+Plugin It's referenced by this text "Usage General instructions on how to use the Release Plugin can be found on the usage page. Some more specific use cases are described in the examples given below. Last but not least, users occasionally contribute additional examples, tips or errata to the plugin's wiki page." The March 2015 thread between Herve Boutemy and Martin Gainty on the maven-dev mailing list seems to document the problem and provide the base URL for a new URL... {quote} > From: herve.bout...@free.fr > To: d...@maven.apache.org > Subject: Codehaus EOL and MAVENUSER Confluence Wiki > Date: Wed, 4 Mar 2015 02:20:09 +0100 > > Hi, > > I got a report from someone about links from Jira to old Codehaus MAVEN > Confluence Wiki [1]: I explained that we already copied the content to ASF > MAVENOLD [2] as read-only and copied useful content to ASF MAVEN [3] > > Then ok for Codehaus MAVEN Confluence Wiki. > > But what about Codehaus MAVENUSER Confluence Wiki [4]? > Is the whole content useful? Should we have the same strategy than MAVEN? Who > could do that? MG>http://docs.codehaus.org/display/MAVENUSER/Home;jsessionid=A686FD6E6C1DA1A824E695ABEB288143 MG>Codehaus content is useful..but will require resource who can understand and write legible cyrilic.. MG>Can Igor port the pages with cyrilic to ASF MAVEN[3]? > > Or should we only copy relevant pages to MAVEN? How to do that (I didn't find > any way to export even a simple page to later reimport) > > Any thoughts? > > Regards, > > Hervé > > > [1] http://docs.codehaus.org/display/MAVEN/ > > [2] https://cwiki.apache.org/confluence/display/MAVENOLD/ > > [3] https://cwiki.apache.org/confluence/display/MAVEN/ > > [4] http://docs.codehaus.org/display/MAVENUSER/ {quote} Source: https://mail-archives.apache.org/mod_mbox/maven-dev/201503.mbox/%3cblu172-w470a03aa20e3c140dadf55ae...@phx.gbl%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MNG-5682) Parent POMs not resolved in multi-module project
[ https://jira.codehaus.org/browse/MNG-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351861#comment-351861 ] Brian Brooks edited comment on MNG-5682 at 8/26/14 9:00 AM: I've encountered this error before and it was a copy-paste mistake when setting up a new project. My project layout looked like {noformat} \---super \---thirdparty +---mod1-root | +---mod1-linux32 | \---mod1-win32 \---mod2-root +---mod2-linux32 \---mod2-win32 {noformat} In my case, I had a mistake in my pom.xmls at the modX-root-level. I had copied the mod1-root tree and named it mod2-root. I thought I had updated all the pom.xmls appropriately. In fact, mod2-root/pom.xml had the same group and artifact ids as mod1-root/pom.xml. After correcting mod2-root's pom.xml to have mod2-root specific maven coordinates my issue was resolved. This info was originally posted by me here: http://stackoverflow.com/a/23201278/110126 was (Author: bbrooks): I've encountered this error before and it was a copy-paste mistake when setting up a new project. My project layout looked like \---super \---thirdparty +---mod1-root | +---mod1-linux32 | \---mod1-win32 \---mod2-root +---mod2-linux32 \---mod2-win32 In my case, I had a mistake in my pom.xmls at the modX-root-level. I had copied the mod1-root tree and named it mod2-root. I thought I had updated all the pom.xmls appropriately. In fact, mod2-root/pom.xml had the same group and artifact ids as mod1-root/pom.xml. After correcting mod2-root's pom.xml to have mod2-root specific maven coordinates my issue was resolved. This info was originally posted by me here: http://stackoverflow.com/a/23201278/110126 > Parent POMs not resolved in multi-module project > > > Key: MNG-5682 > URL: https://jira.codehaus.org/browse/MNG-5682 > Project: Maven > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 3.0.4, 3.1.1, 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) > Java version: 1.7.0_67, vendor: Oracle Corporation > Default locale: en_US, platform encoding: Cp1250 > OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" >Reporter: Kek >Priority: Critical > Attachments: test-project.zip > > > I have multi-module project - I attach the similar simple project structure > to this issue, to simulate the problem => !test-project.zip!. > The structure is: > {noformat} > A- aggregating project, parent for "parent" > |_parent - parent for B and C > |_B > |_C > {noformat} > In reality we have more parents under A for diferent types of A-submodules, > but now it does not matter. > When we run build under maven 2.2.1 - everything is OK, the reactor sorts > the projects like A, PARENT, B,C and build success. > When we run the same build under maven 3.x (3.0.4, 3.1.1, 3.2.3 was tested), > the build fails with following errors: > a>mvn clean > [INFO] Scanning for projects... > [ERROR] The build could not read 2 projects -> [Help 1] > [ERROR] > [ERROR] The project a:b:[unknown-version] (\a\b\pom.xml) has 1 error > [ERROR] Non-resolvable parent POM: Could not find artifact > a:parent:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local > POM @ line 6, column 10 -> [Help 2] > [ERROR] > [ERROR] The project a:c:[unknown-version] (\a\c\pom.xml) has 1 error > [ERROR] Non-resolvable parent POM: Could not find artifact > a:parent:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local > POM @ line 6, column 10 -> [Help 2] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException > [ERROR] [Help 2] > http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException > There is no explicit "relativePath" set in project POMs. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5682) Parent POMs not resolved in multi-module project
[ https://jira.codehaus.org/browse/MNG-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351861#comment-351861 ] Brian Brooks commented on MNG-5682: --- I've encountered this error before and it was a copy-paste mistake when setting up a new project. My project layout looked like \---super \---thirdparty +---mod1-root | +---mod1-linux32 | \---mod1-win32 \---mod2-root +---mod2-linux32 \---mod2-win32 In my case, I had a mistake in my pom.xmls at the modX-root-level. I had copied the mod1-root tree and named it mod2-root. I thought I had updated all the pom.xmls appropriately. In fact, mod2-root/pom.xml had the same group and artifact ids as mod1-root/pom.xml. After correcting mod2-root's pom.xml to have mod2-root specific maven coordinates my issue was resolved. This info was originally posted by me here: http://stackoverflow.com/a/23201278/110126 > Parent POMs not resolved in multi-module project > > > Key: MNG-5682 > URL: https://jira.codehaus.org/browse/MNG-5682 > Project: Maven > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 3.0.4, 3.1.1, 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) > Java version: 1.7.0_67, vendor: Oracle Corporation > Default locale: en_US, platform encoding: Cp1250 > OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" >Reporter: Kek >Priority: Critical > Attachments: test-project.zip > > > I have multi-module project - I attach the similar simple project structure > to this issue, to simulate the problem => !test-project.zip!. > The structure is: > {noformat} > A- aggregating project, parent for "parent" > |_parent - parent for B and C > |_B > |_C > {noformat} > In reality we have more parents under A for diferent types of A-submodules, > but now it does not matter. > When we run build under maven 2.2.1 - everything is OK, the reactor sorts > the projects like A, PARENT, B,C and build success. > When we run the same build under maven 3.x (3.0.4, 3.1.1, 3.2.3 was tested), > the build fails with following errors: > a>mvn clean > [INFO] Scanning for projects... > [ERROR] The build could not read 2 projects -> [Help 1] > [ERROR] > [ERROR] The project a:b:[unknown-version] (\a\b\pom.xml) has 1 error > [ERROR] Non-resolvable parent POM: Could not find artifact > a:parent:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local > POM @ line 6, column 10 -> [Help 2] > [ERROR] > [ERROR] The project a:c:[unknown-version] (\a\c\pom.xml) has 1 error > [ERROR] Non-resolvable parent POM: Could not find artifact > a:parent:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local > POM @ line 6, column 10 -> [Help 2] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException > [ERROR] [Help 2] > http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException > There is no explicit "relativePath" set in project POMs. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5181) New resolution from local repository is very confusing
[ https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336776#comment-336776 ] Brian Brooks commented on MNG-5181: --- The location of the maven 3.x compatibility notes referenced in the ticket have moved to https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes. > New resolution from local repository is very confusing > -- > > Key: MNG-5181 > URL: https://jira.codehaus.org/browse/MNG-5181 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3 >Reporter: Arnaud Heritier >Assignee: Olivier Lamy > Fix For: 3.1.0-alpha-1 > > > I just discover the change introduced in Maven 3.x to try to improve the > resolution mechanism and to avoid to use a local artifact which may not be > available in its remote repository : > https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository > Even if the feature is interesting it has several problems : > # When an artifact isn't accessible from its remote repository it isn't used > by maven which replies a classical "dependency not found error". It is really > annoying for a user with some Maven 2 skills which will have a look at his > local repo, will find the artifact and won't understand why Maven doesn't use > it. At least the error reported by Maven should be clear that even if the > dependency is available locally, it isn't used because it's remote repository > isn't available. > # This behavior cannot be configured to be only a warning for example. It is > really annoying because it doesn't take care of some context and constraints > we may have in a development team. Let's imagine that the remote artifact is > really removed. Cool Maven broke the build to warn us. But it brakes the > build of all the team whereas perhaps only one of them may try to solve the > issue (and it can be a long resolution). Thus having the ability to configure > if this control is blocker or warning may allow the team to configure it as > blocker on the CI server and as warning on the development environment. > # This behavior may introduce some bad practices for example when we are > using a staging feature on a repository manager. In our case my teams have a > dedicated profile to activate a staging repository when we are validating a > release. I recommend to not have this profile always activated but to do it > only on-demand to avoid them to DL staging stuffs they don't need. With this > new feature they need for all builds they run to activate this staging > profile while binaries are stored in it. When you have to do it 20 times per > day minimum let's imagine what the developer does : It adds it as an > alwaysActive profile and then forget to remove it when the release is ended. > For all these reason I would like we improve this feature to make it more > usable and before all bet understandable for ours users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-365) Filtered directory filesets try to include files from ancestor projects in a multi-module build
[ https://jira.codehaus.org/browse/MASSEMBLY-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334337#comment-334337 ] Brian Brooks commented on MASSEMBLY-365: I just lost an hour of time due to this defect. The ${basedir} workaround worked for me. > Filtered directory filesets try to include files from ancestor projects in a > multi-module build > --- > > Key: MASSEMBLY-365 > URL: https://jira.codehaus.org/browse/MASSEMBLY-365 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 2.2-beta-2 > Environment: Mac OS X 10.5.5, Java 1.5.0_16, Maven 2.0.9 >Reporter: Christopher Maier >Priority: Minor > Attachments: assembly-bug.tar.bz > > > When interpreting assembly descriptors, it looks like Maven is resolving > fileSet directories relative to where the build was started, rather than > relative to the project or module the descriptor is defined in. This might > cause problems in multi-module builds where a file exists in the same > directory listed in the descriptor, but in an ancestor module. The attached > file has a small project that illustrates this. This project has one > sub-module, in which an assembly descriptor is defined. It declares a > {{fileSet}}, using the {{directory}} tag, that points to {{src/main/shell}}. > There is a shell file here ({{b.sh}}) that is to be included in the assembly. > There is a also a {{src/main/shell}} directory in the parent project as > well, containing a file ({{a.sh}}) that does not exist in the shell directory > of the sub-module. The assembly plugin is attached to the package phase. > When the sub-module is built from its own directory, everything works as > expected. However, if it is built from the parent directory as part of a > reactor build, Maven complains that it cannot find {{a.sh}} in the > sub-module's {{src/main/shell directory}}. > This looks like it only happens if the assembly specifies that the > {{fileSet}} be filtered. > There is an easy workaround; instead of setting the directory as > {{src/main/shell}}, use {{${basedir}/src/main/shell}} in the assembly > descriptor. I discovered this behavior when I was transitioning one of my > projects from a single project to a multi-module project, and I left some > files behind in the new parent project. I'm going to get rid of those > eventually, and I realize this is probably a pathological structure, but this > behavior is unexpected and may impact other, less pathological projects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5026) Re-instate support of -Dorg.apache.maven.user-settings in MAVEN_OPTS
[ https://jira.codehaus.org/browse/MNG-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=303688#comment-303688 ] Brian Brooks edited comment on MNG-5026 at 7/16/12 1:45 PM: We're trying to upgrade from Maven 2.0.8 to 3.0.4 and encountered this same issue. We have a similar need to override the default location of settings.xml to be in a place that our corporate IT doesn't slow down builds by scanning for viruses. The IT dept excludes certain paths from virus scanning. Thus, we like to place all our build-related files including settings.xml in one of these excluded paths. @Benjamin MAVEN_ARGS would meet our needs. was (Author: bbrooks): We have a similar need to override the default location of settings.xml to be in a place that our corporate IT doesn't slow down builds by scanning for viruses. The IT dept excludes certain paths from virus scanning. Thus, we like to place all our build-related files including settings.xml in one of these excluded paths. @Benjamin MAVEN_ARGS would meet our needs. > Re-instate support of -Dorg.apache.maven.user-settings in MAVEN_OPTS > > > Key: MNG-5026 > URL: https://jira.codehaus.org/browse/MNG-5026 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.0.2 > Environment: All >Reporter: Tim Myerscough > > I've raised this in response to thread > http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html > My use case is that in my environment storing the settings.xml in the users > home directory is not desirable. The build environment can be shared across > different environments that do not share a common home directory. Instead, a > shared mount is used. > Having to maintain multiple copies of the settings.xml in multiple locations > is confusing and error prone for developers. And having to specify a -s > parameter on every command line, pointing at a long path, is undesirible. We > use both Windows and Linux, so aliasing isn't available. I'd like to use a > consistent approach across all environments, including Hudson builds where we > use multiple settings.xml. > Test case: > Create file ~/.m2/settings-alt.xml with contents: > > > > alt-settings > > true > > > > > > alt-settings > > set the MAVEN_OPTS environment variable > MAVEN_OPTS="-Dorg.apache.maven.user-settings=~/.m2/settings-alt.xml" > run: > $mvn help:effective-settings > It should include: > http://maven.apache.org/SETTINGS/1.1.0";> > env-dev > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5026) Re-instate support of -Dorg.apache.maven.user-settings in MAVEN_OPTS
[ https://jira.codehaus.org/browse/MNG-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=303688#comment-303688 ] Brian Brooks commented on MNG-5026: --- We have a similar need to override the default location of settings.xml to be in a place that our corporate IT doesn't slow down builds by scanning for viruses. The IT dept excludes certain paths from virus scanning. Thus, we like to place all our build-related files including settings.xml in one of these excluded paths. @Benjamin MAVEN_ARGS would meet our needs. > Re-instate support of -Dorg.apache.maven.user-settings in MAVEN_OPTS > > > Key: MNG-5026 > URL: https://jira.codehaus.org/browse/MNG-5026 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.0.2 > Environment: All >Reporter: Tim Myerscough > > I've raised this in response to thread > http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html > My use case is that in my environment storing the settings.xml in the users > home directory is not desirable. The build environment can be shared across > different environments that do not share a common home directory. Instead, a > shared mount is used. > Having to maintain multiple copies of the settings.xml in multiple locations > is confusing and error prone for developers. And having to specify a -s > parameter on every command line, pointing at a long path, is undesirible. We > use both Windows and Linux, so aliasing isn't available. I'd like to use a > consistent approach across all environments, including Hudson builds where we > use multiple settings.xml. > Test case: > Create file ~/.m2/settings-alt.xml with contents: > > > > alt-settings > > true > > > > > > alt-settings > > set the MAVEN_OPTS environment variable > MAVEN_OPTS="-Dorg.apache.maven.user-settings=~/.m2/settings-alt.xml" > run: > $mvn help:effective-settings > It should include: > http://maven.apache.org/SETTINGS/1.1.0";> > env-dev > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3068) Build extensions fail to load if not available locally and remote repo is defined in the same POM where the extension is defined
[ http://jira.codehaus.org/browse/MNG-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138553#action_138553 ] Brian Brooks commented on MNG-3068: --- Thanks for the guidance Brett, I was pretty confused with all the similarly named projects. I opened a defect in the Maven Integration for Eclipse project http://jira.codehaus.org/browse/MNGECLIPSE-684 > Build extensions fail to load if not available locally and remote repo is > defined in the same POM where the extension is defined > > > Key: MNG-3068 > URL: http://jira.codehaus.org/browse/MNG-3068 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.1 >Reporter: Vincent Massol >Assignee: John Casey > Fix For: 2.1-alpha-1 > > > * If you define the remote repo in settings.xml it works > * If you define it in the pom.xml file it doesn't work > For example, this fails if xwiki-build-xar-handlers isn't available in the > local repo: > {noformat} > > > > com.xpn.xwiki.platform > xwiki-build-xar-handlers > 1.0-SNAPSHOT > > > > > > xwiki > XWiki Maven2 Remote Repository > http://maven.xwiki.org > > true > > > true > > > > > {noformat} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3068) Build extensions fail to load if not available locally and remote repo is defined in the same POM where the extension is defined
[ http://jira.codehaus.org/browse/MNG-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138396#action_138396 ] Brian Brooks commented on MNG-3068: --- I see that this was fixed in 2.1 but I don't understand the relationship between that version and the Eclipse plugin version. I'm running the latest version of the Maven Integration for Eclipse from the update site http://m2eclipse.sonatype.org/update/ but I am still getting this problem. Sonatype, Inc. Maven Integration for Eclipse 0.9.4.20080603-0114 org.maven.ide.eclipse.feature Sonatype, Inc. Maven Integration for Eclipse 0.9.2.20080413-2321 org.maven.ide.eclipse.subclipse.feature Sonatype, Inc. Maven Integration for Eclipse 0.9.2.20080413-2321 org.maven.ide.eclipse.scm.feature Sonatype, Inc. Maven Integration for Eclipse 0.9.1.200803311600 org.maven.ide.eclipse.mylyn.feature I'm experiencing this problem on the sample tutorial project contained in the Spring-WS 1.5.2 download. http://sourceforge.net/project/showfiles.php?group_id=73357&package_id=178569&release_id=600343 When I try to import the samples/tutorial project, it fails on 'net.java.dev.jets3t:jets3t:pom:0.5.1-20080115' 6/12/08 4:09:51 PM EDT: [DEBUG] Reading global settings from: null 6/12/08 4:09:51 PM EDT: [DEBUG] Settings file is null. Returning null. 6/12/08 4:09:51 PM EDT: [DEBUG] Reading user settings from: C:\Documents and Settings\bb185056\.m2\settings.xml 6/12/08 4:09:51 PM EDT: [DEBUG] Scanning for extensions: C:\dat\workspace_lab\samples\tutorial\pom.xml 6/12/08 4:09:51 PM EDT: [DEBUG] Pre-scanning POM lineage of: C:\dat\workspace_lab\samples\tutorial\pom.xml for build extensions. 6/12/08 4:09:51 PM EDT: [DEBUG] Building model-lineage for: C:\dat\workspace_lab\samples\tutorial\pom.xml to pre-scan for extensions. 6/12/08 4:09:51 PM EDT: [DEBUG] Checking for external profiles in: C:\dat\workspace_lab\samples\tutorial\profiles.xml 6/12/08 4:09:51 PM EDT: [DEBUG] Checking for external profiles in: C:\dat\workspace_lab\samples\tutorial\..\profiles.xml 6/12/08 4:09:51 PM EDT: [DEBUG] Checking: org.springframework.ws:spring-ws-parent:pom:1.5.2 for extensions. (It has 0 modules.) 6/12/08 4:09:51 PM EDT: [DEBUG] Checking org.springframework.ws:spring-ws-parent:pom:1.5.2 for extensions. 6/12/08 4:09:51 PM EDT: [DEBUG] Adding extension: org.springframework.aws:spring-aws-maven from model: org.springframework.ws:spring-ws-parent:pom:1.5.2 6/12/08 4:09:51 PM EDT: [DEBUG] Starting extension-addition process for: org.springframework.aws:spring-aws-maven:jar:1.2.2 6/12/08 4:09:51 PM EDT: [DEBUG] Trying repository central 6/12/08 4:09:51 PM EDT: [DEBUG] Unable to get resource 'net.java.dev.jets3t:jets3t:pom:0.5.1-20080115' from repository central (http://repo1.maven.org/maven2) Unable to locate resource in repository 6/12/08 4:09:51 PM EDT: [DEBUG] Trying repository spring-milestone 6/12/08 4:09:51 PM EDT: [DEBUG] Unable to get resource 'net.java.dev.jets3t:jets3t:pom:0.5.1-20080115' from repository spring-milestone (http://s3.amazonaws.com/maven.springframework.org/milestone) Unable to locate resource in repository If I run maven from the command-line, I don't have any problems... C:\dat\workspace_lab\samples\tutorial>mvn help:active-profiles [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] artifact org.apache.maven.plugins:maven-help-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-help-plugin/2.0.2/maven-help-plugin-2.0.2.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-help-plugin/2.0.2/maven-help-plugin-2.0.2.jar 23K downloaded Downloading: http://s3.amazonaws.com/maven.springframework.org/milestone/net/java/dev/jets3t/jets3t/0.5.1-20080115/jets3t-0.5.1-20 080115.pom Downloading: http://s3.amazonaws.com/maven.springframework.org/release/net/java/dev/jets3t/jets3t/0.5.1-20080115/jets3t-0.5.1-2008 0115.pom Downloading: http://s3.amazonaws.com/maven.springframework.org/external/net/java/dev/jets3t/jets3t/0.5.1-20080115/jets3t-0.5.1-200 80115.pom 1K downloaded Downloading: http://s3.amazonaws.com/maven.springframework.org/milestone/net/java/dev/jets3t/jets3t/0.5.1-20080115/jets3t-0.5.1-20 080115.jar Downloading: http://s3.amazonaws.com/maven.springframework.org/release/net/java/dev/jets3t/jets3t/0.5.1-20080115/jets3t-0.5.1-2008 0115.jar Downloading: http://s3.amazonaws.com/maven.springframework.org/external/net/java/dev/jets3t/jets3t/0.5.1-20080115/jets3t-0.5.1-200 80115.jar 276K downloaded Downloading: http://s3.amazonaws.com/maven.springframework.org/milestone/commons-httpclient/commons-httpclient/3.1/commons-httpcli ent-3.1.jar Downloading: http://s3.amazonaws.com/maven.springframework.org/release/commons-httpclient/commons-httpclient/3.1/commons-h