reintroduction of maven.properties for config orthogonal to POMs

[Jason van Zyl <jv...@maven.org>]

Howdy,

We've chatted about this briefly but I would like to at least use a
maven.properties file for the specification of the maven.repo.local
value. I think we've discussed it being orthogonal to anything in the
POM and I would really like to have a defined way of specifying
maven.repo.local and how to ascertain its value.

Right now we have a slew of things trying to find maven.repo.local:
compilers, continuum and some other various tools and some of look for
override.xml, maven.properties, a system property and it's time to fold
this all into a standard strategy for getting the value of
maven.repo.local.

I'm not sure if there will be any configuration options like
maven.repo.local but I think it belongs outside the POM and we can
search for its value in a defined way like:

- system.property (for tools that embed m2)
- value in ~/.m2/maven.properties

Or whatever is best we should do, I would like to align everything this
week. M1 will obey system properties over anything else so maybe we
should take the same approach with m2.

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 

Re: reintroduction of maven.properties for config orthogonal to POMs

[Jason van Zyl <jv...@maven.org>]

On Mon, 2004-11-01 at 15:07, Brett Porter wrote:
> >An XML configuration might be better I suppose but we don't need a
> >component to provide those settings. That's a bit much.
> >  
> >
> Sure - I agree. But I did want to avoid too many things reading it on 
> their own and not handling the same hierachy (default, site, user) 
> mentioned in the previous email.

Sure, the only thing I can think that truly sits in isolation is the
local repo setting.

> When discussing embedding, did you agree about that these are actually 
> configuration that should be passed in to Maven?

Yes, the maven component must have those values set. The CLI front-end
simply picks them off and passes them in.

>  Continuum (as an 
> example) could be able to read the same files, but not have to.

Right, continuum acting as the front-end would do the same thing.

> Cheers,
> Bret

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 

Re: reintroduction of maven.properties for config orthogonal to POMs

[Brett Porter <br...@apache.org>]

>An XML configuration might be better I suppose but we don't need a
>component to provide those settings. That's a bit much.
>  
>
Sure - I agree. But I did want to avoid too many things reading it on 
their own and not handling the same hierachy (default, site, user) 
mentioned in the previous email.

When discussing embedding, did you agree about that these are actually 
configuration that should be passed in to Maven? Continuum (as an 
example) could be able to read the same files, but not have to.

Cheers,
Bret

Re: reintroduction of maven.properties for config orthogonal to POMs

[Jason van Zyl <jv...@maven.org>]

On Mon, 2004-11-01 at 06:46, Brett Porter wrote:

> I agree with Michal that keeping maven.repo.local and proxies together, 
> and in an xml configuration, is a good idea.

An XML configuration might be better I suppose but we don't need a
component to provide those settings. That's a bit much.

> Cheers,
> Brett

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 

Re: reintroduction of maven.properties for config orthogonal to POMs

[Brett Porter <br...@apache.org>]

> I am pretty sure that there will be other configuration settings which 
> belongs outside the pom.
> Configuration of Proxy Server(s) settings is one of them.
>
> I think we should rather use xml file then properties file as it will 
> give as a better flexibility
> I suppose that we can try to use the new functionality provided by 
> plexus - linked and inlined external configuration for reading such 
> settings. Maybe we can introduce new component which will contain an 
> access to those settings?
>
This was why I put it into the POM, under a <local> section which could 
be treated specially. Proxies are something that would belong in both 
site and user configuration, but not project configuration.

Perhaps extracting the local section to a separate configuration file is 
the best alternative (so it is just a simple default -> site -> user 
inheritence).

I agree with Michal that keeping maven.repo.local and proxies together, 
and in an xml configuration, is a good idea.

Cheers,
Brett

Re: reintroduction of maven.properties for config orthogonal to POMs

[Michal Maczka <mm...@interia.pl>]

Jason van Zyl wrote:

>Howdy,
>
>  
>
[..]

>I'm not sure if there will be any configuration options like
>maven.repo.local but I think it belongs outside the POM and we can
>search for its value in a defined way like:
>
>- system.property (for tools that embed m2)
>- value in ~/.m2/maven.properties
>
>Or whatever is best we should do, I would like to align everything this
>week. M1 will obey system properties over anything else so maybe we
>should take the same approach with m2.
>
>  
>
I am pretty sure that there will be other configuration settings which 
belongs outside the pom.
Configuration of Proxy Server(s) settings is one of them. 


I think we should rather use xml file then properties file as it will 
give as a better flexibility
I suppose that we can try to use the new functionality provided by 
plexus - linked and inlined external configuration for reading such 
settings. Maybe we can introduce new component which will contain an 
access to those settings?

Michal







----------------------------------------------------------------------
Startuj z INTERIA.PL!!! >>> http://link.interia.pl/f1837

Re: reintroduction of maven.properties for config orthogonal to POMs

[Brett Porter <br...@apache.org>]

> Take the case of embedding Maven itself as a component. The whereabouts
> of the local repository is required: this is the case for continuum. So
> it's not simply mojos but Maven itself.

But being able to read maven.properties here is just convenience of having it in
one location. This is really continuum's configuration in this case - continuum
may want to be able to specify a completely different local repository and be
able to tell Maven that without using maven.properties.

> In the compiler components the location of the local repository is used
> for tests, and the comiler component is used in modello to check the
> validity of the generated sources. It may be in these cases that we just
> use surefire to set another system property for the local repository as
> we do for the basedir.

That sounds like a good way to do it.

> I'll update the configuration-management APT doc in CVS which I used as
> a starting point a couple months ago.

Cool. I think I updated it with my changes, but can't remember. I'll do so if
needed.

Cheers,
Brett

Re: reintroduction of maven.properties for config orthogonal to POMs

[Jason van Zyl <jv...@maven.org>]

On Sun, 2004-10-31 at 15:15, Brett Porter wrote:
> I didn't realise there were things outside of maven-core using it, other 
> than via the parameter of a mojo - that doesn't sound right to me.

Take the case of embedding Maven itself as a component. The whereabouts
of the local repository is required: this is the case for continuum. So
it's not simply mojos but Maven itself.

In the compiler components the location of the local repository is used
for tests, and the comiler component is used in modello to check the
validity of the generated sources. It may be in these cases that we just
use surefire to set another system property for the local repository as
we do for the basedir.

> Is there anything else in the configuration processing that needs 
> attention? As I understand it, the plan is to have:
> - a POM containing site defaults, in the maven installation
> - a POM that contains user overrides, in the user home directory
> - a POM that contains project overrides, which sits alongside the 
> pom.xml (like build.properties in m1)
> 
> These are mostly for overriding plugin properties though, I'd guess. But 
> I can still see some specific uses:
> - site specified organization tag, distribution and possibly ciManagement
> - I'd tend to set in the user home directory things like the remote 
> repositories
> - in the project overrides, you might use this instead of making 
> temporary edits to pom.xml. Eg, add a new unit test exclusion.

I'll update the configuration-management APT doc in CVS which I used as
a starting point a couple months ago.

> Cheers,
> Brett
> 
> Jason van Zyl wrote:
> 
> >Howdy,
> >
> >We've chatted about this briefly but I would like to at least use a
> >maven.properties file for the specification of the maven.repo.local
> >value. I think we've discussed it being orthogonal to anything in the
> >POM and I would really like to have a defined way of specifying
> >maven.repo.local and how to ascertain its value.
> >
> >Right now we have a slew of things trying to find maven.repo.local:
> >compilers, continuum and some other various tools and some of look for
> >override.xml, maven.properties, a system property and it's time to fold
> >this all into a standard strategy for getting the value of
> >maven.repo.local.
> >
> >I'm not sure if there will be any configuration options like
> >maven.repo.local but I think it belongs outside the POM and we can
> >search for its value in a defined way like:
> >
> >- system.property (for tools that embed m2)
> >- value in ~/.m2/maven.properties
> >
> >Or whatever is best we should do, I would like to align everything this
> >week. M1 will obey system properties over anything else so maybe we
> >should take the same approach with m2.
> >
> >  
> >
> 

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 

Re: reintroduction of maven.properties for config orthogonal to POMs

[Brett Porter <br...@apache.org>]

I didn't realise there were things outside of maven-core using it, other 
than via the parameter of a mojo - that doesn't sound right to me.

I'm happy enough for it to go back to being in the properties file - I 
didn't really think that it felt right in the POM, however it did have 
the advantage of discouraging anyone from just reading that file instead 
of passing it around properly. Things like continuum obviously need to 
override it.

Is there anything else in the configuration processing that needs 
attention? As I understand it, the plan is to have:
- a POM containing site defaults, in the maven installation
- a POM that contains user overrides, in the user home directory
- a POM that contains project overrides, which sits alongside the 
pom.xml (like build.properties in m1)

These are mostly for overriding plugin properties though, I'd guess. But 
I can still see some specific uses:
- site specified organization tag, distribution and possibly ciManagement
- I'd tend to set in the user home directory things like the remote 
repositories
- in the project overrides, you might use this instead of making 
temporary edits to pom.xml. Eg, add a new unit test exclusion.

Cheers,
Brett

Jason van Zyl wrote:

>Howdy,
>
>We've chatted about this briefly but I would like to at least use a
>maven.properties file for the specification of the maven.repo.local
>value. I think we've discussed it being orthogonal to anything in the
>POM and I would really like to have a defined way of specifying
>maven.repo.local and how to ascertain its value.
>
>Right now we have a slew of things trying to find maven.repo.local:
>compilers, continuum and some other various tools and some of look for
>override.xml, maven.properties, a system property and it's time to fold
>this all into a standard strategy for getting the value of
>maven.repo.local.
>
>I'm not sure if there will be any configuration options like
>maven.repo.local but I think it belongs outside the POM and we can
>search for its value in a defined way like:
>
>- system.property (for tools that embed m2)
>- value in ~/.m2/maven.properties
>
>Or whatever is best we should do, I would like to align everything this
>week. M1 will obey system properties over anything else so maybe we
>should take the same approach with m2.
>
>  
>