You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2009/11/27 12:57:28 UTC

Re: User's project-specific properties ability disabled after MNG-4060

On 2009-11-27, at 5:55 AM, Milos Kleint wrote:

> I agree with Robert here.
> removal of profiles.xml file leaves maven with no non-sharable, per- 
> project
> configuration option. I"ve added my example to
> the issue http://jira.codehaus.org/browse/MNG-4060.
> It would be doable with settings.xml but it would be uber-cumbersome  
> to do
> so.

Why?

I think an activator for a gav would work nicely.

> It could partly work, but only when you work on one set of projects
> only, or keep on  switching the settings file and have a separate  
> copy for
> each project (or set of projects).
>

The profiles.xml made the internals extremely convoluted and hard to  
test. Most of the use cases I've seen are resolved by settings.xml and  
that can be made to be more intelligent to actually scope the profile  
in settings.xml to a specific project would effectively be the same  
thing, or the project needed to be decomposed into smaller projects.

I'm fine with profiles.xml but you'll need to do the work to integrate  
that back into the project builder and build up the integration tests.  
I'm not interested in this work as I honestly don't think it's  
necessary. There are tests enough there to catch anything so you can  
do the work and know if you've disturbed any other part of the system  
so you should be good to go if you want to add this support back in.

>
> Milos
>
> On Thu, Jun 25, 2009 at 8:14 PM, Robert Scholte <rfscholte@codehaus.org 
> >wrote:
>
>>
>> I didn't say it's not possible without profiles.xml, but without it  
>> you
>> have
>> to make a choice between the best of the worst.
>> Let's stick to the passwords. You don't want to expose them in the  
>> pom.xml,
>> right?
>> But what if project A en project B both have a ${password} in their
>> pom.xml,
>> from the settings.xml you can't figure out which password to use,  
>> UNLESS
>> you
>> have to keep settings the specific profile per project. Not really  
>> nice.
>> But let me reverse the question. Why was the profiles.xml  
>> introduced and
>> what made it the team to say goodbye to this file?
>>
>> Robert
>>
>>
>> BRIAN FOX-5 wrote:
>>>
>>> Well, the mixin support should cover the profiles.xml and  
>>> more....even
>>> better it should be possible to resolve the mixins from the  
>>> repository
>>> which
>>> means they are versioned and deployed artifacts like everything  
>>> else.
>>>
>>> On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte
>>> <rf...@codehaus.org>wrote:
>>>
>>>>
>>>> In the settings.xml it's not possible to activate a profile by  
>>>> project.
>>>> Then
>>>> again: I believe settings.xml are actually maven-settings and not
>>>> project-settings. For most users it's a big step to dive into the
>>>> settings.xml. For them there are only a few reasons to access the
>>>> settings
>>>> file:
>>>> - to setup a proxy repository like nexus (which is often done by  
>>>> a more
>>>> experienced user)
>>>> - to set username+pw for a specific server.
>>>> If they don't have to touch the file then leave it, 'cause  
>>>> changes here
>>>> might break maven.
>>>> And a user-specific project-profile has to be located on a very  
>>>> logic
>> and
>>>> easy to access location, so the best option is next to the pom I  
>>>> guess.
>>>>
>>>> -regards,
>>>>
>>>> Robert Scholte
>>>>
>>>>
>>>>
>>>> BRIAN FOX-5 wrote:
>>>>>
>>>>> Why not just put those values into the settings.xml?
>>>>>
>>>>> On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte<
>> rfscholte@codehaus.org>
>>>>> wrote:
>>>>>>
>>>>>> I heard some time ago that the profiles.xml were removed in  
>>>>>> Maven3.
>>>>>> Although I'm still using 2.1.0 I want to be prepared for such
>> changes.
>>>>>>
>>>>>> IMHO I think it's a bad choice to remove this option.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Maven should provide some sort of way where developers can set/ 
>>>>>> change
>>>>>> project properties without having to change the pom.xml.
>>>>>>
>>>>>> I believe the pom should not contain developer-specific  
>>>>>> properties
>> and
>>>>>> which can or will end up in any scm. Think of datasource- 
>>>>>> properties.
>>>>>>
>>>>>>
>>>>>>
>>>>>> There are three degrees of properties:
>>>>>>
>>>>>> - the global properties (combined with the activeByDefault- 
>>>>>> profile)
>>>>>>
>>>>>> - profile-properties (where profiles cover multiple users. By OS,
>>>>>> 'stage')
>>>>>>
>>>>>> - personal properties.
>>>>>>
>>>>>>
>>>>>>
>>>>>> These personal properties can only be used with a personal  
>>>>>> profile. A
>>>>>> personal profile is the best example of data which doesn´t  
>>>>>> belong in
>> a
>>>>>> pom but in a separate file (and probably not in scm).
>>>>>>
>>>>>> Personal properties should be somewhere close to the project,  
>>>>>> like in
>>>> the
>>>>>> root of the project (yes, like the profiles.xml).
>>>>>>
>>>>>> The both settings.xml is too far from the project and there's no
>>>> option
>>>>>> in the (user's) settings.xml to set project-specific properties.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I think that if there was a vote concerning this issue it might
>> result
>>>> in
>>>>>> a long discussion. It's never too late for that, so let's give  
>>>>>> it a
>>>> try.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _________________________________________________________________
>>>>>> Express yourself instantly with MSN Messenger! Download today  
>>>>>> it's
>>>> FREE!
>>>>>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html
>>>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24209431.html
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
----------------------------------------------------------


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


Re: User's project-specific properties ability disabled after MNG-4060

Posted by Jason van Zyl <ja...@maven.org>.
On 2009-11-27, at 4:32 PM, Stephen Connolly wrote:

>
>
> Sent from my [rhymes with tryPod] ;-)
>
> On 27 Nov 2009, at 21:03, Jason van Zyl <ja...@maven.org> wrote:
>
>>
>> On 2009-11-27, at 3:48 PM, Robert Scholte wrote:
>>
>>>
>>> With the alpha releases of Maven 3 published we'll see how  
>>> developers react
>>> on this issue.
>>> I've introduced Maven during several projects and my experience is  
>>> that
>>> newbies fear the settings.xml. They let a pro setup their  
>>> settings.xml for
>>> the repository and from that moment on it's an avoided territory.
>>
>> My experience does not match with yours. In most places I'm in the  
>> developers are not afraid of the tools they use on a daily basis,  
>> and the number of customizations that need to be made are  
>> relatively few.
>>
>>> This means that the personal project-settings shall be resolved in  
>>> the
>>> pom.xml. One profile entry per developer if I'm pessimistic. Ok,  
>>> maybe
>>> combined with a filter-file it's somehow acceptable, but that  
>>> requires
>>> variables in your pom for everything a developer wants to modify  
>>> personal.
>>> From an architectural point of view I can imagine that the  
>>> profiles.xml is
>>> somehow a strange mechanism. But from a developers point of view  
>>> (Jason, I
>>> read your articles about Paving the desire lines) I believe it's a  
>>> strong
>>> concept. It just gives you the force on the right spot,  
>>> personalize the
>>> project/pom at your own risk.
>>> Let's see some other responses and maybe we could reanimate the  
>>> profiles.xml
>>>
>>
>> Anyone can work with new model builder and add the support back in  
>> if they like. My only requirements are the ITs passing and the  
>> performance remains the same. Aside from that there's nothing  
>> stopping anyone from putting the support back in.
>
> I presume there is _some_ leeway with the performance... 5-10% or so  
> and certainly no worse than 2.x
>
> adding any logic is going to have at least 10ms of a performance  
> hit... so I guessy question is where is the cut-off point at which  
> you scream -1 on adding that implementation of that feature?
>

Any single feature at this point that causes more then a 5% hit is  
questionable. It's always a balance of what you're gaining and how  
much it costs. There are still lots of things to be optimized, but I  
would release 3.0 without the profiles.xml as most people are probably  
not going to adopt during 3.0 and so if there's mass hysteria we can  
think about putting it back in.

>>
>>> cheers,
>>>
>>> Robert
>>>
>>>
>>> Bugzilla from mkleint@gmail.com wrote:
>>>>
>>>> On Fri, Nov 27, 2009 at 1:59 PM, Jason van Zyl <ja...@maven.org>  
>>>> wrote:
>>>>
>>>>>
>>>>> On 2009-11-27, at 7:45 AM, Milos Kleint wrote:
>>>>>
>>>>> On Fri, Nov 27, 2009 at 12:57 PM, Jason van Zyl  
>>>>> <ja...@maven.org> wrote:
>>>>>>
>>>>>>
>>>>>>> On 2009-11-27, at 5:55 AM, Milos Kleint wrote:
>>>>>>>
>>>>>>> I agree with Robert here.
>>>>>>>
>>>>>>>> removal of profiles.xml file leaves maven with no non-sharable,
>>>>>>>> per-project
>>>>>>>> configuration option. I"ve added my example to
>>>>>>>> the issue http://jira.codehaus.org/browse/MNG-4060.
>>>>>>>> It would be doable with settings.xml but it would be uber- 
>>>>>>>> cumbersome
>>>>>>>> to
>>>>>>>> do
>>>>>>>> so.
>>>>>>>>
>>>>>>>>
>>>>>>> Why?
>>>>>>>
>>>>>>> I think an activator for a gav would work nicely.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> if there is such a thing, yes, it would help. But then after each
>>>>>> release,
>>>>>> you have to tinker with the activators.
>>>>>>
>>>>>>
>>>>> Then just G:A would do the trick.
>>>>
>>>>
>>>> ...unless you decide to work on a code branch with different  
>>>> settings
>>>> then.
>>>>
>>>>
>>>> Milos
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> It could partly work, but only when you work on one set of  
>>>>>>> projects
>>>>>>>
>>>>>>>> only, or keep on  switching the settings file and have a  
>>>>>>>> separate copy
>>>>>>>> for
>>>>>>>> each project (or set of projects).
>>>>>>>>
>>>>>>>>
>>>>>>>> The profiles.xml made the internals extremely convoluted and  
>>>>>>>> hard to
>>>>>>> test.
>>>>>>> Most of the use cases I've seen are resolved by settings.xml  
>>>>>>> and that
>>>>>>> can
>>>>>>> be
>>>>>>> made to be more intelligent to actually scope the profile in
>>>>>>> settings.xml
>>>>>>> to
>>>>>>> a specific project would effectively be the same thing, or the  
>>>>>>> project
>>>>>>> needed to be decomposed into smaller projects.
>>>>>>>
>>>>>>> I'm fine with profiles.xml but you'll need to do the work to  
>>>>>>> integrate
>>>>>>> that
>>>>>>> back into the project builder and build up the integration  
>>>>>>> tests. I'm
>>>>>>> not
>>>>>>> interested in this work as I honestly don't think it's  
>>>>>>> necessary. There
>>>>>>> are
>>>>>>> tests enough there to catch anything so you can do the work  
>>>>>>> and know if
>>>>>>> you've disturbed any other part of the system so you should be  
>>>>>>> good to
>>>>>>> go
>>>>>>> if
>>>>>>> you want to add this support back in.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Which just translates to "no". fair enough.
>>>>>>
>>>>>>
>>>>> Not at all. It means I'm not interested in that feature. So yes  
>>>>> that
>>>>> might
>>>>> translate into it's unlikely Benjamin, myself or Igor aren't  
>>>>> going to
>>>>> work
>>>>> on it but there's nothing stopping you from adding the support.  
>>>>> As long
>>>>> as
>>>>> all the ITs pass and the performance doesn't degrade have at it.
>>>>>
>>>>>
>>>>> Milos
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Milos
>>>>>>>>
>>>>>>>> On Thu, Jun 25, 2009 at 8:14 PM, Robert Scholte
>>>>>>>> <rfscholte@codehaus.org
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I didn't say it's not possible without profiles.xml, but  
>>>>>>>> without it
>>>>>>>> you
>>>>>>>>> have
>>>>>>>>> to make a choice between the best of the worst.
>>>>>>>>> Let's stick to the passwords. You don't want to expose them  
>>>>>>>>> in the
>>>>>>>>> pom.xml,
>>>>>>>>> right?
>>>>>>>>> But what if project A en project B both have a ${password}  
>>>>>>>>> in their
>>>>>>>>> pom.xml,
>>>>>>>>> from the settings.xml you can't figure out which password to  
>>>>>>>>> use,
>>>>>>>>> UNLESS
>>>>>>>>> you
>>>>>>>>> have to keep settings the specific profile per project. Not  
>>>>>>>>> really
>>>>>>>>> nice.
>>>>>>>>> But let me reverse the question. Why was the profiles.xml  
>>>>>>>>> introduced
>>>>>>>>> and
>>>>>>>>> what made it the team to say goodbye to this file?
>>>>>>>>>
>>>>>>>>> Robert
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> BRIAN FOX-5 wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Well, the mixin support should cover the profiles.xml and
>>>>>>>>>> more....even
>>>>>>>>>> better it should be possible to resolve the mixins from the
>>>>>>>>>> repository
>>>>>>>>>> which
>>>>>>>>>> means they are versioned and deployed artifacts like  
>>>>>>>>>> everything
>>>>>>>>>> else.
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte
>>>>>>>>>> <rf...@codehaus.org>wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In the settings.xml it's not possible to activate a profile  
>>>>>>>>>> by
>>>>>>>>>>> project.
>>>>>>>>>>> Then
>>>>>>>>>>> again: I believe settings.xml are actually maven-settings  
>>>>>>>>>>> and not
>>>>>>>>>>> project-settings. For most users it's a big step to dive  
>>>>>>>>>>> into the
>>>>>>>>>>> settings.xml. For them there are only a few reasons to  
>>>>>>>>>>> access the
>>>>>>>>>>> settings
>>>>>>>>>>> file:
>>>>>>>>>>> - to setup a proxy repository like nexus (which is often  
>>>>>>>>>>> done by a
>>>>>>>>>>> more
>>>>>>>>>>> experienced user)
>>>>>>>>>>> - to set username+pw for a specific server.
>>>>>>>>>>> If they don't have to touch the file then leave it, 'cause  
>>>>>>>>>>> changes
>>>>>>>>>>> here
>>>>>>>>>>> might break maven.
>>>>>>>>>>> And a user-specific project-profile has to be located on a  
>>>>>>>>>>> very
>>>>>>>>>>> logic
>>>>>>>>>>>
>>>>>>>>>>> and
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> easy to access location, so the best option is next to the  
>>>>>>>>> pom I
>>>>>>>>>> guess.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -regards,
>>>>>>>>>>>
>>>>>>>>>>> Robert Scholte
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> BRIAN FOX-5 wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Why not just put those values into the settings.xml?
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte<
>>>>>>>>>>>>
>>>>>>>>>>>> rfscholte@codehaus.org>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> I heard some time ago that the profiles.xml were removed  
>>>>>>>>>>>>> in
>>>>>>>>>>>>> Maven3.
>>>>>>>>>>>>> Although I'm still using 2.1.0 I want to be prepared for  
>>>>>>>>>>>>> such
>>>>>>>>>>>>>
>>>>>>>>>>>>> changes.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> IMHO I think it's a bad choice to remove this option.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maven should provide some sort of way where developers can
>>>>>>>>>>>>> set/change
>>>>>>>>>>>>> project properties without having to change the pom.xml.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I believe the pom should not contain developer-specific
>>>>>>>>>>>>> properties
>>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> which can or will end up in any scm. Think of datasource- 
>>>>>>>>> properties.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are three degrees of properties:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - the global properties (combined with the
>>>>>>>>>>>>> activeByDefault-profile)
>>>>>>>>>>>>>
>>>>>>>>>>>>> - profile-properties (where profiles cover multiple  
>>>>>>>>>>>>> users. By OS,
>>>>>>>>>>>>> 'stage')
>>>>>>>>>>>>>
>>>>>>>>>>>>> - personal properties.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> These personal properties can only be used with a personal
>>>>>>>>>>>>> profile.
>>>>>>>>>>>>> A
>>>>>>>>>>>>> personal profile is the best example of data which doesn 
>>>>>>>>>>>>> ´t belong
>>>>>>>>>>>>> in
>>>>>>>>>>>>>
>>>>>>>>>>>>> a
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> pom but in a separate file (and probably not in scm).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Personal properties should be somewhere close to the  
>>>>>>>>>>>>> project,
>>>>>>>>>>>>> like
>>>>>>>>>>>>> in
>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> root of the project (yes, like the profiles.xml).
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The both settings.xml is too far from the project and  
>>>>>>>>>>>>> there's no
>>>>>>>>>>>>>
>>>>>>>>>>>>> option
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> in the (user's) settings.xml to set project-specific  
>>>>>>>>>>> properties.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think that if there was a vote concerning this issue  
>>>>>>>>>>>>> it might
>>>>>>>>>>>>>
>>>>>>>>>>>>> result
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> a long discussion. It's never too late for that, so let's  
>>>>>>>>>>> give it
>>>>>>>>>>> a
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> try.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _________________________________________________________________
>
>>>>>>>>>>>>> Express yourself instantly with MSN Messenger! Download  
>>>>>>>>>>>>> today
>>>>>>>>>>>>> it's
>>>>>>>>>>>>>
>>>>>>>>>>>>> FREE!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html
>>>>>>>>>
>>>>>>>>> Sent from the Maven Developers mailing list archive at Nabble.com 
>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24209431.html
>>>>>>>>> Sent from the Maven Developers mailing list archive at Nabble.com 
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>> ----------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>> ----------------------------------------------------------
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> -- 
>>> View this message in context: http://old.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p26545382.html
>>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> 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
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


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


Re: User's project-specific properties ability disabled after MNG-4060

Posted by Stephen Connolly <st...@gmail.com>.

Sent from my [rhymes with tryPod] ;-)

On 27 Nov 2009, at 21:03, Jason van Zyl <ja...@maven.org> wrote:

>
> On 2009-11-27, at 3:48 PM, Robert Scholte wrote:
>
>>
>> With the alpha releases of Maven 3 published we'll see how  
>> developers react
>> on this issue.
>> I've introduced Maven during several projects and my experience is  
>> that
>> newbies fear the settings.xml. They let a pro setup their  
>> settings.xml for
>> the repository and from that moment on it's an avoided territory.
>
> My experience does not match with yours. In most places I'm in the  
> developers are not afraid of the tools they use on a daily basis,  
> and the number of customizations that need to be made are relatively  
> few.
>
>> This means that the personal project-settings shall be resolved in  
>> the
>> pom.xml. One profile entry per developer if I'm pessimistic. Ok,  
>> maybe
>> combined with a filter-file it's somehow acceptable, but that  
>> requires
>> variables in your pom for everything a developer wants to modify  
>> personal.
>> From an architectural point of view I can imagine that the  
>> profiles.xml is
>> somehow a strange mechanism. But from a developers point of view  
>> (Jason, I
>> read your articles about Paving the desire lines) I believe it's a  
>> strong
>> concept. It just gives you the force on the right spot, personalize  
>> the
>> project/pom at your own risk.
>> Let's see some other responses and maybe we could reanimate the  
>> profiles.xml
>>
>
> Anyone can work with new model builder and add the support back in  
> if they like. My only requirements are the ITs passing and the  
> performance remains the same. Aside from that there's nothing  
> stopping anyone from putting the support back in.

I presume there is _some_ leeway with the performance... 5-10% or so  
and certainly no worse than 2.x

adding any logic is going to have at least 10ms of a performance  
hit... so I guessy question is where is the cut-off point at which you  
scream -1 on adding that implementation of that feature?

>
>> cheers,
>>
>> Robert
>>
>>
>> Bugzilla from mkleint@gmail.com wrote:
>>>
>>> On Fri, Nov 27, 2009 at 1:59 PM, Jason van Zyl <ja...@maven.org>  
>>> wrote:
>>>
>>>>
>>>> On 2009-11-27, at 7:45 AM, Milos Kleint wrote:
>>>>
>>>> On Fri, Nov 27, 2009 at 12:57 PM, Jason van Zyl <ja...@maven.org>  
>>>> wrote:
>>>>>
>>>>>
>>>>>> On 2009-11-27, at 5:55 AM, Milos Kleint wrote:
>>>>>>
>>>>>> I agree with Robert here.
>>>>>>
>>>>>>> removal of profiles.xml file leaves maven with no non-sharable,
>>>>>>> per-project
>>>>>>> configuration option. I"ve added my example to
>>>>>>> the issue http://jira.codehaus.org/browse/MNG-4060.
>>>>>>> It would be doable with settings.xml but it would be uber- 
>>>>>>> cumbersome
>>>>>>> to
>>>>>>> do
>>>>>>> so.
>>>>>>>
>>>>>>>
>>>>>> Why?
>>>>>>
>>>>>> I think an activator for a gav would work nicely.
>>>>>>
>>>>>
>>>>>
>>>>> if there is such a thing, yes, it would help. But then after each
>>>>> release,
>>>>> you have to tinker with the activators.
>>>>>
>>>>>
>>>> Then just G:A would do the trick.
>>>
>>>
>>> ...unless you decide to work on a code branch with different  
>>> settings
>>> then.
>>>
>>>
>>> Milos
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> It could partly work, but only when you work on one set of  
>>>>>> projects
>>>>>>
>>>>>>> only, or keep on  switching the settings file and have a  
>>>>>>> separate copy
>>>>>>> for
>>>>>>> each project (or set of projects).
>>>>>>>
>>>>>>>
>>>>>>> The profiles.xml made the internals extremely convoluted and  
>>>>>>> hard to
>>>>>> test.
>>>>>> Most of the use cases I've seen are resolved by settings.xml  
>>>>>> and that
>>>>>> can
>>>>>> be
>>>>>> made to be more intelligent to actually scope the profile in
>>>>>> settings.xml
>>>>>> to
>>>>>> a specific project would effectively be the same thing, or the  
>>>>>> project
>>>>>> needed to be decomposed into smaller projects.
>>>>>>
>>>>>> I'm fine with profiles.xml but you'll need to do the work to  
>>>>>> integrate
>>>>>> that
>>>>>> back into the project builder and build up the integration  
>>>>>> tests. I'm
>>>>>> not
>>>>>> interested in this work as I honestly don't think it's  
>>>>>> necessary. There
>>>>>> are
>>>>>> tests enough there to catch anything so you can do the work and  
>>>>>> know if
>>>>>> you've disturbed any other part of the system so you should be  
>>>>>> good to
>>>>>> go
>>>>>> if
>>>>>> you want to add this support back in.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Which just translates to "no". fair enough.
>>>>>
>>>>>
>>>> Not at all. It means I'm not interested in that feature. So yes  
>>>> that
>>>> might
>>>> translate into it's unlikely Benjamin, myself or Igor aren't  
>>>> going to
>>>> work
>>>> on it but there's nothing stopping you from adding the support.  
>>>> As long
>>>> as
>>>> all the ITs pass and the performance doesn't degrade have at it.
>>>>
>>>>
>>>> Milos
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Milos
>>>>>>>
>>>>>>> On Thu, Jun 25, 2009 at 8:14 PM, Robert Scholte
>>>>>>> <rfscholte@codehaus.org
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I didn't say it's not possible without profiles.xml, but  
>>>>>>> without it
>>>>>>> you
>>>>>>>> have
>>>>>>>> to make a choice between the best of the worst.
>>>>>>>> Let's stick to the passwords. You don't want to expose them  
>>>>>>>> in the
>>>>>>>> pom.xml,
>>>>>>>> right?
>>>>>>>> But what if project A en project B both have a ${password} in  
>>>>>>>> their
>>>>>>>> pom.xml,
>>>>>>>> from the settings.xml you can't figure out which password to  
>>>>>>>> use,
>>>>>>>> UNLESS
>>>>>>>> you
>>>>>>>> have to keep settings the specific profile per project. Not  
>>>>>>>> really
>>>>>>>> nice.
>>>>>>>> But let me reverse the question. Why was the profiles.xml  
>>>>>>>> introduced
>>>>>>>> and
>>>>>>>> what made it the team to say goodbye to this file?
>>>>>>>>
>>>>>>>> Robert
>>>>>>>>
>>>>>>>>
>>>>>>>> BRIAN FOX-5 wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Well, the mixin support should cover the profiles.xml and
>>>>>>>>> more....even
>>>>>>>>> better it should be possible to resolve the mixins from the
>>>>>>>>> repository
>>>>>>>>> which
>>>>>>>>> means they are versioned and deployed artifacts like  
>>>>>>>>> everything
>>>>>>>>> else.
>>>>>>>>>
>>>>>>>>> On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte
>>>>>>>>> <rf...@codehaus.org>wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In the settings.xml it's not possible to activate a profile by
>>>>>>>>>> project.
>>>>>>>>>> Then
>>>>>>>>>> again: I believe settings.xml are actually maven-settings  
>>>>>>>>>> and not
>>>>>>>>>> project-settings. For most users it's a big step to dive  
>>>>>>>>>> into the
>>>>>>>>>> settings.xml. For them there are only a few reasons to  
>>>>>>>>>> access the
>>>>>>>>>> settings
>>>>>>>>>> file:
>>>>>>>>>> - to setup a proxy repository like nexus (which is often  
>>>>>>>>>> done by a
>>>>>>>>>> more
>>>>>>>>>> experienced user)
>>>>>>>>>> - to set username+pw for a specific server.
>>>>>>>>>> If they don't have to touch the file then leave it, 'cause  
>>>>>>>>>> changes
>>>>>>>>>> here
>>>>>>>>>> might break maven.
>>>>>>>>>> And a user-specific project-profile has to be located on a  
>>>>>>>>>> very
>>>>>>>>>> logic
>>>>>>>>>>
>>>>>>>>>> and
>>>>>>>>>
>>>>>>>>
>>>>>>>> easy to access location, so the best option is next to the  
>>>>>>>> pom I
>>>>>>>>> guess.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -regards,
>>>>>>>>>>
>>>>>>>>>> Robert Scholte
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> BRIAN FOX-5 wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Why not just put those values into the settings.xml?
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte<
>>>>>>>>>>>
>>>>>>>>>>> rfscholte@codehaus.org>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I heard some time ago that the profiles.xml were removed in
>>>>>>>>>>>> Maven3.
>>>>>>>>>>>> Although I'm still using 2.1.0 I want to be prepared for  
>>>>>>>>>>>> such
>>>>>>>>>>>>
>>>>>>>>>>>> changes.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>> IMHO I think it's a bad choice to remove this option.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Maven should provide some sort of way where developers can
>>>>>>>>>>>> set/change
>>>>>>>>>>>> project properties without having to change the pom.xml.
>>>>>>>>>>>>
>>>>>>>>>>>> I believe the pom should not contain developer-specific
>>>>>>>>>>>> properties
>>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> which can or will end up in any scm. Think of datasource- 
>>>>>>>> properties.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> There are three degrees of properties:
>>>>>>>>>>>>
>>>>>>>>>>>> - the global properties (combined with the
>>>>>>>>>>>> activeByDefault-profile)
>>>>>>>>>>>>
>>>>>>>>>>>> - profile-properties (where profiles cover multiple  
>>>>>>>>>>>> users. By OS,
>>>>>>>>>>>> 'stage')
>>>>>>>>>>>>
>>>>>>>>>>>> - personal properties.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> These personal properties can only be used with a personal
>>>>>>>>>>>> profile.
>>>>>>>>>>>> A
>>>>>>>>>>>> personal profile is the best example of data w 
>>>>>>>>>>>> hich doesn´t belong
>>>>>>>>>>>> in
>>>>>>>>>>>>
>>>>>>>>>>>> a
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> pom but in a separate file (and probably not in scm).
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Personal properties should be somewhere close to the  
>>>>>>>>>>>> project,
>>>>>>>>>>>> like
>>>>>>>>>>>> in
>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> root of the project (yes, like the profiles.xml).
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The both settings.xml is too far from the project and  
>>>>>>>>>>>> there's no
>>>>>>>>>>>>
>>>>>>>>>>>> option
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> in the (user's) settings.xml to set project-specific  
>>>>>>>>>> properties.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think that if there was a vote concerning this issue it  
>>>>>>>>>>>> might
>>>>>>>>>>>>
>>>>>>>>>>>> result
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> in
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> a long discussion. It's never too late for that, so let's  
>>>>>>>>>> give it
>>>>>>>>>> a
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> try.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _________________________________________________________________
 

>>>>>>>>>>>> Express yourself instantly with MSN Messenger! Download  
>>>>>>>>>>>> today
>>>>>>>>>>>> it's
>>>>>>>>>>>>
>>>>>>>>>>>> FREE!
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --- 
>>>>>>>>>>> --- 
>>>>>>>>>>> --- 
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>> View this message in context:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html
>>>>>>>>
>>>>>>>> Sent from the Maven Developers mailing list archive at Nabble.com 
>>>>>>>> .
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --- 
>>>>>>>>>> --- 
>>>>>>>>>> --- 
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24209431.html
>>>>>>>> Sent from the Maven Developers mailing list archive at Nabble.com 
>>>>>>>> .
>>>>>>>>
>>>>>>>>
>>>>>>>> --- 
>>>>>>>> --- 
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> 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
>>>>>> ----------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- 
>>>>>> --- 
>>>>>> ---------------------------------------------------------------
>>>>>> 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
>>>> ----------------------------------------------------------
>>>>
>>>>
>>>> --- 
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>
>> -- 
>> View this message in context: http://old.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p26545382.html
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> 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: User's project-specific properties ability disabled after MNG-4060

Posted by Jason van Zyl <ja...@maven.org>.
On 2009-11-27, at 3:48 PM, Robert Scholte wrote:

>
> With the alpha releases of Maven 3 published we'll see how  
> developers react
> on this issue.
> I've introduced Maven during several projects and my experience is  
> that
> newbies fear the settings.xml. They let a pro setup their  
> settings.xml for
> the repository and from that moment on it's an avoided territory.

My experience does not match with yours. In most places I'm in the  
developers are not afraid of the tools they use on a daily basis, and  
the number of customizations that need to be made are relatively few.

> This means that the personal project-settings shall be resolved in the
> pom.xml. One profile entry per developer if I'm pessimistic. Ok, maybe
> combined with a filter-file it's somehow acceptable, but that requires
> variables in your pom for everything a developer wants to modify  
> personal.
> From an architectural point of view I can imagine that the  
> profiles.xml is
> somehow a strange mechanism. But from a developers point of view  
> (Jason, I
> read your articles about Paving the desire lines) I believe it's a  
> strong
> concept. It just gives you the force on the right spot, personalize  
> the
> project/pom at your own risk.
> Let's see some other responses and maybe we could reanimate the  
> profiles.xml
>

Anyone can work with new model builder and add the support back in if  
they like. My only requirements are the ITs passing and the  
performance remains the same. Aside from that there's nothing stopping  
anyone from putting the support back in.

> cheers,
>
> Robert
>
>
> Bugzilla from mkleint@gmail.com wrote:
>>
>> On Fri, Nov 27, 2009 at 1:59 PM, Jason van Zyl <ja...@maven.org>  
>> wrote:
>>
>>>
>>> On 2009-11-27, at 7:45 AM, Milos Kleint wrote:
>>>
>>> On Fri, Nov 27, 2009 at 12:57 PM, Jason van Zyl <ja...@maven.org>  
>>> wrote:
>>>>
>>>>
>>>>> On 2009-11-27, at 5:55 AM, Milos Kleint wrote:
>>>>>
>>>>> I agree with Robert here.
>>>>>
>>>>>> removal of profiles.xml file leaves maven with no non-sharable,
>>>>>> per-project
>>>>>> configuration option. I"ve added my example to
>>>>>> the issue http://jira.codehaus.org/browse/MNG-4060.
>>>>>> It would be doable with settings.xml but it would be uber- 
>>>>>> cumbersome
>>>>>> to
>>>>>> do
>>>>>> so.
>>>>>>
>>>>>>
>>>>> Why?
>>>>>
>>>>> I think an activator for a gav would work nicely.
>>>>>
>>>>
>>>>
>>>> if there is such a thing, yes, it would help. But then after each
>>>> release,
>>>> you have to tinker with the activators.
>>>>
>>>>
>>> Then just G:A would do the trick.
>>
>>
>> ...unless you decide to work on a code branch with different settings
>> then.
>>
>>
>> Milos
>>
>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>> It could partly work, but only when you work on one set of  
>>>>> projects
>>>>>
>>>>>> only, or keep on  switching the settings file and have a  
>>>>>> separate copy
>>>>>> for
>>>>>> each project (or set of projects).
>>>>>>
>>>>>>
>>>>>> The profiles.xml made the internals extremely convoluted and  
>>>>>> hard to
>>>>> test.
>>>>> Most of the use cases I've seen are resolved by settings.xml and  
>>>>> that
>>>>> can
>>>>> be
>>>>> made to be more intelligent to actually scope the profile in
>>>>> settings.xml
>>>>> to
>>>>> a specific project would effectively be the same thing, or the  
>>>>> project
>>>>> needed to be decomposed into smaller projects.
>>>>>
>>>>> I'm fine with profiles.xml but you'll need to do the work to  
>>>>> integrate
>>>>> that
>>>>> back into the project builder and build up the integration  
>>>>> tests. I'm
>>>>> not
>>>>> interested in this work as I honestly don't think it's  
>>>>> necessary. There
>>>>> are
>>>>> tests enough there to catch anything so you can do the work and  
>>>>> know if
>>>>> you've disturbed any other part of the system so you should be  
>>>>> good to
>>>>> go
>>>>> if
>>>>> you want to add this support back in.
>>>>>
>>>>
>>>>
>>>>
>>>> Which just translates to "no". fair enough.
>>>>
>>>>
>>> Not at all. It means I'm not interested in that feature. So yes that
>>> might
>>> translate into it's unlikely Benjamin, myself or Igor aren't going  
>>> to
>>> work
>>> on it but there's nothing stopping you from adding the support. As  
>>> long
>>> as
>>> all the ITs pass and the performance doesn't degrade have at it.
>>>
>>>
>>> Milos
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> Milos
>>>>>>
>>>>>> On Thu, Jun 25, 2009 at 8:14 PM, Robert Scholte
>>>>>> <rfscholte@codehaus.org
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>>
>>>>>> I didn't say it's not possible without profiles.xml, but  
>>>>>> without it
>>>>>> you
>>>>>>> have
>>>>>>> to make a choice between the best of the worst.
>>>>>>> Let's stick to the passwords. You don't want to expose them in  
>>>>>>> the
>>>>>>> pom.xml,
>>>>>>> right?
>>>>>>> But what if project A en project B both have a ${password} in  
>>>>>>> their
>>>>>>> pom.xml,
>>>>>>> from the settings.xml you can't figure out which password to  
>>>>>>> use,
>>>>>>> UNLESS
>>>>>>> you
>>>>>>> have to keep settings the specific profile per project. Not  
>>>>>>> really
>>>>>>> nice.
>>>>>>> But let me reverse the question. Why was the profiles.xml  
>>>>>>> introduced
>>>>>>> and
>>>>>>> what made it the team to say goodbye to this file?
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> BRIAN FOX-5 wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Well, the mixin support should cover the profiles.xml and
>>>>>>>> more....even
>>>>>>>> better it should be possible to resolve the mixins from the
>>>>>>>> repository
>>>>>>>> which
>>>>>>>> means they are versioned and deployed artifacts like everything
>>>>>>>> else.
>>>>>>>>
>>>>>>>> On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte
>>>>>>>> <rf...@codehaus.org>wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> In the settings.xml it's not possible to activate a profile by
>>>>>>>>> project.
>>>>>>>>> Then
>>>>>>>>> again: I believe settings.xml are actually maven-settings  
>>>>>>>>> and not
>>>>>>>>> project-settings. For most users it's a big step to dive  
>>>>>>>>> into the
>>>>>>>>> settings.xml. For them there are only a few reasons to  
>>>>>>>>> access the
>>>>>>>>> settings
>>>>>>>>> file:
>>>>>>>>> - to setup a proxy repository like nexus (which is often  
>>>>>>>>> done by a
>>>>>>>>> more
>>>>>>>>> experienced user)
>>>>>>>>> - to set username+pw for a specific server.
>>>>>>>>> If they don't have to touch the file then leave it, 'cause  
>>>>>>>>> changes
>>>>>>>>> here
>>>>>>>>> might break maven.
>>>>>>>>> And a user-specific project-profile has to be located on a  
>>>>>>>>> very
>>>>>>>>> logic
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>
>>>>>>>
>>>>>>> easy to access location, so the best option is next to the pom I
>>>>>>>> guess.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -regards,
>>>>>>>>>
>>>>>>>>> Robert Scholte
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> BRIAN FOX-5 wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Why not just put those values into the settings.xml?
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte<
>>>>>>>>>>
>>>>>>>>>> rfscholte@codehaus.org>
>>>>>>>>>
>>>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I heard some time ago that the profiles.xml were removed in
>>>>>>>>>>> Maven3.
>>>>>>>>>>> Although I'm still using 2.1.0 I want to be prepared for  
>>>>>>>>>>> such
>>>>>>>>>>>
>>>>>>>>>>> changes.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>> IMHO I think it's a bad choice to remove this option.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Maven should provide some sort of way where developers can
>>>>>>>>>>> set/change
>>>>>>>>>>> project properties without having to change the pom.xml.
>>>>>>>>>>>
>>>>>>>>>>> I believe the pom should not contain developer-specific
>>>>>>>>>>> properties
>>>>>>>>>>>
>>>>>>>>>>> and
>>>>>>>>>>
>>>>>>>>>
>>>>>>> which can or will end up in any scm. Think of datasource- 
>>>>>>> properties.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> There are three degrees of properties:
>>>>>>>>>>>
>>>>>>>>>>> - the global properties (combined with the
>>>>>>>>>>> activeByDefault-profile)
>>>>>>>>>>>
>>>>>>>>>>> - profile-properties (where profiles cover multiple users.  
>>>>>>>>>>> By OS,
>>>>>>>>>>> 'stage')
>>>>>>>>>>>
>>>>>>>>>>> - personal properties.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> These personal properties can only be used with a personal
>>>>>>>>>>> profile.
>>>>>>>>>>> A
>>>>>>>>>>> personal profile is the best example of data which doesn´t  
>>>>>>>>>>> belong
>>>>>>>>>>> in
>>>>>>>>>>>
>>>>>>>>>>> a
>>>>>>>>>>
>>>>>>>>>
>>>>>>> pom but in a separate file (and probably not in scm).
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Personal properties should be somewhere close to the  
>>>>>>>>>>> project,
>>>>>>>>>>> like
>>>>>>>>>>> in
>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> root of the project (yes, like the profiles.xml).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The both settings.xml is too far from the project and  
>>>>>>>>>>> there's no
>>>>>>>>>>>
>>>>>>>>>>> option
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> in the (user's) settings.xml to set project-specific  
>>>>>>>>> properties.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think that if there was a vote concerning this issue it  
>>>>>>>>>>> might
>>>>>>>>>>>
>>>>>>>>>>> result
>>>>>>>>>>
>>>>>>>>>
>>>>>>> in
>>>>>>>>
>>>>>>>>>
>>>>>>>>> a long discussion. It's never too late for that, so let's  
>>>>>>>>> give it
>>>>>>>>> a
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> try.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _________________________________________________________________
>>>>>>>>>>> Express yourself instantly with MSN Messenger! Download  
>>>>>>>>>>> today
>>>>>>>>>>> it's
>>>>>>>>>>>
>>>>>>>>>>> FREE!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/ 
>>>>>>>>> 01/
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html
>>>>>>>
>>>>>>> Sent from the Maven Developers mailing list archive at Nabble.com 
>>>>>>> .
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>>>>>
>>>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24209431.html
>>>>>>> Sent from the Maven Developers mailing list archive at Nabble.com 
>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>> ----------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>> ----------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>
> -- 
> View this message in context: http://old.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p26545382.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------


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


Re: User's project-specific properties ability disabled after MNG-4060

Posted by Robert Scholte <rf...@codehaus.org>.
With the alpha releases of Maven 3 published we'll see how developers react
on this issue.
I've introduced Maven during several projects and my experience is that
newbies fear the settings.xml. They let a pro setup their settings.xml for
the repository and from that moment on it's an avoided territory. 
This means that the personal project-settings shall be resolved in the
pom.xml. One profile entry per developer if I'm pessimistic. Ok, maybe
combined with a filter-file it's somehow acceptable, but that requires
variables in your pom for everything a developer wants to modify personal.
>From an architectural point of view I can imagine that the profiles.xml is
somehow a strange mechanism. But from a developers point of view (Jason, I
read your articles about Paving the desire lines) I believe it's a strong
concept. It just gives you the force on the right spot, personalize the
project/pom at your own risk.
Let's see some other responses and maybe we could reanimate the profiles.xml

cheers,

Robert


Bugzilla from mkleint@gmail.com wrote:
> 
> On Fri, Nov 27, 2009 at 1:59 PM, Jason van Zyl <ja...@maven.org> wrote:
> 
>>
>> On 2009-11-27, at 7:45 AM, Milos Kleint wrote:
>>
>>  On Fri, Nov 27, 2009 at 12:57 PM, Jason van Zyl <ja...@maven.org> wrote:
>>>
>>>
>>>> On 2009-11-27, at 5:55 AM, Milos Kleint wrote:
>>>>
>>>> I agree with Robert here.
>>>>
>>>>> removal of profiles.xml file leaves maven with no non-sharable,
>>>>> per-project
>>>>> configuration option. I"ve added my example to
>>>>> the issue http://jira.codehaus.org/browse/MNG-4060.
>>>>> It would be doable with settings.xml but it would be uber-cumbersome
>>>>> to
>>>>> do
>>>>> so.
>>>>>
>>>>>
>>>> Why?
>>>>
>>>> I think an activator for a gav would work nicely.
>>>>
>>>
>>>
>>> if there is such a thing, yes, it would help. But then after each
>>> release,
>>> you have to tinker with the activators.
>>>
>>>
>> Then just G:A would do the trick.
> 
> 
> ...unless you decide to work on a code branch with different settings
> then.
> 
> 
> Milos
> 
> 
>>
>>
>>
>>>
>>>>
>>>> It could partly work, but only when you work on one set of projects
>>>>
>>>>> only, or keep on  switching the settings file and have a separate copy
>>>>> for
>>>>> each project (or set of projects).
>>>>>
>>>>>
>>>>>  The profiles.xml made the internals extremely convoluted and hard to
>>>> test.
>>>> Most of the use cases I've seen are resolved by settings.xml and that
>>>> can
>>>> be
>>>> made to be more intelligent to actually scope the profile in
>>>> settings.xml
>>>> to
>>>> a specific project would effectively be the same thing, or the project
>>>> needed to be decomposed into smaller projects.
>>>>
>>>> I'm fine with profiles.xml but you'll need to do the work to integrate
>>>> that
>>>> back into the project builder and build up the integration tests. I'm
>>>> not
>>>> interested in this work as I honestly don't think it's necessary. There
>>>> are
>>>> tests enough there to catch anything so you can do the work and know if
>>>> you've disturbed any other part of the system so you should be good to
>>>> go
>>>> if
>>>> you want to add this support back in.
>>>>
>>>
>>>
>>>
>>> Which just translates to "no". fair enough.
>>>
>>>
>> Not at all. It means I'm not interested in that feature. So yes that
>> might
>> translate into it's unlikely Benjamin, myself or Igor aren't going to
>> work
>> on it but there's nothing stopping you from adding the support. As long
>> as
>> all the ITs pass and the performance doesn't degrade have at it.
>>
>>
>>  Milos
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>  Milos
>>>>>
>>>>> On Thu, Jun 25, 2009 at 8:14 PM, Robert Scholte
>>>>> <rfscholte@codehaus.org
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>
>>>>>
>>>>>  I didn't say it's not possible without profiles.xml, but without it
>>>>> you
>>>>>> have
>>>>>> to make a choice between the best of the worst.
>>>>>> Let's stick to the passwords. You don't want to expose them in the
>>>>>> pom.xml,
>>>>>> right?
>>>>>> But what if project A en project B both have a ${password} in their
>>>>>> pom.xml,
>>>>>> from the settings.xml you can't figure out which password to use,
>>>>>> UNLESS
>>>>>> you
>>>>>> have to keep settings the specific profile per project. Not really
>>>>>> nice.
>>>>>> But let me reverse the question. Why was the profiles.xml introduced
>>>>>> and
>>>>>> what made it the team to say goodbye to this file?
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> BRIAN FOX-5 wrote:
>>>>>>
>>>>>>
>>>>>>> Well, the mixin support should cover the profiles.xml and
>>>>>>> more....even
>>>>>>> better it should be possible to resolve the mixins from the
>>>>>>> repository
>>>>>>> which
>>>>>>> means they are versioned and deployed artifacts like everything
>>>>>>> else.
>>>>>>>
>>>>>>> On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte
>>>>>>> <rf...@codehaus.org>wrote:
>>>>>>>
>>>>>>>
>>>>>>>  In the settings.xml it's not possible to activate a profile by
>>>>>>>> project.
>>>>>>>> Then
>>>>>>>> again: I believe settings.xml are actually maven-settings and not
>>>>>>>> project-settings. For most users it's a big step to dive into the
>>>>>>>> settings.xml. For them there are only a few reasons to access the
>>>>>>>> settings
>>>>>>>> file:
>>>>>>>> - to setup a proxy repository like nexus (which is often done by a
>>>>>>>> more
>>>>>>>> experienced user)
>>>>>>>> - to set username+pw for a specific server.
>>>>>>>> If they don't have to touch the file then leave it, 'cause changes
>>>>>>>> here
>>>>>>>> might break maven.
>>>>>>>> And a user-specific project-profile has to be located on a very
>>>>>>>> logic
>>>>>>>>
>>>>>>>>  and
>>>>>>>
>>>>>>
>>>>>>  easy to access location, so the best option is next to the pom I
>>>>>>> guess.
>>>>>>>
>>>>>>>>
>>>>>>>> -regards,
>>>>>>>>
>>>>>>>> Robert Scholte
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> BRIAN FOX-5 wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Why not just put those values into the settings.xml?
>>>>>>>>>
>>>>>>>>> On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte<
>>>>>>>>>
>>>>>>>>>  rfscholte@codehaus.org>
>>>>>>>>
>>>>>>>
>>>>>>  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I heard some time ago that the profiles.xml were removed in
>>>>>>>>>> Maven3.
>>>>>>>>>> Although I'm still using 2.1.0 I want to be prepared for such
>>>>>>>>>>
>>>>>>>>>>  changes.
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>  IMHO I think it's a bad choice to remove this option.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Maven should provide some sort of way where developers can
>>>>>>>>>> set/change
>>>>>>>>>> project properties without having to change the pom.xml.
>>>>>>>>>>
>>>>>>>>>> I believe the pom should not contain developer-specific
>>>>>>>>>> properties
>>>>>>>>>>
>>>>>>>>>>  and
>>>>>>>>>
>>>>>>>>
>>>>>>  which can or will end up in any scm. Think of datasource-properties.
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There are three degrees of properties:
>>>>>>>>>>
>>>>>>>>>> - the global properties (combined with the
>>>>>>>>>> activeByDefault-profile)
>>>>>>>>>>
>>>>>>>>>> - profile-properties (where profiles cover multiple users. By OS,
>>>>>>>>>> 'stage')
>>>>>>>>>>
>>>>>>>>>> - personal properties.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> These personal properties can only be used with a personal
>>>>>>>>>> profile.
>>>>>>>>>> A
>>>>>>>>>> personal profile is the best example of data which doesn´t belong
>>>>>>>>>> in
>>>>>>>>>>
>>>>>>>>>>  a
>>>>>>>>>
>>>>>>>>
>>>>>>  pom but in a separate file (and probably not in scm).
>>>>>>>
>>>>>>>>
>>>>>>>>>> Personal properties should be somewhere close to the project,
>>>>>>>>>> like
>>>>>>>>>> in
>>>>>>>>>>
>>>>>>>>>>  the
>>>>>>>>>
>>>>>>>>
>>>>>>>>  root of the project (yes, like the profiles.xml).
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The both settings.xml is too far from the project and there's no
>>>>>>>>>>
>>>>>>>>>>  option
>>>>>>>>>
>>>>>>>>
>>>>>>>>  in the (user's) settings.xml to set project-specific properties.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think that if there was a vote concerning this issue it might
>>>>>>>>>>
>>>>>>>>>>  result
>>>>>>>>>
>>>>>>>>
>>>>>>  in
>>>>>>>
>>>>>>>>
>>>>>>>>  a long discussion. It's never too late for that, so let's give it
>>>>>>>> a
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  try.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _________________________________________________________________
>>>>>>>>>> Express yourself instantly with MSN Messenger! Download today
>>>>>>>>>> it's
>>>>>>>>>>
>>>>>>>>>>  FREE!
>>>>>>>>>
>>>>>>>>
>>>>>>>>  http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  --
>>>>>>>> View this message in context:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html
>>>>>>
>>>>>>  Sent from the Maven Developers mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24209431.html
>>>>>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>> ----------------------------------------------------------
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 

-- 
View this message in context: http://old.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p26545382.html
Sent from the Maven Developers mailing list archive at Nabble.com.


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


Re: User's project-specific properties ability disabled after MNG-4060

Posted by Milos Kleint <mk...@gmail.com>.
On Fri, Nov 27, 2009 at 1:59 PM, Jason van Zyl <ja...@maven.org> wrote:

>
> On 2009-11-27, at 7:45 AM, Milos Kleint wrote:
>
>  On Fri, Nov 27, 2009 at 12:57 PM, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>>> On 2009-11-27, at 5:55 AM, Milos Kleint wrote:
>>>
>>> I agree with Robert here.
>>>
>>>> removal of profiles.xml file leaves maven with no non-sharable,
>>>> per-project
>>>> configuration option. I"ve added my example to
>>>> the issue http://jira.codehaus.org/browse/MNG-4060.
>>>> It would be doable with settings.xml but it would be uber-cumbersome to
>>>> do
>>>> so.
>>>>
>>>>
>>> Why?
>>>
>>> I think an activator for a gav would work nicely.
>>>
>>
>>
>> if there is such a thing, yes, it would help. But then after each release,
>> you have to tinker with the activators.
>>
>>
> Then just G:A would do the trick.


...unless you decide to work on a code branch with different settings then.


Milos


>
>
>
>>
>>>
>>> It could partly work, but only when you work on one set of projects
>>>
>>>> only, or keep on  switching the settings file and have a separate copy
>>>> for
>>>> each project (or set of projects).
>>>>
>>>>
>>>>  The profiles.xml made the internals extremely convoluted and hard to
>>> test.
>>> Most of the use cases I've seen are resolved by settings.xml and that can
>>> be
>>> made to be more intelligent to actually scope the profile in settings.xml
>>> to
>>> a specific project would effectively be the same thing, or the project
>>> needed to be decomposed into smaller projects.
>>>
>>> I'm fine with profiles.xml but you'll need to do the work to integrate
>>> that
>>> back into the project builder and build up the integration tests. I'm not
>>> interested in this work as I honestly don't think it's necessary. There
>>> are
>>> tests enough there to catch anything so you can do the work and know if
>>> you've disturbed any other part of the system so you should be good to go
>>> if
>>> you want to add this support back in.
>>>
>>
>>
>>
>> Which just translates to "no". fair enough.
>>
>>
> Not at all. It means I'm not interested in that feature. So yes that might
> translate into it's unlikely Benjamin, myself or Igor aren't going to work
> on it but there's nothing stopping you from adding the support. As long as
> all the ITs pass and the performance doesn't degrade have at it.
>
>
>  Milos
>>
>>
>>
>>
>>>
>>>
>>>  Milos
>>>>
>>>> On Thu, Jun 25, 2009 at 8:14 PM, Robert Scholte <rfscholte@codehaus.org
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>>
>>>>  I didn't say it's not possible without profiles.xml, but without it you
>>>>> have
>>>>> to make a choice between the best of the worst.
>>>>> Let's stick to the passwords. You don't want to expose them in the
>>>>> pom.xml,
>>>>> right?
>>>>> But what if project A en project B both have a ${password} in their
>>>>> pom.xml,
>>>>> from the settings.xml you can't figure out which password to use,
>>>>> UNLESS
>>>>> you
>>>>> have to keep settings the specific profile per project. Not really
>>>>> nice.
>>>>> But let me reverse the question. Why was the profiles.xml introduced
>>>>> and
>>>>> what made it the team to say goodbye to this file?
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> BRIAN FOX-5 wrote:
>>>>>
>>>>>
>>>>>> Well, the mixin support should cover the profiles.xml and more....even
>>>>>> better it should be possible to resolve the mixins from the repository
>>>>>> which
>>>>>> means they are versioned and deployed artifacts like everything else.
>>>>>>
>>>>>> On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte
>>>>>> <rf...@codehaus.org>wrote:
>>>>>>
>>>>>>
>>>>>>  In the settings.xml it's not possible to activate a profile by
>>>>>>> project.
>>>>>>> Then
>>>>>>> again: I believe settings.xml are actually maven-settings and not
>>>>>>> project-settings. For most users it's a big step to dive into the
>>>>>>> settings.xml. For them there are only a few reasons to access the
>>>>>>> settings
>>>>>>> file:
>>>>>>> - to setup a proxy repository like nexus (which is often done by a
>>>>>>> more
>>>>>>> experienced user)
>>>>>>> - to set username+pw for a specific server.
>>>>>>> If they don't have to touch the file then leave it, 'cause changes
>>>>>>> here
>>>>>>> might break maven.
>>>>>>> And a user-specific project-profile has to be located on a very logic
>>>>>>>
>>>>>>>  and
>>>>>>
>>>>>
>>>>>  easy to access location, so the best option is next to the pom I
>>>>>> guess.
>>>>>>
>>>>>>>
>>>>>>> -regards,
>>>>>>>
>>>>>>> Robert Scholte
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> BRIAN FOX-5 wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Why not just put those values into the settings.xml?
>>>>>>>>
>>>>>>>> On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte<
>>>>>>>>
>>>>>>>>  rfscholte@codehaus.org>
>>>>>>>
>>>>>>
>>>>>  wrote:
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> I heard some time ago that the profiles.xml were removed in Maven3.
>>>>>>>>> Although I'm still using 2.1.0 I want to be prepared for such
>>>>>>>>>
>>>>>>>>>  changes.
>>>>>>>>
>>>>>>>
>>>>>
>>>>>>  IMHO I think it's a bad choice to remove this option.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Maven should provide some sort of way where developers can
>>>>>>>>> set/change
>>>>>>>>> project properties without having to change the pom.xml.
>>>>>>>>>
>>>>>>>>> I believe the pom should not contain developer-specific properties
>>>>>>>>>
>>>>>>>>>  and
>>>>>>>>
>>>>>>>
>>>>>  which can or will end up in any scm. Think of datasource-properties.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There are three degrees of properties:
>>>>>>>>>
>>>>>>>>> - the global properties (combined with the activeByDefault-profile)
>>>>>>>>>
>>>>>>>>> - profile-properties (where profiles cover multiple users. By OS,
>>>>>>>>> 'stage')
>>>>>>>>>
>>>>>>>>> - personal properties.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> These personal properties can only be used with a personal profile.
>>>>>>>>> A
>>>>>>>>> personal profile is the best example of data which doesn´t belong
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>>  a
>>>>>>>>
>>>>>>>
>>>>>  pom but in a separate file (and probably not in scm).
>>>>>>
>>>>>>>
>>>>>>>>> Personal properties should be somewhere close to the project, like
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>>  the
>>>>>>>>
>>>>>>>
>>>>>>>  root of the project (yes, like the profiles.xml).
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The both settings.xml is too far from the project and there's no
>>>>>>>>>
>>>>>>>>>  option
>>>>>>>>
>>>>>>>
>>>>>>>  in the (user's) settings.xml to set project-specific properties.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think that if there was a vote concerning this issue it might
>>>>>>>>>
>>>>>>>>>  result
>>>>>>>>
>>>>>>>
>>>>>  in
>>>>>>
>>>>>>>
>>>>>>>  a long discussion. It's never too late for that, so let's give it a
>>>>>>>>
>>>>>>>>>
>>>>>>>>>  try.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> _________________________________________________________________
>>>>>>>>> Express yourself instantly with MSN Messenger! Download today it's
>>>>>>>>>
>>>>>>>>>  FREE!
>>>>>>>>
>>>>>>>
>>>>>>>  http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  --
>>>>>>> View this message in context:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html
>>>>>
>>>>>  Sent from the Maven Developers mailing list archive at Nabble.com.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>  --
>>>>> View this message in context:
>>>>>
>>>>>
>>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24209431.html
>>>>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>> ----------------------------------------------------------
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: User's project-specific properties ability disabled after MNG-4060

Posted by Jason van Zyl <ja...@maven.org>.
On 2009-11-27, at 7:45 AM, Milos Kleint wrote:

> On Fri, Nov 27, 2009 at 12:57 PM, Jason van Zyl <ja...@maven.org>  
> wrote:
>
>>
>> On 2009-11-27, at 5:55 AM, Milos Kleint wrote:
>>
>> I agree with Robert here.
>>> removal of profiles.xml file leaves maven with no non-sharable,
>>> per-project
>>> configuration option. I"ve added my example to
>>> the issue http://jira.codehaus.org/browse/MNG-4060.
>>> It would be doable with settings.xml but it would be uber- 
>>> cumbersome to do
>>> so.
>>>
>>
>> Why?
>>
>> I think an activator for a gav would work nicely.
>
>
> if there is such a thing, yes, it would help. But then after each  
> release,
> you have to tinker with the activators.
>

Then just G:A would do the trick.

>
>>
>>
>> It could partly work, but only when you work on one set of projects
>>> only, or keep on  switching the settings file and have a separate  
>>> copy for
>>> each project (or set of projects).
>>>
>>>
>> The profiles.xml made the internals extremely convoluted and hard  
>> to test.
>> Most of the use cases I've seen are resolved by settings.xml and  
>> that can be
>> made to be more intelligent to actually scope the profile in  
>> settings.xml to
>> a specific project would effectively be the same thing, or the  
>> project
>> needed to be decomposed into smaller projects.
>>
>> I'm fine with profiles.xml but you'll need to do the work to  
>> integrate that
>> back into the project builder and build up the integration tests.  
>> I'm not
>> interested in this work as I honestly don't think it's necessary.  
>> There are
>> tests enough there to catch anything so you can do the work and  
>> know if
>> you've disturbed any other part of the system so you should be good  
>> to go if
>> you want to add this support back in.
>
>
>
> Which just translates to "no". fair enough.
>

Not at all. It means I'm not interested in that feature. So yes that  
might translate into it's unlikely Benjamin, myself or Igor aren't  
going to work on it but there's nothing stopping you from adding the  
support. As long as all the ITs pass and the performance doesn't  
degrade have at it.

> Milos
>
>
>
>>
>>
>>
>>> Milos
>>>
>>> On Thu, Jun 25, 2009 at 8:14 PM, Robert Scholte <rfscholte@codehaus.org
>>>> wrote:
>>>
>>>
>>>> I didn't say it's not possible without profiles.xml, but without  
>>>> it you
>>>> have
>>>> to make a choice between the best of the worst.
>>>> Let's stick to the passwords. You don't want to expose them in the
>>>> pom.xml,
>>>> right?
>>>> But what if project A en project B both have a ${password} in their
>>>> pom.xml,
>>>> from the settings.xml you can't figure out which password to use,  
>>>> UNLESS
>>>> you
>>>> have to keep settings the specific profile per project. Not  
>>>> really nice.
>>>> But let me reverse the question. Why was the profiles.xml  
>>>> introduced and
>>>> what made it the team to say goodbye to this file?
>>>>
>>>> Robert
>>>>
>>>>
>>>> BRIAN FOX-5 wrote:
>>>>
>>>>>
>>>>> Well, the mixin support should cover the profiles.xml and  
>>>>> more....even
>>>>> better it should be possible to resolve the mixins from the  
>>>>> repository
>>>>> which
>>>>> means they are versioned and deployed artifacts like everything  
>>>>> else.
>>>>>
>>>>> On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte
>>>>> <rf...@codehaus.org>wrote:
>>>>>
>>>>>
>>>>>> In the settings.xml it's not possible to activate a profile by  
>>>>>> project.
>>>>>> Then
>>>>>> again: I believe settings.xml are actually maven-settings and not
>>>>>> project-settings. For most users it's a big step to dive into the
>>>>>> settings.xml. For them there are only a few reasons to access the
>>>>>> settings
>>>>>> file:
>>>>>> - to setup a proxy repository like nexus (which is often done  
>>>>>> by a more
>>>>>> experienced user)
>>>>>> - to set username+pw for a specific server.
>>>>>> If they don't have to touch the file then leave it, 'cause  
>>>>>> changes here
>>>>>> might break maven.
>>>>>> And a user-specific project-profile has to be located on a very  
>>>>>> logic
>>>>>>
>>>>> and
>>>>
>>>>> easy to access location, so the best option is next to the pom I  
>>>>> guess.
>>>>>>
>>>>>> -regards,
>>>>>>
>>>>>> Robert Scholte
>>>>>>
>>>>>>
>>>>>>
>>>>>> BRIAN FOX-5 wrote:
>>>>>>
>>>>>>>
>>>>>>> Why not just put those values into the settings.xml?
>>>>>>>
>>>>>>> On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte<
>>>>>>>
>>>>>> rfscholte@codehaus.org>
>>>>
>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I heard some time ago that the profiles.xml were removed in  
>>>>>>>> Maven3.
>>>>>>>> Although I'm still using 2.1.0 I want to be prepared for such
>>>>>>>>
>>>>>>> changes.
>>>>
>>>>>
>>>>>>>> IMHO I think it's a bad choice to remove this option.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Maven should provide some sort of way where developers can  
>>>>>>>> set/change
>>>>>>>> project properties without having to change the pom.xml.
>>>>>>>>
>>>>>>>> I believe the pom should not contain developer-specific  
>>>>>>>> properties
>>>>>>>>
>>>>>>> and
>>>>
>>>>> which can or will end up in any scm. Think of datasource- 
>>>>> properties.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> There are three degrees of properties:
>>>>>>>>
>>>>>>>> - the global properties (combined with the activeByDefault- 
>>>>>>>> profile)
>>>>>>>>
>>>>>>>> - profile-properties (where profiles cover multiple users. By  
>>>>>>>> OS,
>>>>>>>> 'stage')
>>>>>>>>
>>>>>>>> - personal properties.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> These personal properties can only be used with a personal  
>>>>>>>> profile. A
>>>>>>>> personal profile is the best example of data which doesn´t  
>>>>>>>> belong in
>>>>>>>>
>>>>>>> a
>>>>
>>>>> pom but in a separate file (and probably not in scm).
>>>>>>>>
>>>>>>>> Personal properties should be somewhere close to the project,  
>>>>>>>> like in
>>>>>>>>
>>>>>>> the
>>>>>>
>>>>>>> root of the project (yes, like the profiles.xml).
>>>>>>>>
>>>>>>>> The both settings.xml is too far from the project and there's  
>>>>>>>> no
>>>>>>>>
>>>>>>> option
>>>>>>
>>>>>>> in the (user's) settings.xml to set project-specific properties.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I think that if there was a vote concerning this issue it might
>>>>>>>>
>>>>>>> result
>>>>
>>>>> in
>>>>>>
>>>>>>> a long discussion. It's never too late for that, so let's give  
>>>>>>> it a
>>>>>>>>
>>>>>>> try.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _________________________________________________________________
>>>>>>>> Express yourself instantly with MSN Messenger! Download today  
>>>>>>>> it's
>>>>>>>>
>>>>>>> FREE!
>>>>>>
>>>>>>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html
>>>>
>>>>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24209431.html
>>>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>> ----------------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
----------------------------------------------------------


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


Re: User's project-specific properties ability disabled after MNG-4060

Posted by Milos Kleint <mk...@gmail.com>.
On Fri, Nov 27, 2009 at 12:57 PM, Jason van Zyl <ja...@maven.org> wrote:

>
> On 2009-11-27, at 5:55 AM, Milos Kleint wrote:
>
>  I agree with Robert here.
>> removal of profiles.xml file leaves maven with no non-sharable,
>> per-project
>> configuration option. I"ve added my example to
>> the issue http://jira.codehaus.org/browse/MNG-4060.
>> It would be doable with settings.xml but it would be uber-cumbersome to do
>> so.
>>
>
> Why?
>
> I think an activator for a gav would work nicely.


if there is such a thing, yes, it would help. But then after each release,
you have to tinker with the activators.


>
>
>  It could partly work, but only when you work on one set of projects
>> only, or keep on  switching the settings file and have a separate copy for
>> each project (or set of projects).
>>
>>
> The profiles.xml made the internals extremely convoluted and hard to test.
> Most of the use cases I've seen are resolved by settings.xml and that can be
> made to be more intelligent to actually scope the profile in settings.xml to
> a specific project would effectively be the same thing, or the project
> needed to be decomposed into smaller projects.
>
> I'm fine with profiles.xml but you'll need to do the work to integrate that
> back into the project builder and build up the integration tests. I'm not
> interested in this work as I honestly don't think it's necessary. There are
> tests enough there to catch anything so you can do the work and know if
> you've disturbed any other part of the system so you should be good to go if
> you want to add this support back in.



Which just translates to "no". fair enough.

Milos



>
>
>
>> Milos
>>
>> On Thu, Jun 25, 2009 at 8:14 PM, Robert Scholte <rfscholte@codehaus.org
>> >wrote:
>>
>>
>>> I didn't say it's not possible without profiles.xml, but without it you
>>> have
>>> to make a choice between the best of the worst.
>>> Let's stick to the passwords. You don't want to expose them in the
>>> pom.xml,
>>> right?
>>> But what if project A en project B both have a ${password} in their
>>> pom.xml,
>>> from the settings.xml you can't figure out which password to use, UNLESS
>>> you
>>> have to keep settings the specific profile per project. Not really nice.
>>> But let me reverse the question. Why was the profiles.xml introduced and
>>> what made it the team to say goodbye to this file?
>>>
>>> Robert
>>>
>>>
>>> BRIAN FOX-5 wrote:
>>>
>>>>
>>>> Well, the mixin support should cover the profiles.xml and more....even
>>>> better it should be possible to resolve the mixins from the repository
>>>> which
>>>> means they are versioned and deployed artifacts like everything else.
>>>>
>>>> On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte
>>>> <rf...@codehaus.org>wrote:
>>>>
>>>>
>>>>> In the settings.xml it's not possible to activate a profile by project.
>>>>> Then
>>>>> again: I believe settings.xml are actually maven-settings and not
>>>>> project-settings. For most users it's a big step to dive into the
>>>>> settings.xml. For them there are only a few reasons to access the
>>>>> settings
>>>>> file:
>>>>> - to setup a proxy repository like nexus (which is often done by a more
>>>>> experienced user)
>>>>> - to set username+pw for a specific server.
>>>>> If they don't have to touch the file then leave it, 'cause changes here
>>>>> might break maven.
>>>>> And a user-specific project-profile has to be located on a very logic
>>>>>
>>>> and
>>>
>>>> easy to access location, so the best option is next to the pom I guess.
>>>>>
>>>>> -regards,
>>>>>
>>>>> Robert Scholte
>>>>>
>>>>>
>>>>>
>>>>> BRIAN FOX-5 wrote:
>>>>>
>>>>>>
>>>>>> Why not just put those values into the settings.xml?
>>>>>>
>>>>>> On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte<
>>>>>>
>>>>> rfscholte@codehaus.org>
>>>
>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> I heard some time ago that the profiles.xml were removed in Maven3.
>>>>>>> Although I'm still using 2.1.0 I want to be prepared for such
>>>>>>>
>>>>>> changes.
>>>
>>>>
>>>>>>> IMHO I think it's a bad choice to remove this option.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maven should provide some sort of way where developers can set/change
>>>>>>> project properties without having to change the pom.xml.
>>>>>>>
>>>>>>> I believe the pom should not contain developer-specific properties
>>>>>>>
>>>>>> and
>>>
>>>> which can or will end up in any scm. Think of datasource-properties.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There are three degrees of properties:
>>>>>>>
>>>>>>> - the global properties (combined with the activeByDefault-profile)
>>>>>>>
>>>>>>> - profile-properties (where profiles cover multiple users. By OS,
>>>>>>> 'stage')
>>>>>>>
>>>>>>> - personal properties.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> These personal properties can only be used with a personal profile. A
>>>>>>> personal profile is the best example of data which doesn´t belong in
>>>>>>>
>>>>>> a
>>>
>>>> pom but in a separate file (and probably not in scm).
>>>>>>>
>>>>>>> Personal properties should be somewhere close to the project, like in
>>>>>>>
>>>>>> the
>>>>>
>>>>>> root of the project (yes, like the profiles.xml).
>>>>>>>
>>>>>>> The both settings.xml is too far from the project and there's no
>>>>>>>
>>>>>> option
>>>>>
>>>>>> in the (user's) settings.xml to set project-specific properties.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think that if there was a vote concerning this issue it might
>>>>>>>
>>>>>> result
>>>
>>>> in
>>>>>
>>>>>> a long discussion. It's never too late for that, so let's give it a
>>>>>>>
>>>>>> try.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _________________________________________________________________
>>>>>>> Express yourself instantly with MSN Messenger! Download today it's
>>>>>>>
>>>>>> FREE!
>>>>>
>>>>>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>>
>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html
>>>
>>>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> View this message in context:
>>>
>>> http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24209431.html
>>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
> ----------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>