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,
Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
