Making resolution of things from a repository dependent on an environment is definitely dangerous. The only way I would consider it valid is if there's some default provided in the pom itself, but that's going to be difficult to enforce reliably I think.
On Mon, Sep 21, 2009 at 6:09 AM, Jason van Zyl <[email protected]> wrote: > > 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/SonatypeNexus > http://twitter.com/SonatypeM2E > ---------------------------------------------------------- > > > --------------------------------------------------------------------- > 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]
