You are viewing a plain text version of this content. The canonical link for it is here.
Posted to npanday-dev@incubator.apache.org by Brett Porter <br...@apache.org> on 2011/03/01 17:09:57 UTC

Re: [NPanday] - Proposal for NPanday-361

On 28/02/2011, at 9:27 AM, Prins, drs. M.C. (Mark) wrote:
>> Before you invent a property, does Maven already have one it
>> knows about for the regular settings.xml file?
> 
> There are two well known locations; one in the .m2 directory that is in the users %HOMEDRIVE% or %HOME% directory (or user profile directory), this depends on), the other is a system level in %M2_HOME%\conf
> 
> The system level one is always there, the user level one doesn't have to be there, I think...
> 
> When you run mvn w/ -X you can see it 1st tries to load the system file and then th euser file.

Yep. We don't need the global location as npanday-settings doesn't currently merge those and it shouldn't write anything into the installation. You can lookup where -s pointed to, but I wouldn't rely on magic to write to the same directory.

Since everything in NPanday originates from a mojo, I think the best thing to do is to always have a mojo property for expression ${npanday.settings}. That will honour both a property in a profile and on the command line, as well as being able to set it in the plugin configuration on a per-execution basis. If not set, it can default to ${user.home}/.m2/npanday-settings.xml.

From the mojo, this value needs to be passed into method calls that require it (or lookup a central component and set the value).

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/

Re: [NPanday] - Proposal for NPanday-361

Posted by Wendy Smoak <ws...@gmail.com>.
On Wed, Mar 2, 2011 at 3:56 PM, Lars Corneliussen <me...@lcorneliussen.de> wrote:

> as it is readonly, settings is a bad name :(
>
> it wasn't readonly before liits commits. i changed it to support x86 builds on my 64bit machine

I'm pretty sure Brett meant the normal Maven ~/.m2/settings.xml.
Maven only reads that file, it doesn't create or change it.

-- 
Wendy

Re: [NPanday] - Proposal for NPanday-361

Posted by Lars Corneliussen <me...@lcorneliussen.de>.
as it is readonly, settings is a bad name :(

it wasn't readonly before liits commits. i changed it to support x86 builds on my 64bit machine

--
Message sent from mobile device

Am 02.03.2011 um 19:09 schrieb Brett Porter <br...@apache.org>:

> On 02/03/2011, at 6:33 AM, Lars Corneliussen wrote:
> 
>> Should it be created if it doesn't exist? I suggest only automatic creation, when it is set to default location. 
>> 
>> Else it can be scaffolded using the generate-settings goal. 
>> 
>> What does maven do, if settings location is overridden?
> 
> It's read-only, so doesn't really matter in that case. I think it makes sense to create it (and parent directories).
> 
> - Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>

Re: [NPanday] - Proposal for NPanday-361

Posted by Brett Porter <br...@apache.org>.
On 02/03/2011, at 6:33 AM, Lars Corneliussen wrote:

> Should it be created if it doesn't exist? I suggest only automatic creation, when it is set to default location. 
> 
> Else it can be scaffolded using the generate-settings goal. 
> 
> What does maven do, if settings location is overridden?

It's read-only, so doesn't really matter in that case. I think it makes sense to create it (and parent directories).

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/

Re: [NPanday] - Proposal for NPanday-361

Posted by Lars Corneliussen <me...@lcorneliussen.de>.
Should it be created if it doesn't exist? I suggest only automatic creation, when it is set to default location. 

Else it can be scaffolded using the generate-settings goal. 

What does maven do, if settings location is overridden?

--
Message sent from mobile device

Am 01.03.2011 um 18:09 schrieb Brett Porter <br...@apache.org>:

> 
> On 28/02/2011, at 9:27 AM, Prins, drs. M.C. (Mark) wrote:
>>> Before you invent a property, does Maven already have one it
>>> knows about for the regular settings.xml file?
>> 
>> There are two well known locations; one in the .m2 directory that is in the users %HOMEDRIVE% or %HOME% directory (or user profile directory), this depends on), the other is a system level in %M2_HOME%\conf
>> 
>> The system level one is always there, the user level one doesn't have to be there, I think...
>> 
>> When you run mvn w/ -X you can see it 1st tries to load the system file and then th euser file.
> 
> Yep. We don't need the global location as npanday-settings doesn't currently merge those and it shouldn't write anything into the installation. You can lookup where -s pointed to, but I wouldn't rely on magic to write to the same directory.
> 
> Since everything in NPanday originates from a mojo, I think the best thing to do is to always have a mojo property for expression ${npanday.settings}. That will honour both a property in a profile and on the command line, as well as being able to set it in the plugin configuration on a per-execution basis. If not set, it can default to ${user.home}/.m2/npanday-settings.xml.
> 
> From the mojo, this value needs to be passed into method calls that require it (or lookup a central component and set the value).
> 
> - Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>