On 21/09/2009, at 7:56 PM, Benjamin Bentmann wrote:
Hi,
The current fix for this issue makes me feel a little uneasy. As is,
the code in the 2.2.x branch applies profiles from the settings in
full extent to POMs of dependencies. In particular, properties
defined by profiles from the user's settings override properties in
dependency POMs.
For example, a POM of some dependency with
<properties>
<junitVersion>3.8.2</junitVersion>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junitVersion}</version>
</dependency>
</dependencies>
becomes out of a sudden subject to the user's settings. A profile
from the user's settings that defines the property junitVersion
will, intentionally or unintentionally, change the dependency
resolution for all projects that depend on the above POM.
I agree that's not good behaviour. I'm behind on reviewing commits -
but I'd say we should correct this before 2.2.2 gets out.
Ignoring that such a significant change might not be suitable for a
bugfix release like 2.2.2, the question that we should review is how
much influence do we want to allow on the dependency POMs by the
user's settings.
Personally, I believe the only element from the POM that can be
safely subjected to interpolation using properties from the user's
settings is <dependency>/<systemPath> because this element is by its
nature environment-specific.
I think it's valid in the plugin configuration section (which are
never used transitively), and known system paths (the example you've
given is the only one I can think of), and that should be it.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
