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 22:03:41 UTC
Re: User's project-specific properties ability disabled after MNG-4060
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 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