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: 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]
