You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benjamin Bentmann <be...@udo.edu> on 2009/09/21 11:56:01 UTC
[DISCUSS] MNG-4148 - Apply profiles from settings.xml to POMs built
from the repository
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.
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?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] MNG-4148 - Apply profiles from settings.xml to POMs
built from the repository
Posted by Stephen Connolly <st...@gmail.com>.
+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 <br...@infinity.nu>:
> 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 <jv...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] MNG-4148 - Apply profiles from settings.xml to POMs
built from the repository
Posted by Brian Fox <br...@infinity.nu>.
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 <jv...@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
Re: [DISCUSS] MNG-4148 - Apply profiles from settings.xml to POMs built from the repository
Posted by Jason van Zyl <jv...@sonatype.com>.
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
Re: [DISCUSS] MNG-4148 - Apply profiles from settings.xml to POMs built from the repository
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org