+1 Additionally, I feel that we should treat properties defined from the CLI as equivalent to properties defined in settings.xml
I see as perfectly valid to enforce no property substitution from the CLI or from settings.xml in /project/parent/(groupId|artifactId|version) /project/(groupId|artifactId|version|packaging) /project/dependencyManagement/dependencies/dependency/(groupId|artifactId|version|type|classifier) /project/dependencyManagement/dependencies/dependency/exclusions/exclusion/(groupId|artifactId) /project/dependencies/dependency/(groupId|artifactId|version|type|classifier) /project/dependencies/dependency/exclusions/exclusion/(groupId|artifactId) /project/build/pluginManagement/plugins/plugin/(groupId|artifactId|version) /project/build/pluginManagement/plugins/plugin/dependencies/dependency/(groupId|artifactId|version) /project/build/pluginManagement/plugins/plugin/dependencies/dependency/exclusions/exclusion/(groupId|artifactId) /project/build/plugins/plugin/(groupId|artifactId|version) /project/build/plugins/plugin/dependencies/dependency/(groupId|artifactId|version) /project/build/plugins/plugin/dependencies/dependency/exclusions/exclusion/(groupId|artifactId) /project/reporting/plugins/plugin/(groupId|artifactId|version) /project/reporting/plugins/plugin/dependencies/dependency/(groupId|artifactId|version) /project/reporting/plugins/plugin/dependencies/dependency/exclusions/exclusion/(groupId|artifactId) -Stephen 2009/9/21 Brian Fox <[email protected]>: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
