maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <bri...@infinity.nu>
Subject Re: [DISCUSS] MNG-4148 - Apply profiles from settings.xml to POMs built from the repository
Date Mon, 21 Sep 2009 12:05:33 GMT
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 <jvanzyl@sonatype.com> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message