[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=355299#comment-355299 ] Devin Reid edited comment on MNG-5682 at 10/30/14 10:46 PM: Ran in to this issue as well. This is documented behavior as indicated by [Maven 3.x compatiblity notes|https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ParentPOMResolution]. bq. Maven 3 no longer resolves parent POMs from the local project checkout unless the child POM's element is accurate, whether explicitly given or using the default value. This improves consistency regarding the build result when building the child project in isolation and when performing a reactor build that includes the parent project. In Maven 2, building the child project in isolation could fail while the reactor build would succeed to resolve the parent. The reasoning behind this doesn't make sense to me. This change impacts projects that want to "opt-out" of the of the relativePath functionality (i.e. set for parents in child poms) . If I set relativePath to be no path I certainly want the pom to be resolved from the reactor. More over it makes parent poms behavior as a dependency inconsistent with how every other dependency in Maven works. The reason stated that behavior was inconsistent between isolated and reactor builds but I disagree. It was entirely consistent. Using the sample project attached to this issue as an example, if B has a dependency on C, it will fail to build in isolation if C hasn't been installed in exactly the same way it will fail to build if 'parent' hadn't been installed. That is consistent and the way Maven 2 worked. In Maven 3, if parent isn't already installed a reactor build fails, even thought the same would not be true if C were not already installed. Even worse, if parent is installed and I make changes to the working copy those changes are not picked up by dependents even though parent is in the reactor. Very inconsistent behavior. I would hope that this new behavior for parent resolution could be rolled back in its entirety, but a less drastic change would be to allow resolving a parent from the reactor when 'relativePath' is set to null/empty. At least that would allow projects to 'opt-out' as before. was (Author: devman07): Ran in to this issue as well. This is documented behavior as indicated by [Maven 3.x compatiblity notes|https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ParentPOMResolution]. bq. Maven 3 no longer resolves parent POMs from the local project checkout unless the child POM's element is accurate, whether explicitly given or using the default value. This improves consistency regarding the build result when building the child project in isolation and when performing a reactor build that includes the parent project. In Maven 2, building the child project in isolation could fail while the reactor build would succeed to resolve the parent. The reasoning behind this doesn't make sense to me. This change impacts projects that want to "opt-out" of the of the relativePath functionality (i.e. set for parents in child poms) . If I set relativePath to be no path I certainly want the pom to be resolved from the reactor. More over it makes parent poms behavior as a dependency inconsistent with how every other dependency in Maven works. The reason stated that behavior was inconsistent between isolated and reactor builds but I disagree. It was entirely consistent. Using the sample project attached to this issue as an example, if B has a dependency on C, it will fail to build in isolation if C hasn't been installed in exactly the same way it will fail to build if 'parent' hadn't been installed. That is consistent and the way Maven 2 worked. Now if parent isn't installed a reactor build fails, even thought the same would not be true if C were not installed. Even worse, if parent is installed and I make changes to it those changes are not picked up by dependents even though parent is in the reactor. Very inconsistent behavior. I would hope that this new behavior for parent resolution could be rolled back in its entirety, but a less drastic change would be to allow resolving a parent from the reactor when 'relativePath' is set to null/empty. At least that would allow projects to 'opt-out' as before. > 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
[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=355299#comment-355299
]
Devin Reid commented on MNG-5682:
-
Ran in to this issue as well. This is documented behavior as indicated by
[Maven 3.x compatiblity
notes|https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ParentPOMResolution].
bq. Maven 3 no longer resolves parent POMs from the local project checkout
unless the child POM's element is accurate, whether explicitly
given or using the default value. This improves consistency regarding the build
result when building the child project in isolation and when performing a
reactor build that includes the parent project. In Maven 2, building the child
project in isolation could fail while the reactor build would succeed to
resolve the parent.
The reasoning behind this doesn't make sense to me. This change impacts
projects that want to "opt-out" of the of the relativePath functionality (i.e.
set for parents in child poms) . If I set relativePath to be
no path I certainly want the pom to be resolved from the reactor. More over it
makes parent poms behavior as a dependency inconsistent with how every other
dependency in Maven works.
The reason stated that behavior was inconsistent between isolated and reactor
builds but I disagree. It was entirely consistent. Using the sample project
attached to this issue as an example, if B has a dependency on C, it will fail
to build in isolation if C hasn't been installed in exactly the same way it
will fail to build if 'parent' hadn't been installed. That is consistent and
the way Maven 2 worked. Now if parent isn't installed a reactor build fails,
even thought the same would not be true if C were not installed. Even worse, if
parent is installed and I make changes to it those changes are not picked up by
dependents even though parent is in the reactor. Very inconsistent behavior.
I would hope that this new behavior for parent resolution could be rolled back
in its entirety, but a less drastic change would be to allow resolving a parent
from the reactor when 'relativePath' is set to null/empty. At least that would
allow projects to 'opt-out' as before.
> 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: Minor
> 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] (SCM-508) Wrong scm url validation for mercurial provider
[ https://jira.codehaus.org/browse/SCM-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343127#comment-343127 ] Devin Reid commented on SCM-508: Just got bit by this one. localCheckout=true is not working on Windows. Same error as commented above. > Wrong scm url validation for mercurial provider > --- > > Key: SCM-508 > URL: https://jira.codehaus.org/browse/SCM-508 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Reporter: Alexander Nemish > Fix For: 1.x > > Attachments: SCM-508-maven-scm-provider-hg.patch > > > According to documentation (http://maven.apache.org/scm/mercurial.html) scm > url can be of this form: > scm:hg:file://C:/dev/project/v3 > but it doesn't work due to a bug in > https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.2/maven-scm-providers/maven-scm-provider-hg/src/main/java/org/apache/maven/scm/provider/hg/HgScmProvider.java > private HgUrlParserResult parseScmUrl( String scmSpecificUrl ) > line 104: if ( !url.startsWith( "file:///" ) && !url.startsWith( > "file://localhost/" ) ) > The fix might be the following (like in svn provider) > line 104: if ( !url.startsWith( "file://" ) && !url.startsWith( > "file://localhost/" ) ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIA-498) PegDownProcessor parsing timeout makes builds non-deterministic.
Devin Reid created DOXIA-498: Summary: PegDownProcessor parsing timeout makes builds non-deterministic. Key: DOXIA-498 URL: https://jira.codehaus.org/browse/DOXIA-498 Project: Maven Doxia Issue Type: Bug Components: Module - Markdown Affects Versions: 1.4 Environment: Linux, Oracle Java 1.7.0_25 Reporter: Devin Reid Priority: Critical Parsing timeout given to PegDownProcessor should be set to Long.MAX_VALUE. The default value is 2000 (2 seconds) which means that builds of large sites will spuriously fail when built on slower computers. The parsing timeout is a security feature for use when offering Markdown parsing as a service taking user input, since this use case doesn't apply to a Maven build setting the timeout to Long.MAX_VALUE effectively disables the timeout. -- 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] (MDEP-427) Add user property for addParentPoms option
Devin Reid created MDEP-427: --- Summary: Add user property for addParentPoms option Key: MDEP-427 URL: https://jira.codehaus.org/browse/MDEP-427 Project: Maven Dependency Plugin Issue Type: New Feature Components: copy-dependencies Affects Versions: 2.8 Reporter: Devin Reid An boolean option to include parent poms for the copy-dependenices mojo was added to 2.8, but did not include a way to set the option from the command line. An user property should be added that sets this options. My suggestion is "mdep.addParentPoms" to match the style of the other user options. -- 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-5185) Improve "missing dependency" error message when _maven.repositories contains other repository ids than requested
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320576#comment-320576
]
Devin Reid commented on MNG-5185:
-
When I'm using a corporate repository, all maven artifact resolution gets
proxied through the corporate repository so the ability to turn off individual
repositories by id is of limited utility to users with that workflow because
they only have one repository id (configured as a mirror with
* in settings.xml).
What -Dmaven.legacyLocalRepository restores, for me at least, is the ability to
stage an offline build for a project on a connected box and then move the
project and the local repository to another box with no network access (and
likely no maven settings configuration) and still be able to build the project
in offline mode.
> Improve "missing dependency" error message when _maven.repositories contains
> other repository ids than requested
>
>
> Key: MNG-5185
> URL: https://jira.codehaus.org/browse/MNG-5185
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.0.2, 3.0.3, 3.0.4
>Reporter: Mark Derricutt
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
> Attachments:
> 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
>
>
> Based on a discussion on the users list [1], Maven 3 has changed how it
> resolves artifacts from remote repositories. Unfortunately, when "conflicts"
> arise ( GAV is cached in local repo, but POM has no matching repository id
> declared ), Maven just tells the user that the artifact could not be resolved.
> This leads to confusion from users who find the .jar files in their local
> repository, and they just get frustrated and complain that "maven sucks".
> It would be good if Maven was updated with some improved error messages along
> the lines of:
> "The {GAV} artifact was found in your local repository, but came from the
> undeclared repository "xxx", either configure this in your pom with {insert
> sample XML block in error message}, or in your "yyy" mirror."
> The "mirror" section of the error message should be included -if- the current
> ~/.m2/settings.xml declares a mirror. By improving the messages here we can
> help the users move on to building software, rather than pulling out their
> hair :)
> [1]
> http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
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-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=316700#comment-316700 ] Devin Reid commented on MNG-5181: - This feature makes creating portable offline builds require more steps than it did in Maven2. In Maven2 you could do a build using a custom 'maven.repo.local' property and then tar up the whole project, move it to a new box without network access, and have the project build fine offline. Now you either have to strip all the _maven.repository files manually or configure mirrors on a box that has no network access anyway. Would it be possible to have this feature disabled for --offline (-o) builds, or perhaps provide another mechanism for disabling this. > 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: Jason van Zyl > > 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: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories conflict
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305575#comment-305575
]
Devin Reid commented on MNG-5185:
-
Just got bit by this one. I have using '-Dmaven.repo.local' option to create
portable builds for working on non-networked (default settings.xml on those
boxes) computers and spent about an hour scratching my head as to why this
didn't work with Maven3. After deleting all the _maven.repositories it finally
worked. This new 'feature' really introduces some headaches for certain uses of
maven3.
So +1 for improving the error message.
bonus points if this feature could be disabled for offline "mvn -o" builds
entirely.
> Improve "missing dependency" error message when _maven.repositories conflict
>
>
> Key: MNG-5185
> URL: https://jira.codehaus.org/browse/MNG-5185
> Project: Maven 2 & 3
> Issue Type: Improvement
>Reporter: Mark Derricutt
> Attachments:
> 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
>
>
> Based on a discussion on the users list [1], Maven 3 has changed how it
> resolves artifacts from custom repositories. Unfortunately, when conflicts
> arise ( GAV is in local repo, but POM has no matching repository id declared
> ) Maven just tells the user that the artifact could not be resolved.
> This leads to confusion from users who find the .jar files in their local
> repository, and they just get frustrated and complain that "maven sucks".
> It would be good if Maven was updated with some improved error messages along
> the lines of:
> "The {GAV} artifact was found in your local repository, but came from the
> undeclared repository "xxx", either configure this in your pom with {insert
> sample XML block in error message}, or in your "yyy" mirror."
> The "mirror" section of the error message should be included -if- the current
> ~/.m2/settings.xml declares a mirror. By improving the messages here we can
> help the users move on to building software, rather than pulling out their
> hair :)
> [1]
> http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
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: (MDEP-82) go-offline / resolve-plugins does not resolve all plugin dependencies
[ https://jira.codehaus.org/browse/MDEP-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271956#comment-271956 ] Devin Reid commented on MDEP-82: A workaround I have found for this issue is to run a build with the property 'maven.repo.local' set to a directory in the project base directory and run a build to the install phase. One can then archive the resulting project and move it to environments that have no network access and be able to build successfully with the '-o' option. I've tested this successfully with Maven 2.2.1 and Maven 3.0.3. First run: mvn -Dmaven.repo.local=lib clean install Now the following command will work just fine. mvn -Dmaven.repo.local=lib -o clean install > go-offline / resolve-plugins does not resolve all plugin dependencies > - > > Key: MDEP-82 > URL: https://jira.codehaus.org/browse/MDEP-82 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: go-offline, resolve-plugins >Affects Versions: 2.0-alpha-4 > Environment: Maven 2.0.6 >Reporter: Arne Degenring >Assignee: Brian Fox > Attachments: pom.xml > > > The attached pom.xml is a very simple JAR project, without any direct > dependencies or plugin dependencies. > Start with an empty local repository, and run mvn dependency:go-offline on > it. Some files get downloaded, but not everything that is needed for the > build. If you run "mvn -o package" afterwards, you end up with the following > error: > [ERROR] BUILD ERROR > [INFO] > > [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not > exist or no valid version could be found > Afterwards, even "mvn package" without the "-o" parameter does not work any > longer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-177) add target option to go-offline goal
[ http://jira.codehaus.org/browse/MDEP-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206032#action_206032 ] Devin Reid commented on MDEP-177: - A feature like this would be extremely useful for projects that need to be rebuilt offsite from normal development on secure networks. > add target option to go-offline goal > > > Key: MDEP-177 > URL: http://jira.codehaus.org/browse/MDEP-177 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: go-offline >Affects Versions: 2.0 >Reporter: Antony Stubbs >Assignee: Brian Fox > > Say I want to make it so that maven can work completely offline, just from > someone checking out the project from source control. That means all > dependencies must be under source control. > the only way to do this, as far as I know, is to rename your repository dir, > run the go-offline goal, and then copy all contents of the repo into your > project, add the repo location to you project pom and commit. The big problem > with this of course is that maven has to go fetch everything from the net, > and that its a pain to do more than once (i.e. when plugin versions change, > as copy-dependencies already outputs to target/dependencies) > What would be much nicer, and easier to maintain, would be if there was a > target option for go-offline. That way, i could set the 'target' to > /mavenProjectRepo and *everything* needed to run maven on the project would > be installed into that dir, from the local maven repo, or downloaded if > required. > Hope I was clear, let me know if you want clarification. -- 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
