Re: [Maven Artifact Resolver] Different dependency resolution results

Just some details: "tweak" == added some logging to method > DependencyResult retrieve(List jackDependencies) and basically your List is unstable for the same project. And dependency ordering do matter (a LOT). Thanks T On Fri, Aug 9, 2024 at 11:32 AM Tamás Cservenák wrote: > Howdy, > > tried l

Re: [Maven Artifact Resolver] Different dependency resolution results

Howdy, tried locally, and I think I got it. But, by tweaking your code, I spotted that it is your input that is unstable (different), and hence Resolver comes up with different output as well. Make sure you feed the same input (we talk about the same test case, so project is same) for the same pro

Re: [Maven Artifact Resolver] Different dependency resolution results

Howdy, How could I reproduce this locally? T On Sat, Jul 20, 2024 at 1:28 PM Nick Hensel wrote: > Hi, > > I'm resolving dependencies with the help of Maven Artifact Resolver > (2.0) and I have an issue where resolved (transitive) dependencies > differ from run to run. Currently I'm using "new

[Maven Artifact Resolver] Different dependency resolution results

Hi, I'm resolving dependencies with the help of Maven Artifact Resolver (2.0) and I have an issue where resolved (transitive) dependencies differ from run to run. Currently I'm using "new ConfigurationVersionSelector(new ConfigurableVersionSelector.Highest())" as my VersionSelector. In most

Re: Maven profiles and dependency resolution

Hi Piotr, Thinking at it carefully, AFAIK it is a design decision done in early Maven 2 design time: - POM properties don't influence dependencies - profile activation influence dependencies (I don't know for CLI properties) The rationale is that: 1. POM properties are expected to be fixed once

Maven profiles and dependency resolution

Hello, While looking at differences in generated CycloneDX SBOMs[1] I stumbled upon an incoherence in the way Maven builds models of a project's dependencies. On one hand the properties defined in a project have no effect on the effective models of dependencies. For example in: 3.0.0-beta1

Re: Plugin dependency resolution

In the past I've tried to set several maven(core) dependencies of a plugin to provided and it broke! I didn't understand it and didn't had the time to analyze it. Just a huge warning that you can expect surprises. I think we can start thinking of "provided" if we have clear APIs and SPIs defined

Re: Plugin dependency resolution

Yup, this can be approached on "two ends": from Maven and from Plugins Note: let's name artifacts having GA org.apache.maven:maven-* as "maven runtime", artifacts being "the maven", in short: MR. >From plugin end, I never understood why MR dependencies are NOT declared as "provided". maven-p

Re: Plugin dependency resolution

Hi everyone, Does it mean we have two action items: 1. make maven plugin plugin warn or fail (with a toggle) if a maven stack plugin is in scope compile and not provided 2. filter a bit what we "know" (probably using semver in a whitelist of dependencies) 2 is not perfect from a design point of

Re: Plugin dependency resolution

Yup, "provided" scope would make it, but, as you say, it would require all (ours and non-ours) to be "fixed". Just for example, in tooling we did for Nexus 2, the NX plugin packaging (equivalent of maven plugin packaging) was ENFORCING that any NX artifact used as NX plugin dependency be declared

Re: Plugin dependency resolution

thinking about plexus-utils case: only XPP3 class is shared by Maven core Then I imagine that it that dependency is filtered at runtime, many calls from plugins to other features of that lib will fail... If you don't beat at me, I'll try to test tonight Another idea: would marking libraries as "p

Re: Plugin dependency resolution

Created https://issues.apache.org/jira/browse/MNG-7097 On Thu, Feb 11, 2021 at 8:41 AM Tamás Cservenák wrote: > Hi Robert, > > I agree with you: is a really small change. > Re non-exported packages: will take a look into those a bit more, my POC > was just at "artifact level"... (but given Maven

Re: Plugin dependency resolution

Hi Robert, I agree with you: is a really small change. Re non-exported packages: will take a look into those a bit more, my POC was just at "artifact level"... (but given Maven toss away downloaded plugin dependency, is plugin today able to use core artifact's non-exported package?) Yes, several m

Re: Plugin dependency resolution

Hi Tamas, based on the number of lines you wrote versus the amount of downloads that are prevented (and storage) I think it is worth adding. My biggest worry about this solution was about the non exported packages of the exported artifacts. Would such changes have a negative and inconsistent eff

Re: Plugin dependency resolution

Just for fun, tried it on another, a bit bigger project (137 modules), and as 3.6.3 and master was "so close", tried master and patch only: mvn master (4.0.0-alpha-1, ab20190a1a9fecdc8f85b40e8d03d806f3da4fc6) total time 1:49 min total files in local repo: 7679 total bytes in local repo: 652624 cou

Plugin dependency resolution

Howdy, Some time ago I stumbled upon Robert S. remark in "[DISCUSS] MNG-7020 Remove Maven 2 WagonExcluder backward compat code" thread: "Why download, if they are being removed from the classpath afterwards due to classworld config". Similarly, there is a thread "maven-site-plugin and sisu-inject-

Dependency resolution

Hi, My basic question is can a code base compiled entirely with maven built artifacts need any dependencies not defined in the pom? Background on my issue: I have been unable to find technical documents describing how dependencies are resolved based on the code base. I am working for a company

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

Something seems very wrong here On Thursday, 15 December 2016, Christian Schulte wrote: > Am 12/15/16 um 09:16 schrieb Christian Schulte: > > Am 12/15/16 um 07:53 schrieb Stephen Connolly: > >> That may be at odds with the code and docs but it is the only think that > >> makes sense to me, depMg

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

Am 12/15/16 um 09:16 schrieb Christian Schulte: > Am 12/15/16 um 07:53 schrieb Stephen Connolly: >> That may be at odds with the code and docs but it is the only think that >> makes sense to me, depMgmt is about managing dependencies... the bit you >> want to manage is versions and exclusions, ever

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

Am 12/15/16 um 07:53 schrieb Stephen Connolly: > That may be at odds with the code and docs but it is the only think that > makes sense to me, depMgmt is about managing dependencies... the bit you > want to manage is versions and exclusions, everything else is just the > matching as I see it Maven

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

On Wednesday, 14 December 2016, Michael Osipov wrote: > Am 2016-12-14 um 00:46 schrieb Christian Schulte: > >> That's MRESOLVER-9. Fixed the POMs with this >> > a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422> >> commit. This is wha

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

Am 2016-12-14 um 00:46 schrieb Christian Schulte: That's MRESOLVER-9. Fixed the POMs with this commit. This is what is lacking documentation the most. Does the commit message clarify wh

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

That's MRESOLVER-9. Fixed the POMs with this commit. This is what is lacking documentation the most. Does the commit message clarify what is going on? Am 12/13/16 um 20:32 schrieb Micha

Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

Am 12/13/16 um 20:32 schrieb Michael Osipov: > Hi folks, > > current Wagon master cannot be built with > > Apache Maven 3.4.0-SNAPSHOT (33c79c6e4662abb836df95a5d70c236f2e5cda3d; > 2016-12-13T20:22:49+01:00) > Maven home: D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\.. > Java version:

Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

Hi folks, current Wagon master cannot be built with Apache Maven 3.4.0-SNAPSHOT (33c79c6e4662abb836df95a5d70c236f2e5cda3d; 2016-12-13T20:22:49+01:00) Maven home: D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\.. Java version: 1.7.0_80, vendor: Oracle Corporation Java home: C:\Program

AW: Extending Mavens Dependency-Resolution Strategy?

: Maven Developers List Betreff: Re: Extending Mavens Dependency-Resolution Strategy? Have I look at https://issues.apache.org/jira/browse/MPLUGIN-302 This proposal will allow more scopes and plugins are able to select a set of dependencies based on the scope. It looks like your problem could be

Re: Extending Mavens Dependency-Resolution Strategy?

Have I look at https://issues.apache.org/jira/browse/MPLUGIN-302 This proposal will allow more scopes and plugins are able to select a set of dependencies based on the scope. It looks like your problem could be solved with this implementation. thanks, Robert On Wed, 22 Jun 2016 10:40:41 +0200

Extending Mavens Dependency-Resolution Strategy?

Hi, I am working on a new Maven plugin for building Apache Flex projects. While the Flexmojos plugin I am also maintaining seems to still be working but requiring more and more hacks, I would like to drop that and make things cleaner in a new plugin. The dependency scopes defined in Maven pe

Re: Manually triggeren dependency resolution within a plugin

No idea if I've done it the way it is supposed to be done, but check AbstractCompilerMojo#resolveProcessorPathEntries in the maven-compiler-plugin. In case it helps... :-) Am Samstag, 6. Februar 2016 schrieb Karl Heinz Marbaise : > Hi, > > If i'm in a plugin can i manually trigger the resolutio

Manually triggeren dependency resolution within a plugin

Hi, If i'm in a plugin can i manually trigger the resolution of artifacts somehow. So that MavenProject.getArtifacts() is not null... Usually you would define the mojo like this which means the resolution is done by Maven core: @Mojo( name = "", requiresDependencyResolution = Resolution

Unreadable dependency resolution/collection failure messages

Compare this original version: [ERROR] Failed to execute goal on project emerge-monolithic-services: Could not resolve dependencies for project nz.co.company.emerge:emerge-monolithic-services:jar:40.166-SNAPSHOT: Failed to collect dependencies for nz.co.company.emerge:emerge-monolithic-services:ja

aggregation and dependency resolution

-Child2 If one defines the aggregate goal in the Parent, when the plugin executes dependency resolution (obviously) hasn’t executed on the child modules. As such, my plugin is unable analyze the dependencies of the child modules. I am currently using a hack, which turns out to be broken, th

Re: maven-changes-plugin: AnnouncementMojo requires dependency resolution ResolutionScope.TEST

e/maven/plugin/announcement/AnnouncementMojo.java#L70 >> the AnnouncementMojo requires dependency resolution >> ResolutionScope.TEST >> >> Does anybody know why this is the case? >> >> Because of this it is not possible to run >> changes:announcement-generate

Re: maven-changes-plugin: AnnouncementMojo requires dependency resolution ResolutionScope.TEST

uncementMojo.java#L70 > the AnnouncementMojo requires dependency resolution > ResolutionScope.TEST > > Does anybody know why this is the case? > > Because of this it is not possible to run > changes:announcement-generate in multi module project when the > artifacts are n

maven-changes-plugin: AnnouncementMojo requires dependency resolution ResolutionScope.TEST

Hello everybody, according to https://github.com/apache/maven-plugins/blob/trunk/maven-changes-plugin/src/main/java/org/apache/maven/plugin/announcement/AnnouncementMojo.java#L70 the AnnouncementMojo requires dependency resolution ResolutionScope.TEST Does anybody know why this is the case

Choosing dependency resolution dynamically?

I've got a plugin destined for PROCESS_CLASSES. Normally, it will look only at the compile classpath. But I would like to add a scope parameter to optionally look at the test classpath. Is there some alternative to the @Mojo parameters to allow me to request test dependency resol

Re: Pluggable Dependency Resolution

some > method parameter or config tag expresses version and capability... > > LieGrue, > strub > > PS: you can at least check the backward compat of your own lib with the > maven-clirr-plugin. > > --- On Sun, 7/31/11, Jason van Zyl wrote: > >> From: Ja

Re: Pluggable Dependency Resolution

I've been meaning to check out the clirr-plugin - I'll add that to my TODO reading list for the morning. On 1/08/2011, at 12:15 AM, Mark Struberg wrote: > PS: you can at least check the backward compat of your own lib with the > maven-clirr-plugin.

Re: Pluggable Dependency Resolution

On Sun, 7/31/11, Jason van Zyl wrote: > >> From: Jason van Zyl >> Subject: Re: Pluggable Dependency Resolution >> To: "Maven Developers List" >> Date: Sunday, July 31, 2011, 11:58 AM >> What if you could find another way to >> check API compatibil

Re: Pluggable Dependency Resolution

Potentially not. I suppose if there was a way to say [2.0.0,3.0.0) *excluding SNAPSHOTS* then that would certainly be in my favor. From memory there was a discussion some time ago regarding range resolution excluding -SNAPSHOTs unless the artifacts were also in the current reactor build, from

Re: Pluggable Dependency Resolution

/11, Jason van Zyl wrote: > From: Jason van Zyl > Subject: Re: Pluggable Dependency Resolution > To: "Maven Developers List" > Date: Sunday, July 31, 2011, 11:58 AM > What if you could find another way to > check API compatibility, would you need this at all? > >

Re: Pluggable Dependency Resolution

What if you could find another way to check API compatibility, would you need this at all? On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote: > The use case that we originally came with in our discussions revolved around > version ranges, and the fact that a version reference of "2.5.4" doesn't

Re: Pluggable Dependency Resolution

On Jul 31, 2011, at 3:27 AM, Stephen Connolly wrote: > i see two concerns that need separation. > > 1. the code that fetches dependencies from wherever they live. > Sure, I've known people to change this in many ways. Integration of legacy artifact stores, migration strategies which involve p

Re: Pluggable Dependency Resolution

ok, in the past i have had discussions with Jason over version range syntax. Jason previously expoused the view that osgi format version numbers is the -only- way to have version numbers, and anything else he would not support. at the time i was working for a company where we had 5 segment version

Re: Pluggable Dependency Resolution

Not from any of my use cases no. Mark On 31/07/2011, at 10:18 PM, Hervé BOUTEMY wrote: > This lets the question of pluggable version comparison need: is there a real > world example of unwanted version order?

Re: Pluggable Dependency Resolution

Le dimanche 31 juillet 2011, Mark Derricutt a écrit : > The use case that we originally came with in our discussions revolved > around version ranges, ok, that's not a version comparison but version (range) resolution question: version ordering is here to define how artifacts are ordered, then the

Re: Pluggable Dependency Resolution

The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of "2.5.4" doesn't actually mean " give me 2.5.4" but rather "I would like 2.5.4, but meh, use something higher if you need to". In the case were you have artifacts

Re: Pluggable Dependency Resolution

I see this one regularly and don't frankly understand the need other than pure theory. Actual version comparison supports every numbering scheme I ever saw in reality. The only choice that has been made that is a pure choice (neither good nor bad, just a choice had to be made) is that unknown qu

Re: Pluggable Dependency Resolution

t; > From: Igor Fedorenko > > Subject: Re: Pluggable Dependency Resolution > > To: dev@maven.apache.org > > Date: Sunday, July 31, 2011, 7:51 AM > > It is sort-of possible to plug > > per-project dependency resolver and this > > is more or less how Tycho w

Re: Pluggable Dependency Resolution

this could be done in settings.xml! LieGrue, strub --- On Sun, 7/31/11, Igor Fedorenko wrote: From: Igor Fedorenko Subject: Re: Pluggable Dependency Resolution To: dev@maven.apache.org Date: Sunday, July 31, 2011, 7:51 AM It is sort-of possible to plug per-project dependency resolver and this is mo

Re: Pluggable Dependency Resolution

om: Igor Fedorenko > Subject: Re: Pluggable Dependency Resolution > To: dev@maven.apache.org > Date: Sunday, July 31, 2011, 7:51 AM > It is sort-of possible to plug > per-project dependency resolver and this > is more or less how Tycho works already (I can provide more > detai

Re: Pluggable Dependency Resolution

a few times and you see what I mean. After max 10 upgrades, your Eclipse installation is completely messed up as you _will_ get conflicting dependencies which don't work together nicely. --- On Sun, 7/31/11, Stephen Connolly wrote: > From: Stephen Connolly > Subject: Re: Plug

Re: Pluggable Dependency Resolution

It is sort-of possible to plug per-project dependency resolver and this is more or less how Tycho works already (I can provide more details about implementation, if you are interested). The problem is on the consumer end. What dependency resolution logic you expect to apply if standard maven

Re: Pluggable Dependency Resolution

oh i forgot to mention. i also think that version comparison rules should be plugable. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 08:27, "Stephen Connolly"

Re: Pluggable Dependency Resolution

i see two concerns that need separation. 1. the code that fetches dependencies from wherever they live. 2. the code that computed the dependencies graph. #1 should be something that is plugable, and in essence could be part of the repositories definitions... in saying that, i think we need a way

Re: Pluggable Dependency Resolution

Zyl > Subject: Re: Pluggable Dependency Resolution > To: "Maven Developers List" > Date: Saturday, July 30, 2011, 11:58 PM > On Jul 30, 2011, at 7:14 PM, Mark > Derricutt wrote: > > > Hi all, > > > > I wanted to start this discussion completely separate

Re: Pluggable Dependency Resolution

egal Argument podcast ) have often > discussed a desire to have a pluggable dependency resolution mechanism within > Apache Maven, mostly around having the ability to force maven to use the > lowest bound in a range rather than the highest for highlight fast-fail API > breakag

Re: Pluggable Dependency Resolution

27;s > Gentoo resolution issues. Replying to my own post ;-) I was just having the thought that doing something like moving the toolchains-plugin into core, and making use of this as a means to choose your dependency resolution. If we combined this idea with the discussion of a new version of t

Pluggable Dependency Resolution

Hi all, I wanted to start this discussion completely separate from any of the other, rather heated ASL vs EPL discussions around Aether to try and keep this more on topic. For awhile we ( members of the Illegal Argument podcast ) have often discussed a desire to have a pluggable dependency

Re: Release plugin snapshot dependency resolution

On 04/10/2010, at 6:06 PM, Marcus Linke wrote: > OK accepted. But if this shouldn't be within the responsibility of the > release plugin but of the versions plugin, do you know a possibility to > hide this versions plugin goal execution from the users point of view? So > is there a way to hook in

Re: Release plugin snapshot dependency resolution

On 04/10/2010, at 10:36 PM, Marcus Linke wrote: > Hi brett, of course it is. So should i open a new issue for this feature > in the JIRA or will you do so? ;) It's all yours. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ --

Re: Release plugin snapshot dependency resolution

Hi brett, of course it is. So should i open a new issue for this feature in the JIRA or will you do so? ;) "Maven Developers List" writes: >On 04/10/2010, at 6:06 PM, Marcus Linke wrote: > >> OK accepted. But if this shouldn't be within the responsibility of the >> release plugin but of the vers

Re: Release plugin snapshot dependency resolution

OK accepted. But if this shouldn't be within the responsibility of the release plugin but of the versions plugin, do you know a possibility to hide this versions plugin goal execution from the users point of view? So is there a way to hook in the versions plugin goal execution into the release proc

Re: Release plugin snapshot dependency resolution

On 30/09/2010, at 7:05 PM, Marcus Linke wrote: > For my own usecase where we have strongly coupled projects and usually > changes are made in both projects we desire behavior b) but other users > would like prefer behavior a). Understood, but we're talking about the default behaviour, and it see

Re: Release plugin snapshot dependency resolution

The part where you say: >> I retained one exception for the use case where it was a more recent >> snapshot than the release you selected, and the original choice is restored. I like (+1). One use case I see for this is where the dependency is actually a parent pom. Here's an example: Conside

Re: Release plugin snapshot dependency resolution

On 2010-09-29 15:50, Brett Porter wrote: > Hi, > > The release plugin has a mode where it can assist you in updating snapshot > dependencies at release time. A lot of this is better manipulated with the > versions plugin now, but it seems a useful feature to have at release time if > you can. >

Re: Release plugin snapshot dependency resolution

> The first question was redundant - you'd already said you wanted to update > snapshots and the other option is failure. The second one assumes you'll be > setting the snapshot to the equivalent release, then automatically to the > next dev't version. The inflexibility of the first part was poi

Re: Release plugin snapshot dependency resolution

The release plugin must avoid snapshot dependencies in the release of an artifact. This is true. But the question is whether the dependency is kicked to the next snapshot in the next development version of that artifact or it stays at the release version. For example project A depends on artifact B

Re: Release plugin snapshot dependency resolution

+1 On 29 September 2010 14:50, Brett Porter wrote: > Hi, > > The release plugin has a mode where it can assist you in updating snapshot > dependencies at release time. A lot of this is better manipulated with the > versions plugin now, but it seems a useful feature to have at release time > if y

Re: Release plugin snapshot dependency resolution

+1 too. Personnally I'd like we fix MRELEASE-594 too. IMHO it's not a "normal" practice and cause some issues when releasing childs. We should at least ask user thru an interactive question "Are you sure you want to release with SNAPSHOT declaration(s) in depMgmt ?" (or something similar). WDYT

Re: Release plugin snapshot dependency resolution

>>> >> >> That's what it does - it still fails if there are snapshots. It gives you >> the option if it finds a snapshot to let you change that to a released >> version. > > What's the use case here? You have a snapshot of log4j and there's a release > version you can use? > > POM says 2.0-S

Re: Release plugin snapshot dependency resolution

Brett Porter wrote: However, I disagree with the default choice of updating the dependency to another snapshot - since this is outside of the reactor it's a better practice to pin to the release you just chose. I retained one exception for the use case where it was a more recent snapshot than

Re: Release plugin snapshot dependency resolution

On Sep 29, 2010, at 11:25 AM, Brett Porter wrote: > > On 29/09/2010, at 11:57 PM, Jason van Zyl wrote: > >> >> On Sep 29, 2010, at 9:50 AM, Brett Porter wrote: >> >>> Hi, >>> >>> The release plugin has a mode where it can assist you in updating snapshot >>> dependencies at release time. A l

Re: Release plugin snapshot dependency resolution

On 29/09/2010, at 11:57 PM, Jason van Zyl wrote: > > On Sep 29, 2010, at 9:50 AM, Brett Porter wrote: > >> Hi, >> >> The release plugin has a mode where it can assist you in updating snapshot >> dependencies at release time. A lot of this is better manipulated with the >> versions plugin now

Re: Release plugin snapshot dependency resolution

On Sep 29, 2010, at 9:50 AM, Brett Porter wrote: > Hi, > > The release plugin has a mode where it can assist you in updating snapshot > dependencies at release time. A lot of this is better manipulated with the > versions plugin now, but it seems a useful feature to have at release time if >

Release plugin snapshot dependency resolution

Hi, The release plugin has a mode where it can assist you in updating snapshot dependencies at release time. A lot of this is better manipulated with the versions plugin now, but it seems a useful feature to have at release time if you can. The previous behaviour was a bit weird, though. It wo

Re: Question on transitive dependency resolution

The managing of Child A doesn't necessarily mean that Child A's dependencies are weighed higher than other direct dependencies. Also, given the same depth in the tree, the first version processed for a given group:artifact wins...ie the order in the pom can have subtle impacts. On Mon, Sep 28, 200

Re: Question on transitive dependency resolution

can't rely 100% on the output of particular plugins wrt > dependency resolution because they can all change the output with different > input parameters and artifact filters. > > > On 2009-09-28, at 8:54 PM, Paul Benedict wrote: > > I have a project structure like this:

Re: Question on transitive dependency resolution

Make a test project to express the problem. In almost all cases it's impossible to debug or discuss this without a test project everyone can run. Unfortunately you can't rely 100% on the output of particular plugins wrt dependency resolution because they can all change the o

Question on transitive dependency resolution

I have a project structure like this: Parent A * Declares managed dependency org.slf4j:slf4j-api:1.5.8 * Declares managed dependency org.hibernate:hibernate-core:3.3.1.GA * Declares managed dependency org.hibernate:hibernate-annotations:3.4.0.GA Child A * Depends on org.hibernate:hibernate

RE: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM & multi-level dependency resolution)

Brett, > -Original Message- > From: Brett Porter > Sent: maandag 15 december 2008 9:50 > To: Maven Developers List > Subject: Re: BUG? Profile properties not used to resolve > dependencies transitively. (was RE: Version property in root > POM & multi-le

Re: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM & multi-level dependency resolution)

& multi-level dependency resolution) No it doesn't - it should. I think that's a bug. I don't generally encourage using a property from the command line or settings, but your use case sounds valid, and I think that's being used in the hudson builds Jason was referring to a

RE: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM & multi-level dependency resolution)

Brett, > -Original Message- > From: Brett Porter > Sent: donderdag 11 december 2008 17:23 > To: Maven Developers List > Subject: Re: BUG? Profile properties not used to resolve > dependencies transitively. (was RE: Version property in root > POM & multi-le

Re: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM & multi-level dependency resolution)

On 12/12/2008, at 3:10 AM, De Smet Ringo wrote: Brett, -Original Message- From: Brett Porter Ok, I see what you mean. You illustrated the property in the project which should not work. But from settings.xml and the command line it should. Unfortunately, it doesn't, or again I'm mis

RE: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM & multi-level dependency resolution)

Brett, > -Original Message- > From: Brett Porter > > Ok, I see what you mean. You illustrated the property in the > project which should not work. But from settings.xml and the > command line it should. Unfortunately, it doesn't, or again I'm misinterpreting you. :-) The three attac

Re: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM & multi-level dependency resolution)

On 12/12/2008, at 12:39 AM, De Smet Ringo wrote: The value is overridden for the project under build, but not for the transitive dependencies. Are you surprised that I find this an inconsistent result? :-) Ok, I see what you mean. You illustrated the property in the project which should

RE: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM & multi-level dependency resolution)

Brett, > -Original Message- > From: Brett Porter > > It looks like the intended behaviour to me, the same as if > you pulled the properties out of the profile. Properties are > not transitively applied. Can you give me some more background on the why of this decision. If you re-read m

Re: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM & multi-level dependency resolution)

On 11/12/2008, at 11:54 PM, De Smet Ringo wrote: [INFO] The following files have been resolved: [INFO]be.atriso.test:a:pom:1.0-SNAPSHOT:compile [INFO]junit:junit:jar:3.8.1:compile Is this a bug, or is this intended behaviour? It looks like the intended behaviour to me, the same as i

BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM & multi-level dependency resolution)

before the interpolation is executed. Any comments? Ringo > -Original Message- > From: De Smet Ringo > Sent: woensdag 10 december 2008 12:49 > To: dev@maven.apache.org > Subject: Version property in root POM & multi-level > dependency resolution > > Hello, &

RE: Version property in root POM & multi-level dependency resolution

Stephen, > -Original Message- > From: Stephen Connolly [mailto:[EMAIL PROTECTED] > Sent: woensdag 10 december 2008 14:01 > To: Maven Developers List > Subject: Re: Version property in root POM & multi-level > dependency resolution > > I'm not sure wher

Re: Version property in root POM & multi-level dependency resolution

y in root POM & multi-level > > dependency resolution > > > > Have a look at versions:update-properties... (you'd need > > version 1.0-alpha-2 or newer) > > > > I'd structure things a little differently... but it might > > help you achieve your end-go

RE: Version property in root POM & multi-level dependency resolution

Stephen, > -Original Message- > From: Stephen Connolly [mailto:[EMAIL PROTECTED] > Sent: woensdag 10 december 2008 13:12 > To: Maven Developers List > Subject: Re: Version property in root POM & multi-level > dependency resolution > > Have a look a

Re: Version property in root POM & multi-level dependency resolution

there. Now comes the point where I think Maven is failing. Here is the > output of "mvn dependency:resolve" of pres.d: > > [INFO] The following files have been resolved: > [INFO] be.telenet.test:common:jar:9.10.4:compile > [INFO] be.telenet.test:srv.a:jar:9.10-SNAPSHOT:compile

Version property in root POM & multi-level dependency resolution

[INFO] The following files have been resolved: [INFO] be.telenet.test:common:jar:9.10.4:compile [INFO] be.telenet.test:srv.a:jar:9.10-SNAPSHOT:compile The dependency resolution correctly resolved the dependency from pres.d on srv.a to 9.10-SNAPSHOT, but it seems to ignore my overridden prope

Re: Enforcer Plugin and Dependency Resolution

This is a good idea, can you add it to the atypical plugin use cases page John put on docs.codehaus.org? Left a comment at http://docs.codehaus.org/display/MAVEN/Atypical+Plugin+Use+Cases that points to this thread. Benjamin -

RE: Enforcer Plugin and Dependency Resolution

Dependency Resolution Hi, the Enforcer Plugin is usually executed in the "validate" phase and requires resolution of dependencies. This constellation can cause build failures. Consider an Enforcer-enabled multi-project build with a parent and two modules A and B where B has a depen

Enforcer Plugin and Dependency Resolution

applies to a freshly created project whose "1.0-SNAPSHOT" artifacts have never been build before. In such a situation, executing any lifecycle phase before "install" will cause the build to fail because the dependency resolution for module B triggered by the Enforcer cannot fin

Re: Dramatically speed up dependency resolution

On 1/29/08, Tom Huybrechts <[EMAIL PROTECTED]> wrote: > Did you build this on java 6? > > I'm getting bad class version errors on java 5: Strange, I would have thought the Maven 2 build would have been configured to target 1.4. Anyways, I rebuilt with Java 5 and updated the snapshot on people.apa

Re: Dramatically speed up dependency resolution

Also I will look when you have some tests as I was about to look and glad Tom tried it. On 28-Jan-08, at 3:42 AM, Don Brown wrote: On 1/28/08, Tom Huybrechts <[EMAIL PROTECTED]> wrote: I just tried it out and sometimes got this error halfway through a build: Doh, forgot to synchronize the

Re: Dramatically speed up dependency resolution

Did you build this on java 6? I'm getting bad class version errors on java 5: + Error stacktraces are turned on. - this realm = plexus.core urls[0] = file:/c:/dev/tools/maven/lib/maven-2.0.9-SNAPSHOT-uber.jar Number of imports: 0 ---

  1   2   >