[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=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=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=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=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=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=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=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=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-tabpanelfocusedCommentId=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:
amvn 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-tabpanelfocusedCommentId=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:
amvn 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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: settings profiles profile idalt-settings/id properties is-alttrue/is-alt /properties /profile /profiles activeProfiles activeProfilealt-settings/activeProfile /activeProfiles 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: activeProfiles xmlns=http://maven.apache.org/SETTINGS/1.1.0; activeProfileenv-dev/activeProfile /activeProfiles -- 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-tabpanelfocusedCommentId=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: settings profiles profile idalt-settings/id properties is-alttrue/is-alt /properties /profile /profiles activeProfiles activeProfilealt-settings/activeProfile /activeProfiles 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: activeProfiles xmlns=http://maven.apache.org/SETTINGS/1.1.0; activeProfileenv-dev/activeProfile /activeProfiles -- 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-tabpanelfocusedCommentId=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}
build
extensions
extension
groupIdcom.xpn.xwiki.platform/groupId
artifactIdxwiki-build-xar-handlers/artifactId
version1.0-SNAPSHOT/version
/extension
/extensions
/build
repositories
repository
idxwiki/id
nameXWiki Maven2 Remote Repository/name
urlhttp://maven.xwiki.orglt;/url
releases
enabledtrue/enabled
/releases
snapshots
enabledtrue/enabled
/snapshots
/repository
/repositories
/project
{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-tabpanelfocusedCommentId=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=73357package_id=178569release_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\tutorialmvn 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:
