On 2009-09-21, at 5:56 AM, 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.
Agreed. If you allow anything to be interpolated in a dependency and
then inject properties from settings.xml you have complete instability.
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.
WDYT?
I think we need to targeted sections of the POM that can be influenced
by properties defined in settings, or any non-POM source really, and
specify how they are applied. I can see the systemPath in the
dependency being an option as you say (but it would be nice find
another way to keep non-POM properties from touching dependencies all
together) and plugin configurations. For plugin configurations I'm
thinking of the specific use case where the user is specifying some
username/password type information that is local to the user. In any
event I think we should satisfy very narrow use cases instead of
letting anything happen.
Could probably have an enforcer rule to examine all the ${element}s in
the POM and determine if they are in the POM hierarchy and if they are
not blow up unless they are in the specifically targeted sections of
the POM.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
