Re: Expression evaluation
On 16 Jun 07, at 11:37 AM 16 Jun 07, Kenney Westerhof wrote: Jason van Zyl wrote: On 16 Jun 07, at 9:57 AM 16 Jun 07, Kenney Westerhof wrote: So before I write something down that's more to the point than an enumeration of the flaws in the current implementation and the problems it gives us, I'd like to get concensus about the proper way to do it.. People won't pay attention or won't have time and if you don't write down the initial thoughts as a basis it won't go anywhere. It will happen in bursts when people have time, enumerate the problems and when it's linked off that entry point in the wiki people will find it. Ok, I'll write what I think should happen then and people can comment/object ;) Exactly, that's how it starts. Didn't have much luck with the dep resolution stuff though.. Right, but I know where to look for the discussion instead of sifting through email which I find way easier. Even if someone accurately kept track of mail, it doesn't allow people new to the list to easy find out what's going on without going to the archives. I think laying down what you think should be the behavior is the best way to start, gives people something concrete to look at and work from. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Expression evaluation
Jason van Zyl wrote: On 16 Jun 07, at 9:57 AM 16 Jun 07, Kenney Westerhof wrote: So before I write something down that's more to the point than an enumeration of the flaws in the current implementation and the problems it gives us, I'd like to get concensus about the proper way to do it.. People won't pay attention or won't have time and if you don't write down the initial thoughts as a basis it won't go anywhere. It will happen in bursts when people have time, enumerate the problems and when it's linked off that entry point in the wiki people will find it. Ok, I'll write what I think should happen then and people can comment/object ;) Didn't have much luck with the dep resolution stuff though.. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Expression evaluation
On 16 Jun 07, at 9:57 AM 16 Jun 07, Kenney Westerhof wrote: So before I write something down that's more to the point than an enumeration of the flaws in the current implementation and the problems it gives us, I'd like to get concensus about the proper way to do it.. People won't pay attention or won't have time and if you don't write down the initial thoughts as a basis it won't go anywhere. It will happen in bursts when people have time, enumerate the problems and when it's linked off that entry point in the wiki people will find it. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Expression evaluation
Jason van Zyl wrote:
On 16 Jun 07, at 1:18 AM 16 Jun 07, Kenney Westerhof wrote:
Hi,
where's the spec for this?
I'm working on MNG-2651 and similar, and I'm a bit at a loss as how to
proceed.
What does the 'env.' prefix do? System props, env props, or project
props?
Should 'pom.' be the same as 'project.' or should one use the Model
and the other MavenProject?
If someone specifies a pom property (in ) like
1.1,
and the pom's version is 1.0, what should ${pom.version} evaluate to?
Idem for ${version} and a 1.1I've written a little test and it's not good. Right now, the 'context'
parameter
of the evaluation takes precedence.
My suggestion:
1) for pom.* ONLY use reflection
2) for project.* FIRST use reflection, and if that fails, goto 4
3) for env.* use System.getEnv()
4) for the rest, first check the context (system props, -D args),
5) then model properties.
6) legacy fallback: for things like ${version}, ${groupId},
${artifactId}, if the above
steps fail, prepend "pom." and try again, and log a warning.
I'll write a spec on this in 2.1 design docs if we decide on one,
since this is probably turning out to be incompatible with 2.0.x.
We can always fallback to legacy behaviour if the previous steps fail,
so that the broken poms in the repo's I've seen mentioned in the code
still work.
But the order of checking would be changed (for pom.* and project.*)
so results may
vary.
It basically comes down to: we have these pom.*, project.* and env.*
prefixes, but they aren't used at all.
Hope to get some feedback soon,
Drop "env.*" as we just shouldn't deal with envars in the core. They
should go no further then the CLI.
doesn't do anything now, but since we can access sysprops I think it's handy
to also be able to access env vars, for instance to detect certain environments
or applications that have configuration there.
For consistency in 2.1 we should deprecate "pom.*" and just use "project.*"
Yup, I agree.
Put this in a document here:
http://docs.codehaus.org/display/MAVEN/Taxonomy
Make a section for POM :: Interpolation i.e. for just make an
"Interpolation" document and link it from here:
http://docs.codehaus.org/display/MAVEN/Architectural+Goals+for+Maven+2.1
I'm going to make another pass through all the docs again today.
I want to write something, but I want to discuss the proper behaviour first,
and maybe we can even fix this in 2.0.x since right now it's a mess.
I closed about 10 issues all mentioning the same problem, and since this is
not a feature change (though we will do it better in 2.1 which _will_ be a
feature change)
but a formalization of a rather pooly documented/implemented feature, i think
we can improve 2.0.x too.
So before I write something down that's more to the point than an enumeration of
the flaws in the current implementation and the problems it gives us, I'd like
to
get concensus about the proper way to do it..
-- Kenney
Kenney
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: depMgt (mng-1577 again....)
Ralph Goers wrote: Kenney Westerhof wrote: This somewhat describes the situation: - depMgt for artifact X is used to provide defaults for direct dependencies of artifact X, and for overrides of transitive dependencies on X, unless there's also a direct dependency on X in which case the direct dependency is used. I'm sure this is not intended, so what should the intended behaviour be? Actually, from the discussions that occurred while this was being developed what you are describing is exactly what was intended. 1. Before the fix depMgt only provided defaults for direct artifacts and had no impact on transitive dependencies. 2. The first version of my path overrode both direct and transitive dependencies. Objections were raised to it doing that so it was modified to its current behavior. 3. This is OK because you have control over your depMgt and your direct dependencies. You can choose (or not) to specify versions in the dependencies. You have no such control over transitive dependencies. Either we keep the 'child overrides' that's globally present in all of maven, so that dependencies can override depMgt, as is the case now, and also apply that to transitive deps, This doesn't work. It was essentially how things worked in 2.0.6. You will never have a clue what you are going to get as you have no way to control what transitive dependencies bring in, except by artificially declaring them in projects that don't really need them. OR we let depMgt override both local and transitive deps. See above. I think you're misreading (or I am). What's the problem with depMgt ALWAYS overriding? At least that's consistent. -- Kenney Or, is this the intended behaviour after all? Yes Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depMgt (mng-1577 again....)
Jörg Schaible wrote: Kenney Westerhof wrote: Hi, Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what I found: P with dependencyManagement for lucene 1.3 | + my-dep with dependency on lucene 1.4.3 + my-app with dependency on my-dep (I modified the attached project locally; rename my-app to my-dep and add my-app with a dep on my-dep). When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is used for DEFAULTS for direct dependencies. When building my-app, after installing P and my-dep, I get lucene 1.3. So depMgt is used as OVERRIDE for transitive dependencies. Yes. When I add a dep on lucene without a version in my-app, I get 1.3 aswell. When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2. (luckily this also happens when building from the reactor). This is one of the many possible implementations I described in http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification, and it's one that I don't think we should support. The meaning of depMgt is different, applied to either local deps or transitive deps, and it's not consistent. This somewhat describes the situation: - depMgt for artifact X is used to provide defaults for direct dependencies of artifact X, and for overrides of transitive dependencies on X, unless there's also a direct dependency on X in which case the direct dependency is used. I'm sure this is not intended, so what should the intended behaviour be? No, this was *exacltly* the intended behaviour! Do you know, how often we have to add direct deps simply because depMgmt did not override the transitive deps? Ok, so you wanna be able to override transitive deps, that's fine; a good usecase. [snip] Everytime a third-party dep is upgraded, you have to check all its dependencies again. You never know in your EJB if the local deps are there to override transitive one or if they are really necessary. You have to do that too now, for your modules. If one module defines a dependency with a version different from your depMgt, you won't get the version specified in depMgt. You're shifting the problem with this solution.. Even worse, the transitive deps can change simply by adding a complete unrelated dep in your component. All because the sequence the deps are processed seems to be an iterator over a hash map. We had cases, were adding a *unrelated* dep caused the compilation of an project to fail, since suddenly a transitive dep was resolved in a different version. Yeah, that's fixed since 2.0.5; when 2 deps at the same depth have different versions, a 'random' one is chosen, depending on the hash or set implementation of your JRE. Either we keep the 'child overrides' that's globally present in all of maven, so that dependencies can override depMgt, as is the case now, and also apply that to transitive deps, OR we let depMgt override both local and transitive deps. Or, is this the intended behaviour after all? Yes, it is. Definitely for me and I reported 1577. Thanks again for those guys who implemented it. I'm ok with the fact that depMgt overrides versions. I just expected it to do just that, and not be a 'default' or 'override' depending on how many resolution nodes away a dependency was. Say project A extends P where P declares depmgt for B 1.0, and A needs B 2.0. Since dependency versions are 'hints' anyway, they shouldn't be used to override something that's designed to override; just use the override mechanism already there - the depMgt. Inheritance will make sure that any depMgt section in A overrides depMgt sections in P, so you still can have what you want. If I see a depMgt section now, I have no clue what the intent was - defaults or overrides? I'd have to scan the entire module tree to find out; and even then, it could be that for a subset of modules it was meant as an override, and for another subset as defaults. The project as a whole will have problems since there are 2 versions for a given artifact, and depending on the depth, one of them will be chosen. This is very bad imho. -- Kenney - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depMgt (mng-1577 again....)
Brian E. Fox wrote: I think you're questioning if you have this: foo com 1 foo com 2 Should you get 1 or 2? Without the direct dependency, you should get 1 if pulled in transitively. With the direct dependency as shown, you should get 2. I think you always need to maintain the ability to override at a child level if needed. No i'm not questioning that. With maven 2.0.5 and before you'd get 1, with 2.0.6 and later you get 2. I'm questioning the dubious meaning of depMgt. you cannot tell wheter it was created to declare overrides for transitive deps, or wheter it was meant as defaults for direct deps. Either way, as soon as a direct dep is added resp. removed in any child module at any depth, the meaning changes and you get a different version. It's inconsistent, and you cannot tell what a dependencyManagement section does (which version of the dep you're goanna get) without looking at the entire module tree. This has some consequences if the depMgt was inherited and sibling dependencies are used since they would ignore the declared direct dependency in some cases. Is that why you think the behavior is wrong? Exactly; they'd honor the direct dep, but if it's absent and there's a transitive one, that one may win, depending on how far the dep is away from a module. P depMgt for E at 1.0 | + A dep on B, dep on C + B dep on C, dep on E 3.0 + C dep on E version 2.0 + D dep on E, no version + X dep on A, B, C, D D would get E 1.0 C would get E 2.0 B would get E 3.0 A would get either 3.0 or 2.0 ( A -> B -> E 3.0 A -> C -> E 2.0 ) X would get: X -> A -> B -> E 3.0 X -> A -> C -> E 2.0 X -> B -> E 3.0 X -> B -> C -> E 2.0 X -> C -> E 2.0 X -> D -> E 1.0 Shortest paths are through B, C and D, so can get either 1.0, 2.0 or 3.0. Which is it? According to my tests on 3 simple projects, since E is not a direct dep from X, the depMgt overrides kick in and I should get E 1.0 on X, right? It's way to confusing this way and totally not straightforward. An element can change semantics by something far away; that's not descriptive or deterministic or repeatable. If we need 2 different ways to handle versions: 1) declare defaults for direct dependencies 2) declare overrides for transitive ones we need a new element, like 'transitiveDependencyManagement'. This is something I hope we won't support in 2.1... -- Kenney -Original Message- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Saturday, June 16, 2007 7:06 AM To: Maven Developers List Subject: depMgt (mng-1577 again) Hi, Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what I found: P with dependencyManagement for lucene 1.3 | + my-dep with dependency on lucene 1.4.3 + my-app with dependency on my-dep (I modified the attached project locally; rename my-app to my-dep and add my-app with a dep on my-dep). When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is used for DEFAULTS for direct dependencies. When building my-app, after installing P and my-dep, I get lucene 1.3. So depMgt is used as OVERRIDE for transitive dependencies. When I add a dep on lucene without a version in my-app, I get 1.3 aswell. When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2. (luckily this also happens when building from the reactor). This is one of the many possible implementations I described in http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification, and it's one that I don't think we should support. The meaning of depMgt is different, applied to either local deps or transitive deps, and it's not consistent. This somewhat describes the situation: - depMgt for artifact X is used to provide defaults for direct dependencies of artifact X, and for overrides of transitive dependencies on X, unless there's also a direct dependency on X in which case the direct dependency is used. I'm sure this is not intended, so what should the intended behaviour be? Either we keep the 'child overrides' that's globally present in all of maven, so that dependencies can override depMgt, as is the case now, and also apply that to transitive deps, OR we let depMgt override both local and transitive deps. Or, is this the intended behaviour after all? -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depMgt (mng-1577 again....)
Kenney Westerhof wrote: This somewhat describes the situation: - depMgt for artifact X is used to provide defaults for direct dependencies of artifact X, and for overrides of transitive dependencies on X, unless there's also a direct dependency on X in which case the direct dependency is used. I'm sure this is not intended, so what should the intended behaviour be? Actually, from the discussions that occurred while this was being developed what you are describing is exactly what was intended. 1. Before the fix depMgt only provided defaults for direct artifacts and had no impact on transitive dependencies. 2. The first version of my path overrode both direct and transitive dependencies. Objections were raised to it doing that so it was modified to its current behavior. 3. This is OK because you have control over your depMgt and your direct dependencies. You can choose (or not) to specify versions in the dependencies. You have no such control over transitive dependencies. Either we keep the 'child overrides' that's globally present in all of maven, so that dependencies can override depMgt, as is the case now, and also apply that to transitive deps, This doesn't work. It was essentially how things worked in 2.0.6. You will never have a clue what you are going to get as you have no way to control what transitive dependencies bring in, except by artificially declaring them in projects that don't really need them. OR we let depMgt override both local and transitive deps. See above. Or, is this the intended behaviour after all? Yes Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deployed attached snapshot artifacts have version number one higher than expected.
Hi Kenney, your solution worked fine (in 2.0.6). The problem also existed in 2.0.5. I must have created and attached the Artifact wrongly. bedankt Mark On Jun 15, 2007, at 11:19 PM, Kenney Westerhof wrote: Hi, haven't tested this myself with 2.0.6, but take a look at some other plugins that attach artifacts (javadoc, source, assembly:attached etc) to see what the differences are. Those plugins use the ProjectHelper to attach an artifact: /** * Used for attaching the artifact in the project * * @component */ private MavenProjectHelper projectHelper; projectHelper.attachArtifact( project, "javadoc", "javadoc", outputFile ); for instance. Perhaps the Artifact you created is not constructed properly. If you could try this approach and it still creates the wrong timestamp/buildnumber then you've found a bug. -- Kenney Mark Donszelmann wrote: Hi I am attaching artifacts to the main (jar) artifact in my plugin for maven. All works fine for versioned plugins, but for SNAPSHOTS I see the following behavior: 1. mvn install installs the SNAPSHOT correctly in my local repository (correctly). 2. mvn deploy -retrieves the latest build number from the remote repository (lets say 2). -deploys the main SNAPSHOT artifact with build number 3 (correctly). -deploys the pom SNAPSHOT with build number 3 (correctly). -retrieves the latest build number again (now 3, incorrectly, it should not have retrieved it). -deploys the attached SNAPSHOT artifact with build numb er 4 (should have been 3, but got confused with the previous call). this uses mvn 2.0.6 and attaches the extra artifact with a call to project.addAttachedArtifact(artifact); in the "package" phase. The standard deploy plugin and deploy goal is used. any idea why maven looks up the latest build number twice? Did I order some calls wrongly? Regards Mark Donszelmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depMgt (mng-1577 again....)
Kenney Westerhof wrote: > Hi, > > Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is > what I found: > > P with dependencyManagement for lucene 1.3 > | > + my-dep with dependency on lucene 1.4.3 > + my-app with dependency on my-dep > > (I modified the attached project locally; rename my-app to my-dep and add > my-app with a dep on my-dep). > > When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is > used for DEFAULTS for direct dependencies. > > When building my-app, after installing P and my-dep, I get lucene 1.3. So > depMgt is used as OVERRIDE for transitive dependencies. Yes. > When I add a dep on lucene without a version in my-app, I get 1.3 aswell. > > When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2. > > (luckily this also happens when building from the reactor). > > > This is one of the many possible implementations I described in > http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification, > and it's one that I don't think we should support. > > The meaning of depMgt is different, applied to either local deps or > transitive deps, and it's not consistent. > > This somewhat describes the situation: > - depMgt for artifact X is used to provide defaults for direct > dependencies of artifact X, > and for overrides of transitive dependencies on X, > unless there's also a direct dependency on X in which case the direct > dependency is used. > > > I'm sure this is not intended, so what should the intended behaviour be? No, this was *exacltly* the intended behaviour! Do you know, how often we have to add direct deps simply because depMgmt did not override the transitive deps? Every EJB has all its deps (transitive or direct) in the manifest as classpath entry. Now try to build an EAR that consists of ~10 EJBs ... this is a whole nightmare, if you cannot override the transitive deps. And the EJB will simply fail if the EAR is deployed and not all of those EJBs use the deps in the same version. Everytime a third-party dep is upgraded, you have to check all its dependencies again. You never know in your EJB if the local deps are there to override transitive one or if they are really necessary. Even worse, the transitive deps can change simply by adding a complete unrelated dep in your component. All because the sequence the deps are processed seems to be an iterator over a hash map. We had cases, were adding a *unrelated* dep caused the compilation of an project to fail, since suddenly a transitive dep was resolved in a different version. > Either we keep the 'child overrides' that's globally present in all of > maven, so that dependencies can override depMgt, as is the case now, and > also apply that to transitive deps, OR we let depMgt override both local > and transitive deps. > > Or, is this the intended behaviour after all? Yes, it is. Definitely for me and I reported 1577. Thanks again for those guys who implemented it. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Expression evaluation
On 16 Jun 07, at 1:18 AM 16 Jun 07, Kenney Westerhof wrote:
Hi,
where's the spec for this?
I'm working on MNG-2651 and similar, and I'm a bit at a loss as how
to proceed.
What does the 'env.' prefix do? System props, env props, or project
props?
Should 'pom.' be the same as 'project.' or should one use the Model
and the other MavenProject?
If someone specifies a pom property (in ) like
1.1,
and the pom's version is 1.0, what should ${pom.version} evaluate to?
Idem for ${version} and a 1.1I've written a little test and it's not good. Right now, the
'context' parameter
of the evaluation takes precedence.
My suggestion:
1) for pom.* ONLY use reflection
2) for project.* FIRST use reflection, and if that fails, goto 4
3) for env.* use System.getEnv()
4) for the rest, first check the context (system props, -D args),
5) then model properties.
6) legacy fallback: for things like ${version}, ${groupId}, $
{artifactId}, if the above
steps fail, prepend "pom." and try again, and log a warning.
I'll write a spec on this in 2.1 design docs if we decide on one,
since this is probably turning out to be incompatible with 2.0.x.
We can always fallback to legacy behaviour if the previous steps
fail, so that the broken poms in the repo's I've seen mentioned in
the code still work.
But the order of checking would be changed (for pom.* and
project.*) so results may
vary.
It basically comes down to: we have these pom.*, project.* and
env.* prefixes, but they aren't used at all.
Hope to get some feedback soon,
Drop "env.*" as we just shouldn't deal with envars in the core. They
should go no further then the CLI.
For consistency in 2.1 we should deprecate "pom.*" and just use
"project.*"
Put this in a document here: http://docs.codehaus.org/display/MAVEN/
Taxonomy
Make a section for POM :: Interpolation i.e. for just make an
"Interpolation" document and link it from here: http://
docs.codehaus.org/display/MAVEN/Architectural+Goals+for+Maven+2.1
I'm going to make another pass through all the docs again today.
Kenney
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: depMgt (mng-1577 again....)
I think you're questioning if you have this: foo com 1 foo com 2 Should you get 1 or 2? Without the direct dependency, you should get 1 if pulled in transitively. With the direct dependency as shown, you should get 2. I think you always need to maintain the ability to override at a child level if needed. This has some consequences if the depMgt was inherited and sibling dependencies are used since they would ignore the declared direct dependency in some cases. Is that why you think the behavior is wrong? -Original Message- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Saturday, June 16, 2007 7:06 AM To: Maven Developers List Subject: depMgt (mng-1577 again) Hi, Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what I found: P with dependencyManagement for lucene 1.3 | + my-dep with dependency on lucene 1.4.3 + my-app with dependency on my-dep (I modified the attached project locally; rename my-app to my-dep and add my-app with a dep on my-dep). When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is used for DEFAULTS for direct dependencies. When building my-app, after installing P and my-dep, I get lucene 1.3. So depMgt is used as OVERRIDE for transitive dependencies. When I add a dep on lucene without a version in my-app, I get 1.3 aswell. When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2. (luckily this also happens when building from the reactor). This is one of the many possible implementations I described in http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification, and it's one that I don't think we should support. The meaning of depMgt is different, applied to either local deps or transitive deps, and it's not consistent. This somewhat describes the situation: - depMgt for artifact X is used to provide defaults for direct dependencies of artifact X, and for overrides of transitive dependencies on X, unless there's also a direct dependency on X in which case the direct dependency is used. I'm sure this is not intended, so what should the intended behaviour be? Either we keep the 'child overrides' that's globally present in all of maven, so that dependencies can override depMgt, as is the case now, and also apply that to transitive deps, OR we let depMgt override both local and transitive deps. Or, is this the intended behaviour after all? -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding wildcards to IncludesArtifactFilter
Just another pointer to add. I've put together some wildcard filtering support for the assembly plugin, and factored it into a separate library so I could share it with the maven-repository- builder project. These wildcard-enabled filters are by no means perfect, but if you're interested in taking a look, they're in maven- common-artifact-filters under maven/shared. I put them here so we could re-release them independently of Maven, should the need arise. -john On Jun 15, 2007, at 5:57 PM, Brian E. Fox wrote: Mark, There are already a bunch of filters defined within dependency for a lot of this. None of them work for you or is it that you need to access them from the shared component? -Original Message- From: Mark Hobson [mailto:[EMAIL PROTECTED] Sent: Friday, June 15, 2007 9:46 AM To: Maven Developers List Subject: Re: Adding wildcards to IncludesArtifactFilter On 15/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: I think you have two different things here. The first visualizing the tree removing certain aspects and this implies the resolution is complete and you're looking at a reduction. The second is actually changing how the resolution happened in the first place. I don't think filtering has anything to do with visualization. The filtering obviously affects what shows up to be viewed, but I don't think the filter is what you want when you're looking at a dependency tree. Sure, you wouldn't typically filter with wildcards during resolution, although it is feasible. The filtering during serialisation is performed by a DependencyNodeFilter, where one of the implementations provides a bridge to ArtifactFilter. This allows us to reuse these filters, hence me adding wildcard functionality to IncludesArtifactFilter. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
depMgt (mng-1577 again....)
Hi, Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what I found: P with dependencyManagement for lucene 1.3 | + my-dep with dependency on lucene 1.4.3 + my-app with dependency on my-dep (I modified the attached project locally; rename my-app to my-dep and add my-app with a dep on my-dep). When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is used for DEFAULTS for direct dependencies. When building my-app, after installing P and my-dep, I get lucene 1.3. So depMgt is used as OVERRIDE for transitive dependencies. When I add a dep on lucene without a version in my-app, I get 1.3 aswell. When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2. (luckily this also happens when building from the reactor). This is one of the many possible implementations I described in http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification, and it's one that I don't think we should support. The meaning of depMgt is different, applied to either local deps or transitive deps, and it's not consistent. This somewhat describes the situation: - depMgt for artifact X is used to provide defaults for direct dependencies of artifact X, and for overrides of transitive dependencies on X, unless there's also a direct dependency on X in which case the direct dependency is used. I'm sure this is not intended, so what should the intended behaviour be? Either we keep the 'child overrides' that's globally present in all of maven, so that dependencies can override depMgt, as is the case now, and also apply that to transitive deps, OR we let depMgt override both local and transitive deps. Or, is this the intended behaviour after all? -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Expression evaluation
Hi,
where's the spec for this?
I'm working on MNG-2651 and similar, and I'm a bit at a loss as how to proceed.
What does the 'env.' prefix do? System props, env props, or project props?
Should 'pom.' be the same as 'project.' or should one use the Model
and the other MavenProject?
If someone specifies a pom property (in ) like
1.1,
and the pom's version is 1.0, what should ${pom.version} evaluate to?
Idem for ${version} and a 1.1We can always fallback to legacy behaviour if the previous steps fail, so that
the broken poms in the repo's I've seen mentioned in the code still work.
But the order of checking would be changed (for pom.* and project.*) so results
may
vary.
It basically comes down to: we have these pom.*, project.* and env.* prefixes,
but they aren't used at all.
Hope to get some feedback soon,
Kenney
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
