[jira] (MNG-5569) JAVA_HOME "Program Files (x86)" gives error
[ https://jira.codehaus.org/browse/MNG-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340224#comment-340224 ] Casper Roubos commented on MNG-5569: Hi, thanks for the quick reply. I have one remark, though: I have changed the JAVA_HOME to "d:\data\java\jdk1.6.0_45", so with double quotes aswell. And then it did work. Why is there a problem with double quotes with "program files (x86)" and not with "data\java"? > JAVA_HOME "Program Files (x86)" gives error > --- > > Key: MNG-5569 > URL: https://jira.codehaus.org/browse/MNG-5569 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Command Line > Environment: Apache Maven 3.1.1 > (0728685237757ffbf44136acec0402957f723d9a; 2013-09- > Maven home: d:\DATA\apache-maven-3.1.1\bin\.. > Java version: 1.6.0_45, vendor: Sun Microsystems Inc. > Java home: d:\data\java\jdk1.6.0_45\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" 64-bit >Reporter: Casper Roubos >Assignee: Robert Scholte > > _as_ a programmer with a Windows 7 64-bits OS, > _I want_ Maven to work with a JAVA_HOME path containing "c:\Program Files > (x86)\Java\jdk1.6.0_45", > _so that_ I do not get a wierd error like "Files not expected at this time" > * Unzip maven-3.1.1.zip in a folder like "d:\data\maven-3.1.1" > * Install JDK at "c:\Program Files (x86)\Java" > * set JAVA_HOME accordingly" > * enter "mvn --version" > ** _result_: an error "Files not expected at this time" > ** _expected_: maven returning the version details > * Copy JDK to an other directory, like "d:\data\Java\jdk1.6.0_45" > * set JAVA_HOME accordingly > ** _result_: maven returning the version details > ** _conclusion_: maven does not like "c:\Program Files (x86)\Java" -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[ https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340225#comment-340225 ] Wiebke Timm commented on MNG-1388: -- Requesting to reopen this issue as well. We are using maven for native packages and need to workaround this issue. We have classifiers for the different platforms (win32-x86 and linux-gcc) and common packages/headers (classifier "header"). Please fix this! > Transitive Dependencies in a profile are not used > - > > Key: MNG-1388 > URL: https://jira.codehaus.org/browse/MNG-1388 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows XP using Maven 2.0. >Reporter: Damian Bradicich > Fix For: Issues to be reviewed for 3.x > > > I have a jar project file that defines a dependency inside a certain profile. > If I then include that project inside of another war project, the > dependencies defined in the jar project's profile isn't getting transferred > over to the war. > Ie we have this: > A depends on SQL or Oracle depending on profile > B depends on A. > If sql profile is active, I would expect that when I build B, it pulls > the transitive dependancy on sql from A. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[ https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340226#comment-340226 ] Jörg Schaible commented on MNG-1388: Use properties for the classifier of those native artifacts and set those in the profiles. > Transitive Dependencies in a profile are not used > - > > Key: MNG-1388 > URL: https://jira.codehaus.org/browse/MNG-1388 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows XP using Maven 2.0. >Reporter: Damian Bradicich > Fix For: Issues to be reviewed for 3.x > > > I have a jar project file that defines a dependency inside a certain profile. > If I then include that project inside of another war project, the > dependencies defined in the jar project's profile isn't getting transferred > over to the war. > Ie we have this: > A depends on SQL or Oracle depending on profile > B depends on A. > If sql profile is active, I would expect that when I build B, it pulls > the transitive dependancy on sql from A. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-405) Preemptive authentication still not working with Maven 3.0.4+
[ https://jira.codehaus.org/browse/WAGON-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340227#comment-340227 ] Konrad Windszus commented on WAGON-405: --- The documentation about the default behaviour was updated at [1]. Thanks a lot for that. But the example at [2] still does not work for Maven 3.0.4+. Could someone with write access to that page add the example from the comment above and add a hint, that this will enable preemptive authentication for GET as well. Maybe there could be some more information added to [3] about the different configuration options for the HTTP wagon provider? [1] - http://maven.apache.org/guides/mini/guide-http-settings.html#Maven_3.0.4 [2] - http://maven.apache.org/guides/mini/guide-http-settings.html#Example:_Using_Preemptive_Authentication [3] - http://maven.apache.org/wagon/wagon-providers/wagon-http/ > Preemptive authentication still not working with Maven 3.0.4+ > - > > Key: WAGON-405 > URL: https://jira.codehaus.org/browse/WAGON-405 > Project: Maven Wagon > Issue Type: Bug >Reporter: Konrad Windszus > Attachments: WAGON-405-MVN3.1.1.log > > > Although by default the preemptive authentication should work now with Maven > 3.0.4, a wireshare dump exposes, that each request for downloading a new > dependency does not initially come with the authentication header. Only after > Nexus replied with a 401 the right credentials are set in the authentication > header. According to [1], since Maven 3.0.4 the default HTTP wagon uses > preemptive authentication which cannot be disabled [2]. Even with Maven 3.1.1 > it does not work. > [1] - http://maven.apache.org/guides/mini/guide-http-settings.html#Maven_3.0.4 > [2] - > http://maven.40175.n5.nabble.com/Maven-3-0-4-preemptive-auth-problem-tt5470892.html#none -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-681) plugin ignores empty finalName and uses default value
[
https://jira.codehaus.org/browse/MASSEMBLY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340228#comment-340228
]
Paul Millar commented on MASSEMBLY-681:
---
If I've understood you correctly, maven mojo XML parser simply ignores empty
elements. If so, this sounds like a bug as an empty element is both valid and
distinct from that element being missing.
To me, introducing a noFinalName flag looks like a work-around for this
XML-parser bug. As the problem isn't urgent (at least, for me), perhaps it
would be better to fix the mojo XML parser so empty XML elements are not
ignored.
> plugin ignores empty finalName and uses default value
> -
>
> Key: MASSEMBLY-681
> URL: https://jira.codehaus.org/browse/MASSEMBLY-681
> Project: Maven Assembly Plugin
> Issue Type: Wish
>Affects Versions: 2.4
>Reporter: Paul Millar
>Priority: Minor
>
> When used in the 'dir' format, I would argue that an empty finalName is
> reasonable.
> For example, I would expect the following configuration, with the 'dir'
> format, to output the assembled files in ${foo.baseDirectory}
>
>
> src/main/assembly/foo.xml
>
> ${foo.baseDirectory}
>
>
> The actual behaviour is to silently ignore the configured empty finalName and
> use the default finalName value, which is append this to the outputDirectory.
> Arguably there are two bugs here:
> finalName is silently ignored (if this is invalid, it should report an
> error)
> the empty finalName is not honoured.
> Specify '.' as the finalName (.) seems to work as a
> work-around, at least for unix-like systems.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5188) Test scope dependency incorrectly promoted to compile scope
[ https://jira.codehaus.org/browse/MNG-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340231#comment-340231 ] Kai Lehmann commented on MNG-5188: -- As I'm not owner of this task, I cannot reopen. I'll crete a new task. > Test scope dependency incorrectly promoted to compile scope > --- > > Key: MNG-5188 > URL: https://jira.codehaus.org/browse/MNG-5188 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.3 > Environment: Linux 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 > UTC 2011 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_23" > OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre10-0ubuntu5) > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) >Reporter: Harald Wellmann > Attachments: junit-transitive.zip > > > I'm having a strange issue where a module with three dependencies has an > unexpected transitive dependency on JUnit with compile scope (where test > scope would be expected). > I've isolated this problem in a small example project which is attached. > My module2 depends on > 1) module1 > 2) test-deps > 3) module1:test-jar > module1 depends on Apache OpenJPA which has a compile scope transitive > dependency on JUnit (not really needed, I think, but that's the way it was > released). module1 also has a test scope dependency on JUnit for its own > JUnit tests. > As I don't want a compile scope dependency on JUnit in my module2, I use an > for JUnit. > test-deps has POM packaging, it simply collects the test dependencies I > normally need in all modules of my project. test-deps uses the default > compile scope for each dependency (junit and spring-test in this example). > module2 has a test scope dependency on test-deps, so by Maven transitive > scope resolution, the junit dependency is propagated to module2 with test > scope. > Since some of the module2 JUnit tests are derived from base classes in module > 1, module2 depends on the test-jar of module1 with scope test. > Thus, none of the three dependencies should cause a compile scope dependency > on junit, but the combination of the three seems to have some fatal effect. > This looks like a bug in Maven's dependency scope resolution. > To reproduce, unpack the attachment, cd to junit-transitive, run mvn -X clean > install and look at the compile classpath for module2 in the log. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[ https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340230#comment-340230 ] Iain Coulter commented on MNG-1388: --- Using properties for the classifiers is not a complete solution if your building a multi platorm relase. ie selecting both win32-x86 and linux-gcc (from Wiebkes post) using profiles for each then the property for the classifier in first profile will be overwritten by the property in the second! > Transitive Dependencies in a profile are not used > - > > Key: MNG-1388 > URL: https://jira.codehaus.org/browse/MNG-1388 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows XP using Maven 2.0. >Reporter: Damian Bradicich > Fix For: Issues to be reviewed for 3.x > > > I have a jar project file that defines a dependency inside a certain profile. > If I then include that project inside of another war project, the > dependencies defined in the jar project's profile isn't getting transferred > over to the war. > Ie we have this: > A depends on SQL or Oracle depending on profile > B depends on A. > If sql profile is active, I would expect that when I build B, it pulls > the transitive dependancy on sql from A. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[ https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340233#comment-340233 ] Wiebke Timm commented on MNG-1388: -- Not sure what you mean by "set those in the profiles". If you set the property in some parent, you would need a different parent (for that platform's profile) for different platforms. But that doesn't solve cases with managed dependencies: For managed dependencies, a whole subtree is built with a certain platform (i.e. classifier) that's different from the platform of the rest of the tree, but still must be unique within that subtree. This cannot be addressed properly without modeling of transitive dependencies. In any case, we have tried using properties and failed. We are using a workaround with environment variables and that still can't properly deal with the subtree problem described above. > Transitive Dependencies in a profile are not used > - > > Key: MNG-1388 > URL: https://jira.codehaus.org/browse/MNG-1388 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows XP using Maven 2.0. >Reporter: Damian Bradicich > Fix For: Issues to be reviewed for 3.x > > > I have a jar project file that defines a dependency inside a certain profile. > If I then include that project inside of another war project, the > dependencies defined in the jar project's profile isn't getting transferred > over to the war. > Ie we have this: > A depends on SQL or Oracle depending on profile > B depends on A. > If sql profile is active, I would expect that when I build B, it pulls > the transitive dependancy on sql from A. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5265) enforce repository url verification for passing authz
[
https://jira.codehaus.org/browse/MNG-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340234#comment-340234
]
Olivier Lamy commented on MNG-5265:
---
As said on a thread in mailing list, I still consider it as a possible security
problem. But ATM no time to work on that
> enforce repository url verification for passing authz
> -
>
> Key: MNG-5265
> URL: https://jira.codehaus.org/browse/MNG-5265
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 2.0.10, 2.2.1, 3.0.2, 3.0.3, 3.0.4
>Reporter: Olivier Lamy
> Fix For: 3.2
>
>
> Related discussion: http://markmail.org/message/7pswshucxc7qwtef
> in your settings you have:
> {code}
>
> olamy
> reallycomplicatedpassword
> foo.org
>
> {code}
> During dependencies resolution, you get a pom with a repository.
> {code}
>
> foo.org
> http://yourpasswordwillbehacked.org/
>
> {code}
> Idea id in settings must contains the target hostname.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://jira.codehaus.org/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340235#comment-340235
]
Karel Piwko commented on MNG-5199:
--
Yes, I believe this is a deficiency in spawned execution environments. There
are more information about Maven execution that could be propagated to outside
world, such as http://jira.codehaus.org/browse/SUREFIRE-790
> Return back org.apache.maven.user-settings and
> org.apache.maven.global-settings properties
> --
>
> Key: MNG-5199
> URL: https://jira.codehaus.org/browse/MNG-5199
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Settings
>Affects Versions: 3.0.3
>Reporter: Karel Piwko
>
> According to discussion at
> http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
> I'm sure there is a valid use case for the property:
> Imagine following:
> {code}
> mvn -s setting.xml test
> {code}
> Surefire has no way how to pass the path of the settings.xml in the spawned
> process. If the test in spawned process want to for example access remote
> repository defined in settings.xml, user has to specify settings.xml path in
> the test itself.
> However, for the following:
> {code}
> mvn -Dorg.apache.maven.user-settings=settings.xml test
> {code}
> This system property can be passed to surefire configuration and propagated
> to the Surefire spawned process later on.
> Having a system property removes duplication of the environment settings.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[
https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340237#comment-340237
]
Jörg Schaible commented on MNG-1388:
bq. selecting both win32-x86 and linux-gcc (from Wiebkes post)
Where was there a requirement that both platform profiles have to be active *at
the same time* ?
Let's make an example:
parent.xml:
{code:xml|Title=parent.xml}
...
com.company.project
component
1.0
${company.platform}
...
...
linux
linux-gcc
..
win32-x86
...
{code}
parent.xml:
{code:xml|Title=parent.xml}
...
com.company.project
component
${company.platform}
...
{code}
In this example I've used the property "linux" as activator, but you might use
activation based on OS is appropriate. Anyway, with this setup you can call
Maven either with:
mvn -Dlinux clean install
or define this property in the settings.xml. You are even able to test a build
for a new platform directly:
mvn -Dcompany.platform=cygwin-gcc clean install
> Transitive Dependencies in a profile are not used
> -
>
> Key: MNG-1388
> URL: https://jira.codehaus.org/browse/MNG-1388
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0
> Environment: Windows XP using Maven 2.0.
>Reporter: Damian Bradicich
> Fix For: Issues to be reviewed for 3.x
>
>
> I have a jar project file that defines a dependency inside a certain profile.
> If I then include that project inside of another war project, the
> dependencies defined in the jar project's profile isn't getting transferred
> over to the war.
> Ie we have this:
> A depends on SQL or Oracle depending on profile
> B depends on A.
> If sql profile is active, I would expect that when I build B, it pulls
> the transitive dependancy on sql from A.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[ https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340250#comment-340250 ] Gili commented on MNG-1388: --- Defining properties fails to solve the problem because transitive dependencies can and do span across multiple organizations. Meaning, Company A publishes libraries A1, A2, A3 which depend on libraries B1, B2, B3 written by company B, which depend on libraries C1, C2, C3 written by company C. Defining properties this way leaks information from the innermost dependency to the outermost one, meaning: # Anyone building a native library needs to also know how to build all their transitive dependencies (libraries written by other people). Extrapolate this across a couple more level and this gets very complicated very fast. # This approach requires property names to be unique across the entire build tree, but again we don't own all transitive dependencies (this spans multiple organizations). This issue should be reopened. > Transitive Dependencies in a profile are not used > - > > Key: MNG-1388 > URL: https://jira.codehaus.org/browse/MNG-1388 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows XP using Maven 2.0. >Reporter: Damian Bradicich > Fix For: Issues to be reviewed for 3.x > > > I have a jar project file that defines a dependency inside a certain profile. > If I then include that project inside of another war project, the > dependencies defined in the jar project's profile isn't getting transferred > over to the war. > Ie we have this: > A depends on SQL or Oracle depending on profile > B depends on A. > If sql profile is active, I would expect that when I build B, it pulls > the transitive dependancy on sql from A. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5570) Changes to AbstractMavenLifecycleParticipant breaks Tycho
[ https://jira.codehaus.org/browse/MNG-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5570: --- Fix Version/s: 3.2 > Changes to AbstractMavenLifecycleParticipant breaks Tycho > - > > Key: MNG-5570 > URL: https://jira.codehaus.org/browse/MNG-5570 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Jason van Zyl > Fix For: 3.2 > > > The participant is now called too late for Tycho to affect dependency > ordering. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5570) Changes to AbstractMavenLifecycleParticipant breaks Tycho
Jason van Zyl created MNG-5570: -- Summary: Changes to AbstractMavenLifecycleParticipant breaks Tycho Key: MNG-5570 URL: https://jira.codehaus.org/browse/MNG-5570 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.2 Reporter: Jason van Zyl The participant is now called too late for Tycho to affect dependency ordering. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5570) Changes to AbstractMavenLifecycleParticipant breaks Tycho
[ https://jira.codehaus.org/browse/MNG-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5570: --- Assignee: Igor Fedorenko > Changes to AbstractMavenLifecycleParticipant breaks Tycho > - > > Key: MNG-5570 > URL: https://jira.codehaus.org/browse/MNG-5570 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Jason van Zyl >Assignee: Igor Fedorenko > Fix For: 3.2 > > > The participant is now called too late for Tycho to affect dependency > ordering. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5265) enforce repository url verification for passing authz
[
https://jira.codehaus.org/browse/MNG-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340245#comment-340245
]
Jason van Zyl commented on MNG-5265:
Is preemptive auth on GET still on?
I don't think we need to do any special fiddling. I think what needs to happen
is per the spec and that you shouldn't send any authentication info unless the
server requests it. For large PUTs to prevent having to wait until the end of
the transmission another way would need to be found. I can't remember if a HEAD
on resource triggers the server to send an authentication request if required.
> enforce repository url verification for passing authz
> -
>
> Key: MNG-5265
> URL: https://jira.codehaus.org/browse/MNG-5265
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 2.0.10, 2.2.1, 3.0.2, 3.0.3, 3.0.4
>Reporter: Olivier Lamy
> Fix For: 3.2
>
>
> Related discussion: http://markmail.org/message/7pswshucxc7qwtef
> in your settings you have:
> {code}
>
> olamy
> reallycomplicatedpassword
> foo.org
>
> {code}
> During dependencies resolution, you get a pom with a repository.
> {code}
>
> foo.org
> http://yourpasswordwillbehacked.org/
>
> {code}
> Idea id in settings must contains the target hostname.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3879) Dependency map and documentation
[ https://jira.codehaus.org/browse/MNG-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3879: --- Fix Version/s: (was: 3.2) Issues to be reviewed for 4.x > Dependency map and documentation > > > Key: MNG-3879 > URL: https://jira.codehaus.org/browse/MNG-3879 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Dependencies >Affects Versions: 2.0.9 >Reporter: Benson Margulies > Fix For: Issues to be reviewed for 4.x > > > This JIRA proposes a feature. I'm willing to try to contribute it given a > modicum of encouragement and guidance. > Over at CXF, we get many questions from users who are completely confounded > by the complex dependency graph that results from our many dependencies and > their many dependencies. I think that they would be less confused by far if > maven gave them a tiny bit of help. > My idea for this requires an addition to the core POM, which is why I'm > starting with a JIRA here. I propose to add an 'explanation' element to the > dependency element. This would contain a human-readable string explaining why > the dependency is here, which could be carried out through the dependency > plugin. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
[ https://jira.codehaus.org/browse/MNG-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5366: --- Fix Version/s: (was: 3.2) Issues to be reviewed for 4.x > [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 > -- > > Key: MNG-5366 > URL: https://jira.codehaus.org/browse/MNG-5366 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.4, 3.0.5 >Reporter: Paul Gier > Fix For: Issues to be reviewed for 4.x > > > Using Maven 3.0.4, artifacts can only be resolved a single time during the > build lifecycle using the Maven 2.x dependency resolution API. Using > resolver.resolveAlways() should force re-resolution of the artifact, however > if the artifact was already resolved once during the build, then it will not > be re-resolved even when calling resolveAlways(). > This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1911) Building plugins with extensions in a reactor fails
[
https://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340243#comment-340243
]
Jason van Zyl commented on MNG-1911:
Anyone else thought about this from the discussion on the mailing list? I would
like to close this as won't fix.
> Building plugins with extensions in a reactor fails
> ---
>
> Key: MNG-1911
> URL: https://jira.codehaus.org/browse/MNG-1911
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.1
>Reporter: Guillaume Nodet
>Priority: Critical
> Fix For: 3.2
>
> Attachments: MNG-1911.zip
>
>
> I have the following in my main pom
> {code:xml}
>
>
>
>
> org.apache.servicemix.plugins
> maven2-jbi-plugin
> 1.0-SNAPSHOT
> true
>
>
>
>
> {code}
> If i try to add it to the modules, the first time, maven complains that it
> can not download the plugin.
> If i remove the {{}} tag, all works, but i need it :)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-456) Add an option to allow comparing reference project to generated one regardless of the EOL encoding
[ https://jira.codehaus.org/browse/ARCHETYPE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340253#comment-340253 ] Baptiste Mathus commented on ARCHETYPE-456: --- Woops, just noticed I did the patch against the 2.2. Currently reworking it to apply on the trunk, sorry about that. > Add an option to allow comparing reference project to generated one > regardless of the EOL encoding > -- > > Key: ARCHETYPE-456 > URL: https://jira.codehaus.org/browse/ARCHETYPE-456 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.2 >Reporter: Baptiste Mathus > Attachments: ARCHETYPE-ignoreEOLEncoding.patch > > > Mojo : archetype:integration-test > Currently, depending on where you created the reference project to be > compared to the generated one, the test can fail. > This feature would add an option to ask for comparison saying basically you > don't care it's a CR, a LF, or a CRLF EOL, and are only interested in the > rest of the content. > I'm also including a patch (which also includes the corresponding IT for the > invoker-plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5553) ${map(some.key)} is not properly interpolated
[
https://jira.codehaus.org/browse/MNG-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340247#comment-340247
]
Jason van Zyl commented on MNG-5553:
I've released plexus-utils 3.0.17 so it should be in maven central shortly.
I'll update master when it arrives.
> ${map(some.key)} is not properly interpolated
> -
>
> Key: MNG-5553
> URL: https://jira.codehaus.org/browse/MNG-5553
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.2
>
> Attachments: dotted-map-key.zip
>
>
> Plexus ReflectionValueExtractor does not correctly handle mapped properties
> when map key contains '.' (dot). I will use this jira to track both changes
> to plexus-util and corresponding changes to maven.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1388) Transitive Dependencies in a profile are not used
[
https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340248#comment-340248
]
Iain Coulter commented on MNG-1388:
---
{quote}
Where was there a requirement that both platform profiles have to be active at
the same time ?
{quote}
Rereading I can see it was not a requirement in this case, but in the projects
I work on we support multiple databases and multiple platforms. Some releases
include jars/natives for all Database/platforms whereas others are limited to
specific customers and hence only include single database/native classifier.
To do this we must enable multiple different profiles per build
> Transitive Dependencies in a profile are not used
> -
>
> Key: MNG-1388
> URL: https://jira.codehaus.org/browse/MNG-1388
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0
> Environment: Windows XP using Maven 2.0.
>Reporter: Damian Bradicich
> Fix For: Issues to be reviewed for 3.x
>
>
> I have a jar project file that defines a dependency inside a certain profile.
> If I then include that project inside of another war project, the
> dependencies defined in the jar project's profile isn't getting transferred
> over to the war.
> Ie we have this:
> A depends on SQL or Oracle depending on profile
> B depends on A.
> If sql profile is active, I would expect that when I build B, it pulls
> the transitive dependancy on sql from A.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-456) Add an option to allow comparing reference project to generated one regardless of the EOL encoding
Baptiste Mathus created ARCHETYPE-456: - Summary: Add an option to allow comparing reference project to generated one regardless of the EOL encoding Key: ARCHETYPE-456 URL: https://jira.codehaus.org/browse/ARCHETYPE-456 Project: Maven Archetype Issue Type: Improvement Components: Plugin Affects Versions: 2.2 Reporter: Baptiste Mathus Attachments: ARCHETYPE-ignoreEOLEncoding.patch Mojo : archetype:integration-test Currently, depending on where you created the reference project to be compared to the generated one, the test can fail. This feature would add an option to ask for comparison saying basically you don't care it's a CR, a LF, or a CRLF EOL, and are only interested in the rest of the content. I'm also including a patch (which also includes the corresponding IT for the invoker-plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
[ https://jira.codehaus.org/browse/MNG-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340242#comment-340242 ] Jason van Zyl commented on MNG-5366: This has been fixed in Aether and when the Aether 1.0 is released we'll absorb the fix. > [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 > -- > > Key: MNG-5366 > URL: https://jira.codehaus.org/browse/MNG-5366 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.4, 3.0.5 >Reporter: Paul Gier > Fix For: Issues to be reviewed for 4.x > > > Using Maven 3.0.4, artifacts can only be resolved a single time during the > build lifecycle using the Maven 2.x dependency resolution API. Using > resolver.resolveAlways() should force re-resolution of the artifact, however > if the artifact was already resolved once during the build, then it will not > be re-resolved even when calling resolveAlways(). > This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-4173) Remove automatic version resolution for POM plugins
[ https://jira.codehaus.org/browse/MNG-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-4173: --- Fix Version/s: (was: 3.2) Issues to be reviewed for 4.x > Remove automatic version resolution for POM plugins > --- > > Key: MNG-4173 > URL: https://jira.codehaus.org/browse/MNG-4173 > Project: Maven 2 & 3 > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann > Fix For: Issues to be reviewed for 4.x > > > Maven 3.x will no longer try to automatically find the version for plugins > specified in the POM, i.e. the effective POM must declare a version for each > plugin used for the sake of reproducible builds. Omitting the plugin version > will raise in error. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5571) Instructions to resume the build lie, with -T parallel builds
Derek Lewis created MNG-5571:
Summary: Instructions to resume the build lie, with -T parallel
builds
Key: MNG-5571
URL: https://jira.codehaus.org/browse/MNG-5571
Project: Maven 2 & 3
Issue Type: Bug
Reporter: Derek Lewis
Priority: Minor
Attachments: resume-from-testcase.zip
In a project with many modules that are able to build in parallel, if one fails
the build, the output says to use -rf to resume from that module. However,
this may not run the other modules that were running in parallel. If one of
those modules also had failures, but had not yet reached those failures during
the first build, and those modules aren't build in the second build, the build
will pass, despite these 'hidden' errors.
In the example I've attached, there are four submodules, a, b, c and d. Module
d depends on a, b, and c, and all modules share a common parent module.
The properties fail.a, fail.b, and fail.c will cause the respective module to
fail.
Build first with just "mvn install -T4".
Next, imagine making a change in modules a, b, and c that break them, and build
with "mvn install -T4 -Dfail.a -Dfail.b -Dfail.c"
Due to the timing in the test poms (using antrun sleep), this should print:
{noformat}
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :c
{noformat}
Above that, you will see it reporting the failure of all three modules, but in
a lot of cases where there are surefire tests failing, it's extremely difficult
to tell that more than one module failed. As a result, I generally just look
at the module it's told me to resume from, to find failures.
So, pretend you've done that, but the errors in a and b remain, and run "mvn
install -T4 -Dfail.a -Dfail.b -rf :c" as it's suggested.
The build passes, giving a false sense of confidence.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5207: --- Summary: [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers (was: [Regression] Maven 3 fails to calculate proper build order) > [Regression] Maven 3 fails to calculate proper build order with dependencies > with classifiers > - > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Jörg Schaible >Assignee: Kristian Rosenvold >Priority: Critical > Fix For: 3.2 > > Attachments: mng5207-it.tgz, MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5571) Instructions to resume the build can be misleading with -T parallel builds
[
https://jira.codehaus.org/browse/MNG-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Lewis updated MNG-5571:
-
Summary: Instructions to resume the build can be misleading with -T
parallel builds (was: Instructions to resume the build lie, with -T parallel
builds)
> Instructions to resume the build can be misleading with -T parallel builds
> --
>
> Key: MNG-5571
> URL: https://jira.codehaus.org/browse/MNG-5571
> Project: Maven 2 & 3
> Issue Type: Bug
>Reporter: Derek Lewis
>Priority: Minor
> Attachments: resume-from-testcase.zip
>
>
> In a project with many modules that are able to build in parallel, if one
> fails the build, the output says to use -rf to resume from that module.
> However, this may not run the other modules that were running in parallel.
> If one of those modules also had failures, but had not yet reached those
> failures during the first build, and those modules aren't build in the second
> build, the build will pass, despite these 'hidden' errors.
> In the example I've attached, there are four submodules, a, b, c and d.
> Module d depends on a, b, and c, and all modules share a common parent module.
> The properties fail.a, fail.b, and fail.c will cause the respective module to
> fail.
> Build first with just "mvn install -T4".
> Next, imagine making a change in modules a, b, and c that break them, and
> build with "mvn install -T4 -Dfail.a -Dfail.b -Dfail.c"
> Due to the timing in the test poms (using antrun sleep), this should print:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :c
> {noformat}
> Above that, you will see it reporting the failure of all three modules, but
> in a lot of cases where there are surefire tests failing, it's extremely
> difficult to tell that more than one module failed. As a result, I generally
> just look at the module it's told me to resume from, to find failures.
> So, pretend you've done that, but the errors in a and b remain, and run "mvn
> install -T4 -Dfail.a -Dfail.b -rf :c" as it's suggested.
> The build passes, giving a false sense of confidence.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories/_remote.repositories contains other repository ids than requested
[ https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5185: --- Fix Version/s: (was: 3.2) Issues to be reviewed for 4.x > Improve "missing dependency" error message when > _maven.repositories/_remote.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: Issues to be reviewed for 4.x > > 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 local > repositories|https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository]. > Unfortunately, when "conflicts" arise (GAV is cached in local repo, but > restricted to some repository ids, and actual 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 without knowing this restriction feature: 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 remote > 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 was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories/_remote.repositories contains other repository ids than requested
[ https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340259#comment-340259 ] Jason van Zyl commented on MNG-5185: This patch will have to be adapted and integrated into an Aether 1.0 before we absorb it. > Improve "missing dependency" error message when > _maven.repositories/_remote.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: Issues to be reviewed for 4.x > > 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 local > repositories|https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository]. > Unfortunately, when "conflicts" arise (GAV is cached in local repo, but > restricted to some repository ids, and actual 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 without knowing this restriction feature: 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 remote > 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 was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5569) JAVA_HOME "Program Files (x86)" gives error
[
https://jira.codehaus.org/browse/MNG-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340260#comment-340260
]
Robert Scholte commented on MNG-5569:
-
That's not a Maven question, but a Windows OS question.
try to do the following:
{noformat}
C:\>set MAVEN_BATCH_ECHO=on
C:\>mvn -v
{noformat}
When the quotes are placed on the wrong spots, you can't execute Maven (or any
program through commandline)
> JAVA_HOME "Program Files (x86)" gives error
> ---
>
> Key: MNG-5569
> URL: https://jira.codehaus.org/browse/MNG-5569
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-
> Maven home: d:\DATA\apache-maven-3.1.1\bin\..
> Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
> Java home: d:\data\java\jdk1.6.0_45\jre
> Default locale: nl_NL, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" 64-bit
>Reporter: Casper Roubos
>Assignee: Robert Scholte
>
> _as_ a programmer with a Windows 7 64-bits OS,
> _I want_ Maven to work with a JAVA_HOME path containing "c:\Program Files
> (x86)\Java\jdk1.6.0_45",
> _so that_ I do not get a wierd error like "Files not expected at this time"
> * Unzip maven-3.1.1.zip in a folder like "d:\data\maven-3.1.1"
> * Install JDK at "c:\Program Files (x86)\Java"
> * set JAVA_HOME accordingly"
> * enter "mvn --version"
> ** _result_: an error "Files not expected at this time"
> ** _expected_: maven returning the version details
> * Copy JDK to an other directory, like "d:\data\Java\jdk1.6.0_45"
> * set JAVA_HOME accordingly
> ** _result_: maven returning the version details
> ** _conclusion_: maven does not like "c:\Program Files (x86)\Java"
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5378) Use m-s-u in Maven core
[ https://jira.codehaus.org/browse/MNG-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340263#comment-340263 ] Jason van Zyl commented on MNG-5378: I don't see this happening in 3.2 as it's a pretty radical change. > Use m-s-u in Maven core > --- > > Key: MNG-5378 > URL: https://jira.codehaus.org/browse/MNG-5378 > Project: Maven 2 & 3 > Issue Type: Bug >Reporter: Jason van Zyl >Assignee: Kristian Rosenvold > Fix For: Issues to be reviewed for 4.x > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5378) Use m-s-u in Maven core
[ https://jira.codehaus.org/browse/MNG-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5378: --- Fix Version/s: (was: 3.2) Issues to be reviewed for 4.x > Use m-s-u in Maven core > --- > > Key: MNG-5378 > URL: https://jira.codehaus.org/browse/MNG-5378 > Project: Maven 2 & 3 > Issue Type: Bug >Reporter: Jason van Zyl >Assignee: Kristian Rosenvold > Fix For: Issues to be reviewed for 4.x > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-182) Missing documentation for new feature MENFORCER-160
[ https://jira.codehaus.org/browse/MENFORCER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Friedenhagen updated MENFORCER-182: - Attachment: (was: MENFORCER-162.patch) > Missing documentation for new feature MENFORCER-160 > --- > > Key: MENFORCER-182 > URL: https://jira.codehaus.org/browse/MENFORCER-182 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation >Reporter: Karl Heinz Marbaise > Fix For: 1.4 > > > Currently the documentation for MENFORCER-160 is missing. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-182) Missing documentation for new feature MENFORCER-160
[ https://jira.codehaus.org/browse/MENFORCER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340191#comment-340191 ] Mirko Friedenhagen edited comment on MENFORCER-182 at 1/27/14 2:27 PM: --- Added a patch for the documentation also available as https://github.com/apache/maven-enforcer/pull/12. was (Author: mfriedenhagen): Added a patch for the documentation also available as https://github.com/apache/maven-enforcer/pull/10. > Missing documentation for new feature MENFORCER-160 > --- > > Key: MENFORCER-182 > URL: https://jira.codehaus.org/browse/MENFORCER-182 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation >Reporter: Karl Heinz Marbaise > Fix For: 1.4 > > > Currently the documentation for MENFORCER-160 is missing. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-182) Missing documentation for new feature MENFORCER-160
[ https://jira.codehaus.org/browse/MENFORCER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Friedenhagen updated MENFORCER-182: - Attachment: MENFORCER-182.patch Add better example using bannedPlugins > Missing documentation for new feature MENFORCER-160 > --- > > Key: MENFORCER-182 > URL: https://jira.codehaus.org/browse/MENFORCER-182 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation >Reporter: Karl Heinz Marbaise > Fix For: 1.4 > > Attachments: MENFORCER-182.patch > > > Currently the documentation for MENFORCER-160 is missing. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-168) In a multi module project "bannedDependencies" rule tries to resolve project artifacts from external repository
[
https://jira.codehaus.org/browse/MENFORCER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340268#comment-340268
]
Karl Heinz Marbaise commented on MENFORCER-168:
---
After checking your pull request i've tested with Maven 3.0.4, Maven 3.0.5,
Maven 3.1.0 and Maven 3.1.1. and it does not work with **none** of them.
But:
I've taken a deeper look into it and realized that the integration tests are
running by calling maven (via maven-invoker-plugin) like this:
{code}mvn validate{code}
LIfecylce. If you do that directly on the command with the example project it
will fail also. The problem is causes that during the validate lifecycle no
artifact (jar) has been created. That means in other words the artifacts are
not in the reactor as well.
If you call Maven via:
{code}mvn package{code}
It works without any problem.
> In a multi module project "bannedDependencies" rule tries to resolve project
> artifacts from external repository
> ---
>
> Key: MENFORCER-168
> URL: https://jira.codehaus.org/browse/MENFORCER-168
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Conny Kreyssel
>Priority: Critical
>
> I have created a pull request with a IT case on github.
> see https://github.com/apache/maven-enforcer/pull/6
> Seems to be a problem with maven 3.1.1. The IT runs with maven 3.0.4 but
> fails with 3.1.1.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-168) In a multi module project "bannedDependencies" rule tries to resolve project artifacts from external repository
[
https://jira.codehaus.org/browse/MENFORCER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340268#comment-340268
]
Karl Heinz Marbaise edited comment on MENFORCER-168 at 1/27/14 2:44 PM:
After checking your pull request i've tested with Maven 3.0.4, Maven 3.0.5,
Maven 3.1.0 and Maven 3.1.1. and it does not work with **none** of them.
But:
I've taken a deeper look into it and realized that the integration tests are
running by calling maven (via maven-invoker-plugin) like this:
{code}mvn validate{code}
LIfecylce. If you do that directly on the command with the example project it
will fail also. The problem is causes that during the validate lifecycle no
artifact (jar) has been created. That means in other words the artifacts are
not available in the reactor as well.
If you call Maven via:
{code}mvn package{code}
It works without any problem.
was (Author: khmarbaise):
After checking your pull request i've tested with Maven 3.0.4, Maven 3.0.5,
Maven 3.1.0 and Maven 3.1.1. and it does not work with **none** of them.
But:
I've taken a deeper look into it and realized that the integration tests are
running by calling maven (via maven-invoker-plugin) like this:
{code}mvn validate{code}
LIfecylce. If you do that directly on the command with the example project it
will fail also. The problem is causes that during the validate lifecycle no
artifact (jar) has been created. That means in other words the artifacts are
not in the reactor as well.
If you call Maven via:
{code}mvn package{code}
It works without any problem.
> In a multi module project "bannedDependencies" rule tries to resolve project
> artifacts from external repository
> ---
>
> Key: MENFORCER-168
> URL: https://jira.codehaus.org/browse/MENFORCER-168
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Conny Kreyssel
>Priority: Critical
>
> I have created a pull request with a IT case on github.
> see https://github.com/apache/maven-enforcer/pull/6
> Seems to be a problem with maven 3.1.1. The IT runs with maven 3.0.4 but
> fails with 3.1.1.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5553) ${map(some.key)} is not properly interpolated
[
https://jira.codehaus.org/browse/MNG-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5553.
--
Resolution: Fixed
> ${map(some.key)} is not properly interpolated
> -
>
> Key: MNG-5553
> URL: https://jira.codehaus.org/browse/MNG-5553
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.2
>
> Attachments: dotted-map-key.zip
>
>
> Plexus ReflectionValueExtractor does not correctly handle mapped properties
> when map key contains '.' (dot). I will use this jira to track both changes
> to plexus-util and corresponding changes to maven.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-182) Missing documentation for new feature MENFORCER-160
[ https://jira.codehaus.org/browse/MENFORCER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MENFORCER-182. - Resolution: Fixed Patch applied into [r1561846|http://svn.apache.org/r1561846]. Thanks. > Missing documentation for new feature MENFORCER-160 > --- > > Key: MENFORCER-182 > URL: https://jira.codehaus.org/browse/MENFORCER-182 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation >Reporter: Karl Heinz Marbaise > Fix For: 1.4 > > Attachments: MENFORCER-182.patch > > > Currently the documentation for MENFORCER-160 is missing. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-182) Missing documentation for new feature MENFORCER-160
[ https://jira.codehaus.org/browse/MENFORCER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340269#comment-340269 ] Karl Heinz Marbaise edited comment on MENFORCER-182 at 1/27/14 3:01 PM: Patch applied into [r1561846|http://svn.apache.org/r1561846]. Thanks to Mirko Friedenhagen. was (Author: khmarbaise): Patch applied into [r1561846|http://svn.apache.org/r1561846]. Thanks. > Missing documentation for new feature MENFORCER-160 > --- > > Key: MENFORCER-182 > URL: https://jira.codehaus.org/browse/MENFORCER-182 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation >Reporter: Karl Heinz Marbaise > Fix For: 1.4 > > Attachments: MENFORCER-182.patch > > > Currently the documentation for MENFORCER-160 is missing. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-168) In a multi module project "bannedDependencies" rule tries to resolve project artifacts from external repository
[
https://jira.codehaus.org/browse/MENFORCER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340268#comment-340268
]
Karl Heinz Marbaise edited comment on MENFORCER-168 at 1/27/14 3:09 PM:
After checking your pull request i've tested with Maven 3.0.4, Maven 3.0.5,
Maven 3.1.0 and Maven 3.1.1. and it does not work with **none** of them.
But:
I've taken a deeper look into it and realized that the integration tests are
running by calling maven (via maven-invoker-plugin) like this:
{code}mvn validate{code}
LIfecylce. If you do that directly on the command with the example project it
will fail also. The problem is causes that during the validate lifecycle no
artifact (jar) has been created. That means in other words the artifacts are
not available in the reactor as well.
If you call Maven via:
{code}mvn package{code}
It works without any problem.
Furthermore if you add an {{invoker.properties}} into your root of your project
everything is fine.
was (Author: khmarbaise):
After checking your pull request i've tested with Maven 3.0.4, Maven 3.0.5,
Maven 3.1.0 and Maven 3.1.1. and it does not work with **none** of them.
But:
I've taken a deeper look into it and realized that the integration tests are
running by calling maven (via maven-invoker-plugin) like this:
{code}mvn validate{code}
LIfecylce. If you do that directly on the command with the example project it
will fail also. The problem is causes that during the validate lifecycle no
artifact (jar) has been created. That means in other words the artifacts are
not available in the reactor as well.
If you call Maven via:
{code}mvn package{code}
It works without any problem.
> In a multi module project "bannedDependencies" rule tries to resolve project
> artifacts from external repository
> ---
>
> Key: MENFORCER-168
> URL: https://jira.codehaus.org/browse/MENFORCER-168
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Conny Kreyssel
>Priority: Critical
>
> I have created a pull request with a IT case on github.
> see https://github.com/apache/maven-enforcer/pull/6
> Seems to be a problem with maven 3.1.1. The IT runs with maven 3.0.4 but
> fails with 3.1.1.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-168) In a multi module project "bannedDependencies" rule tries to resolve project artifacts from external repository
[
https://jira.codehaus.org/browse/MENFORCER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340268#comment-340268
]
Karl Heinz Marbaise edited comment on MENFORCER-168 at 1/27/14 3:12 PM:
After checking your pull request i've tested with Maven 3.0.4, Maven 3.0.5,
Maven 3.1.0 and Maven 3.1.1. and it does not work with **none** of them.
But:
I've taken a deeper look into it and realized that the integration tests are
running by calling maven (via maven-invoker-plugin) like this:
{code}mvn validate{code}
LIfecylce. If you do that directly on the command with the example project it
will fail also. The problem is causes that during the validate lifecycle no
artifact (jar) has been created. That means in other words the artifacts are
not available in the reactor as well.
If you call Maven via:
{code}mvn package{code}
It works without any problem.
Furthermore if you add an {{invoker.properties}} into your root of your project
with the following content:
{code}invoker.goals=clean package{code}
everything is fine.
was (Author: khmarbaise):
After checking your pull request i've tested with Maven 3.0.4, Maven 3.0.5,
Maven 3.1.0 and Maven 3.1.1. and it does not work with **none** of them.
But:
I've taken a deeper look into it and realized that the integration tests are
running by calling maven (via maven-invoker-plugin) like this:
{code}mvn validate{code}
LIfecylce. If you do that directly on the command with the example project it
will fail also. The problem is causes that during the validate lifecycle no
artifact (jar) has been created. That means in other words the artifacts are
not available in the reactor as well.
If you call Maven via:
{code}mvn package{code}
It works without any problem.
Furthermore if you add an {{invoker.properties}} into your root of your project
everything is fine.
> In a multi module project "bannedDependencies" rule tries to resolve project
> artifacts from external repository
> ---
>
> Key: MENFORCER-168
> URL: https://jira.codehaus.org/browse/MENFORCER-168
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Conny Kreyssel
>Priority: Critical
>
> I have created a pull request with a IT case on github.
> see https://github.com/apache/maven-enforcer/pull/6
> Seems to be a problem with maven 3.1.1. The IT runs with maven 3.0.4 but
> fails with 3.1.1.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-168) In a multi module project "bannedDependencies" rule tries to resolve project artifacts from external repository
[
https://jira.codehaus.org/browse/MENFORCER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340268#comment-340268
]
Karl Heinz Marbaise edited comment on MENFORCER-168 at 1/27/14 3:14 PM:
After checking your pull request i've tested with Maven 3.0.4, Maven 3.0.5,
Maven 3.1.0 and Maven 3.1.1. and it does not work with **none** of them.
But:
I've taken a deeper look into it and discovered that the integration tests are
running by calling maven (via maven-invoker-plugin) like this:
{code}mvn validate{code}
LIfecylce. If you do that directly on the command with the example project it
will fail also. The problem is causes that during the validate lifecycle no
artifact (jar) has been created. That means in other words the artifacts are
not available in the reactor as well.
If you call Maven via:
{code}mvn package{code}
It works without any problem.
Furthermore if you add an {{invoker.properties}} into your root of your project
with the following content:
{code}invoker.goals=clean package{code}
everything is fine.
was (Author: khmarbaise):
After checking your pull request i've tested with Maven 3.0.4, Maven 3.0.5,
Maven 3.1.0 and Maven 3.1.1. and it does not work with **none** of them.
But:
I've taken a deeper look into it and realized that the integration tests are
running by calling maven (via maven-invoker-plugin) like this:
{code}mvn validate{code}
LIfecylce. If you do that directly on the command with the example project it
will fail also. The problem is causes that during the validate lifecycle no
artifact (jar) has been created. That means in other words the artifacts are
not available in the reactor as well.
If you call Maven via:
{code}mvn package{code}
It works without any problem.
Furthermore if you add an {{invoker.properties}} into your root of your project
with the following content:
{code}invoker.goals=clean package{code}
everything is fine.
> In a multi module project "bannedDependencies" rule tries to resolve project
> artifacts from external repository
> ---
>
> Key: MENFORCER-168
> URL: https://jira.codehaus.org/browse/MENFORCER-168
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Conny Kreyssel
>Priority: Critical
>
> I have created a pull request with a IT case on github.
> see https://github.com/apache/maven-enforcer/pull/6
> Seems to be a problem with maven 3.1.1. The IT runs with maven 3.0.4 but
> fails with 3.1.1.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-456) Add an option to allow comparing reference project to generated one regardless of the EOL encoding
[ https://jira.codehaus.org/browse/ARCHETYPE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baptiste Mathus updated ARCHETYPE-456: -- Attachment: build-archetype-ignore-eol-encoding.zip ARCHETYPE-ignoreEOLEncoding.patch New version of the patch. Not sure at all though that the patch format is gonna retain the necessary newline encoding (LF, CR instead of a single one and so on). So, I'm also attaching a zipped version of the new it directory. The ITs is actually composed of two runs, the first one *must* fail (without enabling the ignoreEOLEncoding new behaviour). > Add an option to allow comparing reference project to generated one > regardless of the EOL encoding > -- > > Key: ARCHETYPE-456 > URL: https://jira.codehaus.org/browse/ARCHETYPE-456 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.2 >Reporter: Baptiste Mathus > Attachments: ARCHETYPE-ignoreEOLEncoding-v2.patch, > build-archetype-ignore-eol-encoding.zip > > > Mojo : archetype:integration-test > Currently, depending on where you created the reference project to be > compared to the generated one, the test can fail. > This feature would add an option to ask for comparison saying basically you > don't care it's a CR, a LF, or a CRLF EOL, and are only interested in the > rest of the content. > I'm also including a patch (which also includes the corresponding IT for the > invoker-plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-456) Add an option to allow comparing reference project to generated one regardless of the EOL encoding
[ https://jira.codehaus.org/browse/ARCHETYPE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340270#comment-340270 ] Baptiste Mathus edited comment on ARCHETYPE-456 at 1/27/14 3:28 PM: New version of the patch. Not sure at all though that the patch format is gonna retain the necessarily different newline encodings (LF, CR instead of a single one and so on). So, I'm also attaching a zipped version of the new it directory. The ITs is actually composed of two runs, the first one *must* fail (without enabling the ignoreEOLEncoding new behaviour). was (Author: baptiste): New version of the patch. Not sure at all though that the patch format is gonna retain the necessary newline encoding (LF, CR instead of a single one and so on). So, I'm also attaching a zipped version of the new it directory. The ITs is actually composed of two runs, the first one *must* fail (without enabling the ignoreEOLEncoding new behaviour). > Add an option to allow comparing reference project to generated one > regardless of the EOL encoding > -- > > Key: ARCHETYPE-456 > URL: https://jira.codehaus.org/browse/ARCHETYPE-456 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.2 >Reporter: Baptiste Mathus > Attachments: ARCHETYPE-ignoreEOLEncoding-v2.patch, > build-archetype-ignore-eol-encoding.zip > > > Mojo : archetype:integration-test > Currently, depending on where you created the reference project to be > compared to the generated one, the test can fail. > This feature would add an option to ask for comparison saying basically you > don't care it's a CR, a LF, or a CRLF EOL, and are only interested in the > rest of the content. > I'm also including a patch (which also includes the corresponding IT for the > invoker-plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-456) Add an option to allow comparing reference project to generated one regardless of the EOL encoding
[ https://jira.codehaus.org/browse/ARCHETYPE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baptiste Mathus updated ARCHETYPE-456: -- Attachment: (was: ARCHETYPE-ignoreEOLEncoding.patch) > Add an option to allow comparing reference project to generated one > regardless of the EOL encoding > -- > > Key: ARCHETYPE-456 > URL: https://jira.codehaus.org/browse/ARCHETYPE-456 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.2 >Reporter: Baptiste Mathus > Attachments: ARCHETYPE-ignoreEOLEncoding-v2.patch, > build-archetype-ignore-eol-encoding.zip > > > Mojo : archetype:integration-test > Currently, depending on where you created the reference project to be > compared to the generated one, the test can fail. > This feature would add an option to ask for comparison saying basically you > don't care it's a CR, a LF, or a CRLF EOL, and are only interested in the > rest of the content. > I'm also including a patch (which also includes the corresponding IT for the > invoker-plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-456) Add an option to allow comparing reference project to generated one regardless of the EOL encoding
[ https://jira.codehaus.org/browse/ARCHETYPE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baptiste Mathus updated ARCHETYPE-456: -- Attachment: (was: ARCHETYPE-ignoreEOLEncoding.patch) > Add an option to allow comparing reference project to generated one > regardless of the EOL encoding > -- > > Key: ARCHETYPE-456 > URL: https://jira.codehaus.org/browse/ARCHETYPE-456 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.2 >Reporter: Baptiste Mathus > Attachments: ARCHETYPE-ignoreEOLEncoding-v2.patch, > build-archetype-ignore-eol-encoding.zip > > > Mojo : archetype:integration-test > Currently, depending on where you created the reference project to be > compared to the generated one, the test can fail. > This feature would add an option to ask for comparison saying basically you > don't care it's a CR, a LF, or a CRLF EOL, and are only interested in the > rest of the content. > I'm also including a patch (which also includes the corresponding IT for the > invoker-plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-456) Add an option to allow comparing reference project to generated one regardless of the EOL encoding
[ https://jira.codehaus.org/browse/ARCHETYPE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baptiste Mathus updated ARCHETYPE-456: -- Attachment: ARCHETYPE-ignoreEOLEncoding-v2.patch > Add an option to allow comparing reference project to generated one > regardless of the EOL encoding > -- > > Key: ARCHETYPE-456 > URL: https://jira.codehaus.org/browse/ARCHETYPE-456 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.2 >Reporter: Baptiste Mathus > Attachments: ARCHETYPE-ignoreEOLEncoding-v2.patch, > build-archetype-ignore-eol-encoding.zip > > > Mojo : archetype:integration-test > Currently, depending on where you created the reference project to be > compared to the generated one, the test can fail. > This feature would add an option to ask for comparison saying basically you > don't care it's a CR, a LF, or a CRLF EOL, and are only interested in the > rest of the content. > I'm also including a patch (which also includes the corresponding IT for the > invoker-plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5468) Allow mojos to access the user properties
[ https://jira.codehaus.org/browse/MNG-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-5468. --- Resolution: Not A Bug Assignee: Robert Scholte Closing, see hints from [~hboutemy] and [~olamy] > Allow mojos to access the user properties > - > > Key: MNG-5468 > URL: https://jira.codehaus.org/browse/MNG-5468 > Project: Maven 2 & 3 > Issue Type: Wish >Affects Versions: 3.0.4 >Reporter: Michael Ekstrand >Assignee: Robert Scholte > > There does not seem to be any way to obtain the user properties in a mojo. > The mojo can get the model properties from the project, but not the user > properties specified on the Maven command line. This is problematic for mojos > that want to consult them for additional configuration to pass on to other > things (user classes, scripts, etc.). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5479) ExecutionEvent.Type.SessionEnded omited when runtime exception thrown
[
https://jira.codehaus.org/browse/MNG-5479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5479:
---
Assignee: Jason van Zyl
> ExecutionEvent.Type.SessionEnded omited when runtime exception thrown
> -
>
> Key: MNG-5479
> URL: https://jira.codehaus.org/browse/MNG-5479
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Embedding, IDEs
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Milos Kleint
>Assignee: Jason van Zyl
> Fix For: 3.2
>
> Attachments: maven.patch
>
>
> in LifecycleStarter.java the ExecutionEvent.Type.SessionStarted is always
> fired, but ExecutionEvent.Type.SessionEnded appears only be fired when in
> some cases, omitted in case of RuntimeException thrown. IMHO the event should
> be fired in finally {} block. See attached patch.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5265) enforce repository url verification for passing authz
[
https://jira.codehaus.org/browse/MNG-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5265:
---
Fix Version/s: (was: 3.2)
Issues to be reviewed for 4.x
> enforce repository url verification for passing authz
> -
>
> Key: MNG-5265
> URL: https://jira.codehaus.org/browse/MNG-5265
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 2.0.10, 2.2.1, 3.0.2, 3.0.3, 3.0.4
>Reporter: Olivier Lamy
> Fix For: Issues to be reviewed for 4.x
>
>
> Related discussion: http://markmail.org/message/7pswshucxc7qwtef
> in your settings you have:
> {code}
>
> olamy
> reallycomplicatedpassword
> foo.org
>
> {code}
> During dependencies resolution, you get a pom with a repository.
> {code}
>
> foo.org
> http://yourpasswordwillbehacked.org/
>
> {code}
> Idea id in settings must contains the target hostname.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1911) Building plugins with extensions in a reactor fails
[
https://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-1911:
---
Assignee: Jason van Zyl
> Building plugins with extensions in a reactor fails
> ---
>
> Key: MNG-1911
> URL: https://jira.codehaus.org/browse/MNG-1911
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.1
>Reporter: Guillaume Nodet
>Assignee: Jason van Zyl
>Priority: Critical
> Fix For: 3.2
>
> Attachments: MNG-1911.zip
>
>
> I have the following in my main pom
> {code:xml}
>
>
>
>
> org.apache.servicemix.plugins
> maven2-jbi-plugin
> 1.0-SNAPSHOT
> true
>
>
>
>
> {code}
> If i try to add it to the modules, the first time, maven complains that it
> can not download the plugin.
> If i remove the {{}} tag, all works, but i need it :)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5207: --- Assignee: Jason van Zyl (was: Kristian Rosenvold) > [Regression] Maven 3 fails to calculate proper build order with dependencies > with classifiers > - > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Jörg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: 3.2 > > Attachments: mng5207-it.tgz, MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3056) Dependencies should not be able to introduce repositories to the build
[
https://jira.codehaus.org/browse/MNG-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340281#comment-340281
]
Joseph Walton commented on MNG-3056:
For anyone looking for how to force resolution through a single URL, it's under
[Using A Single
Repository|http://maven.apache.org/guides/mini/guide-mirror-settings.html]. Add
a mirror to your {{~/.m2/settings.xml}} with {{mirrorOf}} set to {{*}}:
{noformat}
...
internal-repository
Maven Repository Manager running on repo.mycompany.com
http://repo.mycompany.com/proxy
*
...
{noformat}
> Dependencies should not be able to introduce repositories to the build
> --
>
> Key: MNG-3056
> URL: https://jira.codehaus.org/browse/MNG-3056
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 2.2.x (to be reviewed)
>Reporter: Wendy Smoak
>Assignee: Jason van Zyl
> Fix For: Issues to be reviewed for 3.x
>
>
> If you depend on an artifact that has repositories or pluginRepositories
> defined in the pom, those repositories are also searched for artifacts.
> It's disconcerting when you think you've overridden 'central' and set things
> up to use only internal repositories, and Maven still tries to to download
> artifacts from elsewhere.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories/_remote.repositories contains other repository ids than requested
[ https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Walton updated MNG-5185: --- Attachment: 0001-MNG-5185-Warn-about-artifacts-present-but-not-available-eclipse-aether.patch bq. This patch will have to be adapted and integrated into an Aether 1.0 before we absorb it. I've updated the patch to apply against the Eclipse aether-core master branch. This gets more complicated now Aether and Maven are separate projects: is this a useful change? What would the next steps be to get this into an Eclipse release that Maven could then consume? > Improve "missing dependency" error message when > _maven.repositories/_remote.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: Issues to be reviewed for 4.x > > Attachments: > 0001-MNG-5185-Warn-about-artifacts-present-but-not-available-eclipse-aether.patch, > 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 local > repositories|https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository]. > Unfortunately, when "conflicts" arise (GAV is cached in local repo, but > restricted to some repository ids, and actual 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 without knowing this restriction feature: 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 remote > 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 was sent by Atlassian JIRA (v6.1.6#6162)
