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 <properties>) like
<pom.version>1.1</pom.version>,
and the pom's version is 1.0, what should ${pom.version} evaluate to?
Idem for ${version} and a <property><version>1.1</....?
Should we ONLY resolve pom.* and project.* from the model or;
should we default to the pom properties if the reflection fails, or;
the other way around?
I'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]
