e one dependency from that
dependencyManagement section, spring-boot-autoconfigure.
I don't understand why the consumer POM has copied all of the managed
dependencies from spring-boot-dependencies, or why the consumer POM
contains dependencyManagement at all, because the dependency on
spring-boot-aut
Hi all,
I was able to find some StackOverflow questions that described the expected
behaviour and I'm able to get this feature implemented by injecting a
MavenProject variable and accessing the project's Model
DependencyManagement field.
Thanks,
Ian
On Tue, Jul 28, 2020 at 3:24 PM Ia
I have a working but not feature complete verbose tree builder and
serializer in the maven-dependency-plugin and I am trying to add the
dependencyManagement messages (ex.
(org.apache.maven:maven-model:jar:2.0.5:test - version managed from 2.0.4;
scope managed from compile; omitted for conflict
mmit to branch MNG-6213
> >> in repository https://gitbox.apache.org/repos/asf/maven.git
> >>
> >> commit 859e344f4d5f7bfa00caf7343ea6554138e9dcf7
> >> Author: Michael Warnecke <13...@nordakademie.de>
> >> AuthorDate: Sat Sep 23 18:37:09 2017 +020
859e344f4d5f7bfa00caf7343ea6554138e9dcf7
Author: Michael Warnecke <13...@nordakademie.de>
AuthorDate: Sat Sep 23 18:37:09 2017 +0200
[MNG-6213] Validate scope in dependencyManagement
This closes #131
---
.../model/validation/DefaultModelValidator.java| 10 ++-
.../validation/DefaultModelValidatorTes
hor: Michael Warnecke <13...@nordakademie.de>
> AuthorDate: Sat Sep 23 18:37:09 2017 +0200
>
> [MNG-6213] Validate scope in dependencyManagement
>
> This closes #131
> ---
> .../model/validation/DefaultModelValidator.java| 10 ++-
> .../
GitHub user clarkperkins opened a pull request:
https://github.com/apache/maven/pull/158
Set the profiles on reecursive dependencyManagement imports
When a set of default repositories are specified via a profile in the
global settings.xml, recursive dependencyManagement imports
GitHub user MichaelWarnecke opened a pull request:
https://github.com/apache/maven/pull/131
[MNG-6213] Validate scope in dependencyManagement
This is a patch for MNG-6213: https://issues.apache.org/jira/browse/MNG-6213
You can merge this pull request into a Git repository by
Github user MichaelWarnecke closed the pull request at:
https://github.com/apache/maven/pull/130
---
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
GitHub user MichaelWarnecke opened a pull request:
https://github.com/apache/maven/pull/130
[MNG-6231] Validate scope in dependencyManagement
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/MichaelWarnecke/maven MNG-6213
Github user akacme commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168756278
I've added POM-property-based configuration. Based on my current skill
level embedding configuration somewhere else would require change in
dependencies section for maven-m
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168565897
POM property, CLI property override, or we might want to start collecting
these provisional changes in a special maven plugin configuration section for
activating proposed
injected via settings.xml).
In case when a change of DependencyManagement model is allowed (4.x?) -
this might be better approach in the long run as this info can be reused in the
maven dependency plugin (to show where managed version comes from) and perhaps
will allow to introduce pluggable
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168534190
General rule of thumb is that a change in resolution will definitely not go
in if it changes the default behaviour within a minor version. First smoke test
is making sure
Github user akacme commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168519406
I've introduced DependencyManagementGraph object to store and compute
"distance" for dependencyManagement section - so there is no change to the
model itsel
Github user michael-o commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168405448
Now I see, the `Optional´ comes from Guava and not from Java. I think the
likelyhood is higher w/o a model change.
---
If your project is set up for it, you can reply
Github user akacme commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168404937
In other words - will it go to Maven 3.x when there is no modification to
the model itself?
---
If your project is set up for it, you can reply to this email and have your
Github user akacme commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168403276
Code has been compiled using Java 7. Model has been enhanced to store graph
of imports in dependency management section - I can rewrite it to store it
elsewhere, but such s
Github user michael-o commented on the pull request:
https://github.com/apache/maven/pull/74#issuecomment-168402507
You are using Java 8 features which we can't accept. Java 7 only. The model
is changed. I would opt-in for that not before Maven 4.
---
If your project is set up for it
GitHub user akacme opened a pull request:
https://github.com/apache/maven/pull/74
[MNG-5947] dependencyManagement import section does not resolve
dependencies using "nearest" definition
o DepenencyManagement model updated to contain declared dependencies
an
Github user akacme closed the pull request at:
https://github.com/apache/maven/pull/73
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enable
GitHub user akacme opened a pull request:
https://github.com/apache/maven/pull/73
[MNG-5947] dependencyManagement import section does not resolve
dependencies using "nearest" definition
dependencies using "nearest" definition
o DepenencyManagement mode
://maven.40175.n5.nabble.com/Only-one-POM-with-dependencyManagement-for-entire-company-tp5814669p5814769.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
t;
> >
> >
> > -
> > BR, tibor17
> > --
> > View this message in context:
> >
> http://maven.40175.n5.nabble.com/Only-one-POM-with-dependencyManagement-for-entire-company-tp5814669p5814678.html
> > Sent from the Maven Developers mailing list ar
r several customers using other (not-so-Maven-friendly)
app servers I've created similar BOMs.
/Anders
>
>
>
> -
> BR, tibor17
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Only-one-POM-with-dependencyManagement-for-entire-company-tp5814669p5
interest. :(
-
BR, tibor17
--
View this message in context:
http://maven.40175.n5.nabble.com/Only-one-POM-with-dependencyManagement-for-entire-company-tp5814669p5814678.html
Sent from the Maven Developers mailing list archive at Nabble.com
:
> Hi All,
>
> I would like to get your help. I am still trying to explain that very large
> commercial company (don't mean ASF) should not have one hotspot POM with
> only one dependencyManagement (DM). One DM is too weak rule, i would say.
>
> My arguments are that one
Hi All,
I would like to get your help. I am still trying to explain that very large
commercial company (don't mean ASF) should not have one hotspot POM with
only one dependencyManagement (DM). One DM is too weak rule, i would say.
My arguments are that one DM section will not fit to the nee
See also https://jira.codehaus.org/browse/MRELEASE-594
Some background info: the maven-release-plugin ensures that the *used*
dependencies of the project are final.
If a dependency is *defined* as SNAPSHOT in dependencyManagement but it
isn't used, the release is considered stable.
Ho
Hello everyone,
I was wondering why the resolution of snapshots in the dependency
section is implemented but the resolution of snapshots in the
dependencyManagement section is not. There is also a @TODO comment
regarding this at CheckDependencySnapshots.java line 148.
As far as I can see
Hello,
I am using dependencyManagement and including a pom with with a scope of
import so I can include it's dependencies' versions. It works as expected
except for two things:
-the versions plugin can't seem to update this dependency.
-the release plugin doesn't accept a
Brian, I'll then close MENFORCER-19 and comment with a link to
dependency:analyse-dpt-mgt
Baptiste, Mojo.codehaus.org could be a good place for such
contributor-driven incubator.
We allready merged some major mojo plugins into maven ones.
2011/2/3 Baptiste MATHUS
> Hi all,
>
> I've been thinkin
Hi all,
I've been thinking about enforcer rules for some times.
I think it would be a good thing to have a kind of enforcer-rules-incubator
project somewhere that would encourage users share¢ralize their rules.
I personnally have already written rules that I think are not very specific
to my orga
You could simply add a flag or alternate mojo to the dependency plugin
to allow it to fail. IIRC the analyze goal already does this. IOW it's
not a requirement that every mojo that fails a build be rolled into
the enforcer plugin. Failing that, you'd have to pull all the logic
out into a shared com
Hi folks,
I'd like to work on MENFORCER-19,
org.apache.maven.plugin.dependency.AnalyzeDepMgt has all the necessary code
to create an EnforcerRule "EnforceDependencyManagement", but I wonder how we
should manage such code duplication. Copy/paste some hundred lines from
dependency plugin into enforc
wing:
>
>
> scan all project (and sub poms) for "Company" specific dependencies added
> specifying a version
>
> - versions should only be specified in dependencyManagement sections.
> Fail if we find specific versions explicitly defined.
>
>
> This initial
>
>
> scan all project (and sub poms) for "Company" specific dependencies added
> specifying a version
>
> - versions should only be specified in dependencyManagement sections.
> Fail if we find specific versions explicitly defined.
>
>
> This initial
ur team to perform the following:
scan all project (and sub poms) for "Company" specific dependencies added
specifying a version
- versions should only be specified in dependencyManagement sections.
Fail if we find specific versions explicitly defined.
This initially feels like a
ailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2008 5:05 AM
To: dev@maven.apache.org
Cc: Julian Payne
Subject: Specifying a repository in pluginManagement or
dependencyManagement
I have some plugins and dependencies that are published to their own
repositories and I want to be able to specify
I have some plugins and dependencies that are published to their own
repositories and I want to be able to specify for a given dependency
which repository to use to look for new versions. Ideally I would be
like to be able to do something like this in my pom (I use jtidy as an
example but I also ha
Shane Isbell wrote:
>>
>>I've been refactoring more of the project builder
>>code and encountered a
>>rule that if a
>>dependencyManagement/dependencies/dependency
>>element ha
te:
I've been refactoring more of the project builder
code and encountered a
rule that if a
dependencyManagement/dependencies/dependency
element has
type=pom and scope=import, the de
ote:
Ralph Goers wrote:
Ralph Goers wrote:
Shane Isbell wrote:
I've been refactoring more of the project builder
code and encountered a
rule that if a
dependencyMa
Hi Shane,
A few questions on this:
On 26/08/2008, at 12:26 AM, Shane Isbell wrote:
Basically, you just put in into the pom. The id
references an external pom snippet and injects it.
What does the id look like? Is the snippet a standalone file, or is it
referenced from an existing POM? And
ECTED]> wrote:
>
>
>
> Ralph Goers wrote:
>
>>
>>
>> Ralph Goers wrote:
>>
>>>
>>>
>>> Ralph Goers wrote:
>>>
>>>>
>>>>
>>>> Shane Isbell wrote:
>>>>
>>>>> I&
Ralph Goers wrote:
Ralph Goers wrote:
Ralph Goers wrote:
Shane Isbell wrote:
I've been refactoring more of the project builder code and
encountered a
rule that if a dependencyManagement/dependencies/dependency element
has
type=pom and scope=import, the dependency management se
Ralph Goers wrote:
Ralph Goers wrote:
Shane Isbell wrote:
I've been refactoring more of the project builder code and
encountered a
rule that if a dependencyManagement/dependencies/dependency element has
type=pom and scope=import, the dependency management section of that
depen
Ralph Goers wrote:
Shane Isbell wrote:
I've been refactoring more of the project builder code and encountered a
rule that if a dependencyManagement/dependencies/dependency element has
type=pom and scope=import, the dependency management section of that
dependency should be imported int
Shane Isbell wrote:
I've been refactoring more of the project builder code and encountered a
rule that if a dependencyManagement/dependencies/dependency element has
type=pom and scope=import, the dependency management section of that
dependency should be imported into the containing pom
Aside from the potential for solving this in the new project builder
code, the existing implementation has a major limitation:
If a parent POM specified a child in its dependencyManagement section
with scope == import, and that child specifies this parent POM in its
section, then you wind up
I've been refactoring more of the project builder code and encountered a
rule that if a dependencyManagement/dependencies/dependency element has
type=pom and scope=import, the dependency management section of that
dependency should be imported into the containing pom model. This is a
one-off
Crosspost to dev list.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tue 1/22/2008 2:51 PM
To: Maven Users List
Subject: RE: Report for dependencyManagement and pluginManagement
I have searched for this, but couldn't find it. I've started to imple
gt; Incidentally - Anyone know if there is an option
> that
> > makes the eclipse plugin create eclipse projects
> for
> > projects with packaging pom. This would be really
> > nice for editing the dependencyManagement section
> of
> > the pom.
> >
> &
This is a long standing and popular issue in JIRA.
On 12/3/06, Ole Ersoy <[EMAIL PROTECTED]> wrote:
Hi,
If I override a dependency
in a child pom, and then
run
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comma
n that
makes the eclipse plugin create eclipse projects for
projects with packaging pom. This would be really
nice for editing the dependencyManagement section of
the pom.
Here is the section of this document containing the
test for this (The mail parser may nix some of the
entities)
Challenge
/directory/sandbox/oersoy/maven-testing/eclipse-maven-testing.apt
Incidentally - Anyone know if there is an option that
makes the eclipse plugin create eclipse projects for
projects with packaging pom. This would be really
nice for editing the dependencyManagement section of
the pom.
Here is the section
On 15 Sep 06, at 4:06 PM 15 Sep 06, Ralph Goers wrote:
OK. Could someone apply the patch I provided for http://
jira.codehaus.org/browse/MNG-1577 and verify it?
If you add tests I will apply it. I don't have time to check it and
verify it right now. A test would expedite the review of thi
OK. Could someone apply the patch I provided for
http://jira.codehaus.org/browse/MNG-1577 and verify it?
Ralph
Carlos Sanchez wrote:
Is not that we don't want to see that fixed, but we're very busy. A
patch would help to get it solved earlier.
---
Add an option to enforce dependencyManagement
-
Key: MNG-2128
URL: http://jira.codehaus.org/browse/MNG-2128
Project: Maven 2
Type: New Feature
Components: Dependencies
Versions: 2.0.3, 2.0, 2.0.1, 2.0.2
[ http://jira.codehaus.org/browse/MNG-2128?page=all ]
Carlos Sanchez updated MNG-2128:
Fix Version: 2.1
> Add an option to enforce dependencyManagement
> -
>
> Key: MNG-2128
>
Is not that we don't want to see that fixed, but we're very busy. A
patch would help to get it solved earlier.
On 2/28/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
> OK. Thanks for the info. But until
> http://jira.codehaus.org/browse/MNG-1577 is fixed I'm afraid I will have
> to stick with Maven 1.
OK. Thanks for the info. But until
http://jira.codehaus.org/browse/MNG-1577 is fixed I'm afraid I will have
to stick with Maven 1.0.2. FWIW, the vote count on that issue has gone
from 3 to 8 since I started this thread yesterday. I guarantee it will
go much higher.
Carlos Sanchez wrote:
Y
You don't have guarantee of wich one will be chosen, althoug it will
be always the same.
On 2/28/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
> And if A -> B -> D1.0 and
>-> C -> D2.0
> who wins?
>
>
> Carlos Sanchez said:
> > No, closest in the dependency graph means that the deepes
And if A -> B -> D1.0 and
-> C -> D2.0
who wins?
Carlos Sanchez said:
> No, closest in the dependency graph means that the deepest dep is
> overriden
>
> If A -> B -> C1.0 and A -> C2.0
> then C2.0 wins because id closer to your project (A)
>
> On 2/28/06, Ralph Goers <[EMAIL PROTE
No, closest in the dependency graph means that the deepest dep is overriden
If A -> B -> C1.0 and A -> C2.0
then C2.0 wins because id closer to your project (A)
On 2/28/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
> Carlos Sanchez said:
> > To be clear:
> > You never have two artifacts in the class
Carlos Sanchez said:
> To be clear:
> You never have two artifacts in the classpath with same
> groupId:artifactId, maven uses the "nearer" version always, which is
> the one closest to your project in the transitive dependency graph,
> not the most recent version.
Is that the same as saying it us
To be clear:
You never have two artifacts in the classpath with same
groupId:artifactId, maven uses the "nearer" version always, which is
the one closest to your project in the transitive dependency graph,
not the most recent version.
On 2/28/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Ralph G
where the control lies in choosing versions. We
believe it needs to be at a global (i.e. corporate wide) scope. Changes
to versions of third party jars always start with our lowest level
framework compoents and percolate their way up.
As I said, Maven could even emit Warnings when it detects that
to be?
> >> Our configuration management dept requires that all our projects use
> >> the same versions of xerces, xalan, etc. This is controlled via the
> >> build.properties file. Putting it in each project's POM still leads
> >> to the possibility that other
Steve Loughran wrote:
No. I have a properties file that lays down the dependencies for
everything in my project, like log4j, across
about 20 different sub projects.
These have template pom files that hard code what they depend on, but
the actual version of what they depend on is driven by my
Ralph Goers wrote:
Steve,
What you are proposing is to basically bypass maven and "hack" the pom's
dynamically with the versions required. It seems to me it would be
easier to have a process to do that in one's local repository. Then you
only have to do it once. But then you don't have a re
t other projects will use different versions.
So it sounds like I have to have a dependencyManagement section in a
master pom and then each project has to specify all its dependencies
and this will then cause the versions specified in transitive
dependencies not to be used?
Ralph
Its an inte
is is controlled via the
build.properties file. Putting it in each project's POM still leads to
the possibility that other projects will use different versions.
So it sounds like I have to have a dependencyManagement section in a
master pom and then each project has to specify all its dependencies
Thanks. I guess I'm not the first to feel this is a major design error.
Carlos Sanchez wrote:
You can vote for the issue http://jira.codehaus.org/browse/MNG-1577
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addition
a the
build.properties file. Putting it in each project's POM still leads to
the possibility that other projects will use different versions.
So it sounds like I have to have a dependencyManagement section in a
master pom and then each project has to specify all its dependencies and
this will
the incorrect default behavior for anyone -
> unless everyone is forced to disable transitive dependencies.
>
> Without this control projects will very quickly have multiple versions
> of jars.
>
> So am I missing something? Is there another configuration item that can
> be s
> of jars.
>
> So am I missing something? Is there another configuration item that can
> be specified on a dependency in the dependencyManagement section to
> cause it to override child poms?
>
> Unfortunately, unless this is remedied we will be forced to stick with
> Mave
to disable transitive dependencies.
Without this control projects will very quickly have multiple versions
of jars.
So am I missing something? Is there another configuration item that can
be specified on a dependency in the dependencyManagement section to
cause it to override child poms?
Unfo
AIL PROTECTED]>
To:
Sent: Wednesday, February 15, 2006 11:10 AM
Subject: Bug in POM validation when using dependencyManagement
Hi,
I make extensive use of the dependencyManagement section over multiple POM
hierchies.
I have them setup like this:
${pom.groupId}
Hi,
I make extensive use of the dependencyManagement section over multiple
POM hierchies.
I have them setup like this:
${pom.groupId}
some-artifact
${some-artifact}
The actual version is defined in the same POM in the
section as e.g. 1.0
${version} in dependencyManagement is replaced after release:prepare
Key: MRELEASE-70
URL: http://jira.codehaus.org/browse/MRELEASE-70
Project: Maven 2.x Release Plugin
Type: Bug
Environment: xp
* the case, then I'll just have to declare the test dependencies in
each module that also needs the test scope jars. Is this correct?
Thanks.
> test scope in dependencyManagement does not appear to be transitive to
>
[ http://jira.codehaus.org/browse/MNG-385?page=all ]
Jason van Zyl updated MNG-385:
--
Component: (was: Design & Best Practices)
Bootstrap & Build
> use dependencyManagement i
[ http://jira.codehaus.org/browse/MNG-385?page=all ]
Jason van Zyl updated MNG-385:
--
Priority: Trivial (was: Minor)
> use dependencyManagement in m2 itself
> -
>
> Key: MNG-385
>
r the easymock in the child
should already be transitive to the peer. But tests scope jars are not.
There are other problems here: eg, no group ID.
> test scope in dependencyManagement does not appear to be transitive to
> dependent
reminder to moderators not to moderate through anything from this address.
I tried emailing it, but didn't get a response. Who knows what they've done.
- Brett
[EMAIL PROTECTED] wrote:
> test scope in dependencyManagement does not appear to be transitive to
> depen
test scope in dependencyManagement does not appear to be transitive to
dependent subProjects
Key: MNG-1921
URL: http://jira.codehaus.org/browse/MNG-1921
Project: Maven 2
I believe.
> test scope in dependencyManagement does not appear to be transitive to
> dependent subProjects
>
>
> Key: MNG-1921
> URL: http://jira.codehaus.o
test scope in dependencyManagement does not appear to be transitive to
dependent subProjects
Key: MNG-1921
URL: http://jira.codehaus.org/browse/MNG-1921
Project: Maven 2
: MNG-1728)
Project: Maven 2.x Release Plugin (was: Maven 2)
> Release versioning does not work with dependencyManagement
> --
>
> Key: MRELEASE-7
> URL: http://jira.codehaus.org/browse/MRELEASE-7
>
: Maven)
Key: MRELEASE-36 (was: MNG-1374)
Project: Maven 2.x Release Plugin (was: Maven 2)
> Release plugin fails to update SNAPSHOTS in the dependencyManagement section
>
>
> Key:
: Maven)
Key: MRELEASE-36 (was: MNG-1374)
Project: Maven 2.x Release Plugin (was: Maven 2)
> Release plugin fails to update SNAPSHOTS in the dependencyManagement section
>
>
> Key:
: MNG-1728)
Project: Maven 2.x Release Plugin (was: Maven 2)
> Release versioning does not work with dependencyManagement
> --
>
> Key: MRELEASE-7
> URL: http://jira.codehaus.org/browse/MRELEASE-7
>
[ http://jira.codehaus.org/browse/MNG-1374?page=all ]
Emmanuel Venisse closed MNG-1374:
-
Resolution: Fixed
ok Mike, you're right
> Release plugin fails to update SNAPSHOTS in the dependencyManagement
[ http://jira.codehaus.org/browse/MNG-1374?page=comments#action_53118 ]
mike perham commented on MNG-1374:
--
I disagree, Emmanuel. See the last part of my comment on Dec-02-05.
> Release plugin fails to update SNAPSHOTS in the dependencyManagement sect
[ http://jira.codehaus.org/browse/MNG-1374?page=all ]
Emmanuel Venisse reopened MNG-1374:
---
We need to update dependency versions in dependencyManagement to new version
after tagging process
> Release plugin fails to update SNAPSHOTS in
dependencies.
I changed the patches, in that I added a new createDependencyArtifact(..)
method on ArtifactFactory, which will eliminate the need to call an older
variant of the method by passing in a null value for the inheritedScope
parameter.
> Optional tag in dependencyManagement is
[ http://jira.codehaus.org/browse/MNG-1374?page=all ]
John Casey closed MNG-1374:
---
Resolution: Fixed
Fix Version: 2.0.1
applied. thanks, mike
> Release plugin fails to update SNAPSHOTS in the dependencyManagement sect
pse's code
format to format per the maven spec and it reformatted a lot of the file.
> Release plugin fails to update SNAPSHOTS in the dependencyManagement section
>
>
> Key: MNG-1374
>
update SNAPSHOTS in the dependencyManagement section
>
>
> Key: MNG-1374
> URL: http://jira.codehaus.org/browse/MNG-1374
> Project: Maven 2
> Type: Bug
> Components: maven-release-plugin
&
1 - 100 of 131 matches
Mail list logo
