You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Phillip Hellewell <ss...@gmail.com> on 2010/10/03 23:34:19 UTC
Company-wide settings
I see that Maven can have a settings.xml at both the "Global Level"
and "User Level". Is there a way to have a settings.xml that can be
referenced (or included) from a pom.xml, whose settings would apply
first but could be overridden by a global or user settings.xml.
The idea is to have a shared "company-level" settings.xml with
settings like profiles that most developers will want, and to have
them automatically available. The alternative is for everyone to
manually append it to their global or user-level settings.xml.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Company-wide settings
Posted by "Thiessen, Todd (Todd)" <tt...@avaya.com>.
>
> One way is to make a custom Maven distribution for your organization,
> with a modified settings.xml.
>
> This also has the advantage of having all developers use the same
> version, which makes support easier.
>
> Many organizations don't allow developers to download and install
> random stuff off the internet anyway, so this becomes your
> corporate/approved/official Maven distro.
This is what we do for the most part. We checkout the global settings.xml file to the conf folder of the maven install. This way, if settings ever change, all a dev needs to do is an svn update on the file.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Company-wide settings
Posted by "Yanko, Curtis" <cu...@uhc.com>.
We do. It is simply a requirement for the AppDev team to implement. So,
even when they forget, we catch it in the build process since those
builds happen on our servers where the settings.xml is definitely set to
use our internal repository.
________________________________
Curt Yanko | Continuous Integration Services
Making IT Happen, one build at a time
-----Original Message-----
From: anders.g.hammar@gmail.com [mailto:anders.g.hammar@gmail.com] On
Behalf Of Anders Hammar
Sent: Monday, October 04, 2010 6:29 AM
To: Maven Users List
Subject: Re: Company-wide settings
One issue with this approach is that m2eclipse will not use this
settings.xml file (by default, as it has it's own embedded Maven). I
guess this could be solved by configuring the standalone Maven
installation in m2eclipse.
Anyone that has actually tried the approach of having a "corporate"
settings.xml bundled with a custom Maven distro?
/Anders
On Mon, Oct 4, 2010 at 11:46, Wendy Smoak <ws...@gmail.com> wrote:
> On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell <ss...@gmail.com>
> wrote:
> > The idea is to have a shared "company-level" settings.xml with
> > settings like profiles that most developers will want, and to have
> > them automatically available. The alternative is for everyone to
> > manually append it to their global or user-level settings.xml.
>
> One way is to make a custom Maven distribution for your organization,
> with a modified settings.xml.
>
> This also has the advantage of having all developers use the same
> version, which makes support easier.
>
> Many organizations don't allow developers to download and install
> random stuff off the internet anyway, so this becomes your
> corporate/approved/official Maven distro.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Company-wide settings
Posted by "Thiessen, Todd (Todd)" <tt...@avaya.com>.
> One issue with this approach is that m2eclipse will not use this
> settings.xml file (by default, as it has it's own embedded Maven). I
> guess
> this could be solved by configuring the standalone Maven installation in
> m2eclipse.
That is exactly what we do.
>
> Anyone that has actually tried the approach of having a "corporate"
> settings.xml bundled with a custom Maven distro?
We do have a custom "corporate" maven distro that developers can checkout. However, we have a number of teams that are using different versions of maven so our "recommended" approach for the organization is to simply checkout the settings.xml file to whatever maven installation they want.
For example, I have been trying to stay on the "somewhat" cutting edge of maven releases and have downloaded and tried the beta version of maven 3. Other teams are using fairly old versions. Not all teams are the same so we found that a common Maven distro for all devs to be overkill.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
On Mon, Oct 4, 2010 at 2:49 PM, Justin Edelson <ju...@gmail.com> wrote:
> On 10/4/10 2:34 PM, Phillip Hellewell wrote:
>>
>> Ok, slow down everyone. No worries. I just did a test and have found
>> that this approach fails miserably. It apparently wants the parent
>> pom to be available whenever I depend on this project, so obviously
>> this doesn't work.
> No, there's a lot of cause to worry. Because some poor shmuck is going
> to read this thread a year from now and think that there's actually a
> valid debate about where to put distributionManagement. There's not. It
> goes in the pom.
This was the email thread about where to put <repositories>, not
<distributionManagement>. For <repositories> I have been told
settings.xml is the best place.
> Put the URL in a parent POM. Deploy the parent POM to a repository. End
> of story.
Yes, I'm going to try this for <distributionManagement> again tomorrow
and try to get it working. I'm not sure why it was giving me trouble
today.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Justin Edelson <ju...@gmail.com>.
On 10/4/10 2:34 PM, Phillip Hellewell wrote:
> On Mon, Oct 4, 2010 at 12:30 PM, Anders Hammar <an...@hammar.net> wrote:
>> Philip, with all due respect, but reading your posts I get the impression
>> you're doing your best not to follow Maven best practice. Maven is all about
>> convention and best practice patterns. Please acknowledge that our advice is
>> based on actual experience and going your own path will surely get you into
>> trouble! It's not really a matter of what you think, but rather what Maven
>> thinks. :-)
>
> Ok, slow down everyone. No worries. I just did a test and have found
> that this approach fails miserably. It apparently wants the parent
> pom to be available whenever I depend on this project, so obviously
> this doesn't work.
No, there's a lot of cause to worry. Because some poor shmuck is going
to read this thread a year from now and think that there's actually a
valid debate about where to put distributionManagement. There's not. It
goes in the pom.
The failure is that you need to deploy your parent POM to a Maven
repository. That's the bootstrap problem. It's been discussed and
documented.
>
> So no worries, I'm fully convinced that I want to use settings.xml to
> specify repositories. But I'm still trying to find the best way to
> specify a distributionManagement in each of my poms without
> duplicating the <url>.
Put the URL in a parent POM. Deploy the parent POM to a repository. End
of story.
Justin
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Anders Hammar <an...@hammar.net>.
> Specifically, you'll run into issues when you need to change the
> distribution urls. To do that I need to either deploy a new release of
> the parent pom and change *all* of the other project poms to refer to
> the new release, or go manually remove the parent pom from nexus and
> deploy a changed one (which has all sorts of other problems). bleh.
>
Oh no, never NEVER remove (or alter) an artifact from a maven repo!
/Anders
RE: Company-wide settings
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Phillip Hellewell [mailto:sshock@gmail.com]
>
>On Mon, Oct 4, 2010 at 12:30 PM, Anders Hammar <an...@hammar.net>
wrote:
>> Philip, with all due respect, but reading your posts I get the
impression
>> you're doing your best not to follow Maven best practice. Maven is
all
>about
>> convention and best practice patterns. Please acknowledge that our
advice
>is
>> based on actual experience and going your own path will surely get
you
>into
>> trouble! It's not really a matter of what you think, but rather what
>Maven
>> thinks. :-)
>
>Ok, slow down everyone. No worries. I just did a test and have found
>that this approach fails miserably. It apparently wants the parent
>pom to be available whenever I depend on this project, so obviously
>this doesn't work.
>
>So no worries, I'm fully convinced that I want to use settings.xml to
>specify repositories. But I'm still trying to find the best way to
>specify a distributionManagement in each of my poms without
>duplicating the <url>.
fwiw, I'm using a (globally installed) settings.xml here to specify
where to retrieve artifacts from (a local nexus proxy). Most of the
projects I work with use a parent pom that specifies a
distributionManagement section, and it seems to work ok for the most
part, but there are some drawbacks.
Specifically, you'll run into issues when you need to change the
distribution urls. To do that I need to either deploy a new release of
the parent pom and change *all* of the other project poms to refer to
the new release, or go manually remove the parent pom from nexus and
deploy a changed one (which has all sorts of other problems). bleh.
eric
(btw, you'll hear a lot of people with a very fixed mindset regarding
the supposed "one true maven way", but don't think that everyone agrees
with that. I, for one, think the tools you use should guide you to a
good methodology, but should have at least a little bit of flexibility
to allow for the inevitable differences that pop up in real world
projects without throwing up tons of roadblocks)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
On Mon, Oct 4, 2010 at 12:30 PM, Anders Hammar <an...@hammar.net> wrote:
> Philip, with all due respect, but reading your posts I get the impression
> you're doing your best not to follow Maven best practice. Maven is all about
> convention and best practice patterns. Please acknowledge that our advice is
> based on actual experience and going your own path will surely get you into
> trouble! It's not really a matter of what you think, but rather what Maven
> thinks. :-)
Ok, slow down everyone. No worries. I just did a test and have found
that this approach fails miserably. It apparently wants the parent
pom to be available whenever I depend on this project, so obviously
this doesn't work.
So no worries, I'm fully convinced that I want to use settings.xml to
specify repositories. But I'm still trying to find the best way to
specify a distributionManagement in each of my poms without
duplicating the <url>.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Anders Hammar <an...@hammar.net>.
Philip, with all due respect, but reading your posts I get the impression
you're doing your best not to follow Maven best practice. Maven is all about
convention and best practice patterns. Please acknowledge that our advice is
based on actual experience and going your own path will surely get you into
trouble! It's not really a matter of what you think, but rather what Maven
thinks. :-)
/Anders
On Mon, Oct 4, 2010 at 19:29, Phillip Hellewell <ss...@gmail.com> wrote:
> On Mon, Oct 4, 2010 at 11:07 AM, Thiessen, Todd (Todd)
> <tt...@avaya.com> wrote:
> > Right. The blog entry explains this "bootstrapping" problem quite well.
>
> I'm not sure I will have the "bootstrap" problem, because I'm thinking
> about having this company pom be in SVN in a directory that all other
> components get automatically upon checkout via svn:externals.
>
> Since I am treating this pom as a settings file, I don't even care
> about it being in a repository, ever. In fact, if possible I would
> like to make it impossible for it to get deployed to a repository. I
> really want it to just be a settings file.
>
> Of course I'd much rather use the settings.xml for all this, but if I
> have to use a pom to specify the distributionManagement, then why not
> put the repositories in there too, as that keeps them all in the same
> place, will be easier to maintain, and everyone gets updates to it
> automatically.
>
> If putting repositories in POMs is a "Bad Idea", then I'd argue that
> putting distributionManagement in POMs is a "Bad Idea" too, but for
> some reason the settings.xml doesn't allow distributionManagement in
> there.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Company-wide settings
Posted by "Thiessen, Todd (Todd)" <tt...@avaya.com>.
You only need distribution management to specify what you deploy to, not where you get artifacts from. Very different. Deploying to has none of the issues described in the blog entry. This is a good use of the distro mangement section and you should put that in a parent pom somewhere and is not a bad thing as you are alluding to.
Your solution of svn externals sounds very complicated ;-). I am sure you will run into a number of problems with it.
There are also a couple of other issues that the blog discusses that you have not mentioned here:
1. If a transitive pom specifies a repository, you are going to hit the internet to try and download that dependency and not from your corporate repository.
2. Once you put repository information in your pom it is burned there forever. So if an artifact moves to another repository, you tags will not build and you will have to track down artifacts manually. While this is less of a problem for the Enterprise, it can and does happen.
> -----Original Message-----
> From: Phillip Hellewell [mailto:sshock@gmail.com]
> Sent: Monday, October 04, 2010 1:29 PM
> To: Maven Users List
> Subject: Re: Company-wide settings
>
> On Mon, Oct 4, 2010 at 11:07 AM, Thiessen, Todd (Todd)
> <tt...@avaya.com> wrote:
> > Right. The blog entry explains this "bootstrapping" problem quite well.
>
> I'm not sure I will have the "bootstrap" problem, because I'm thinking
> about having this company pom be in SVN in a directory that all other
> components get automatically upon checkout via svn:externals.
>
> Since I am treating this pom as a settings file, I don't even care
> about it being in a repository, ever. In fact, if possible I would
> like to make it impossible for it to get deployed to a repository. I
> really want it to just be a settings file.
>
> Of course I'd much rather use the settings.xml for all this, but if I
> have to use a pom to specify the distributionManagement, then why not
> put the repositories in there too, as that keeps them all in the same
> place, will be easier to maintain, and everyone gets updates to it
> automatically.
>
> If putting repositories in POMs is a "Bad Idea", then I'd argue that
> putting distributionManagement in POMs is a "Bad Idea" too, but for
> some reason the settings.xml doesn't allow distributionManagement in
> there.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
On Mon, Oct 4, 2010 at 11:07 AM, Thiessen, Todd (Todd)
<tt...@avaya.com> wrote:
> Right. The blog entry explains this "bootstrapping" problem quite well.
I'm not sure I will have the "bootstrap" problem, because I'm thinking
about having this company pom be in SVN in a directory that all other
components get automatically upon checkout via svn:externals.
Since I am treating this pom as a settings file, I don't even care
about it being in a repository, ever. In fact, if possible I would
like to make it impossible for it to get deployed to a repository. I
really want it to just be a settings file.
Of course I'd much rather use the settings.xml for all this, but if I
have to use a pom to specify the distributionManagement, then why not
put the repositories in there too, as that keeps them all in the same
place, will be easier to maintain, and everyone gets updates to it
automatically.
If putting repositories in POMs is a "Bad Idea", then I'd argue that
putting distributionManagement in POMs is a "Bad Idea" too, but for
some reason the settings.xml doesn't allow distributionManagement in
there.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Company-wide settings
Posted by "Thiessen, Todd (Todd)" <tt...@avaya.com>.
Right. The blog entry explains this "bootstrapping" problem quite well.
> -----Original Message-----
> From: anders.g.hammar@gmail.com [mailto:anders.g.hammar@gmail.com] On
> Behalf Of Anders Hammar
> Sent: Monday, October 04, 2010 1:02 PM
> To: Maven Users List
> Subject: Re: Company-wide settings
>
> It wouldn't work for other reasons as well.
> Here's one case:
> You're developing your Maven project. You specify the corp parent as the
> parent. But that pom is in the corp repo and not on your hard drive. And
> as
> the info about that repo is in the parent, Maven doesn't know of the repo
> and can't get the corp parent.
>
> It has to be defined in settings.xml.
>
> /Anders
> On Mon, Oct 4, 2010 at 18:57, Thiessen, Todd (Todd)
> <tt...@avaya.com>wrote:
>
> > I wouldn't personally. This blog at Sonatype explains why.
> >
> >
> > http://www.sonatype.com/people/2009/02/why-putting-repositories-in-
> your-poms-is-a-bad-idea/
> >
> >
> >
> > > -----Original Message-----
> > > From: Phillip Hellewell [mailto:sshock@gmail.com]
> > > Sent: Monday, October 04, 2010 12:55 PM
> > > To: Maven Users List
> > > Subject: Re: Company-wide settings
> > >
> > > On Mon, Oct 4, 2010 at 9:11 AM, Phillip Hellewell <ss...@gmail.com>
> > > wrote:
> > > > Thanks all for the great suggestions.
> > >
> > > Do you think using a parent pom for the settings would also be a
> > > workable solution?
> > >
> > > I'm already going to have to use a parent pom anyways, for the
> default
> > > distributionManagement (since that can't go in settings.xml), so
> maybe
> > > I should just do all my company-wide settings in a shared pom that
> > > every project includes using <parent>.
> > >
> > > Phillip
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Anders Hammar <an...@hammar.net>.
It wouldn't work for other reasons as well.
Here's one case:
You're developing your Maven project. You specify the corp parent as the
parent. But that pom is in the corp repo and not on your hard drive. And as
the info about that repo is in the parent, Maven doesn't know of the repo
and can't get the corp parent.
It has to be defined in settings.xml.
/Anders
On Mon, Oct 4, 2010 at 18:57, Thiessen, Todd (Todd) <tt...@avaya.com>wrote:
> I wouldn't personally. This blog at Sonatype explains why.
>
>
> http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
>
>
>
> > -----Original Message-----
> > From: Phillip Hellewell [mailto:sshock@gmail.com]
> > Sent: Monday, October 04, 2010 12:55 PM
> > To: Maven Users List
> > Subject: Re: Company-wide settings
> >
> > On Mon, Oct 4, 2010 at 9:11 AM, Phillip Hellewell <ss...@gmail.com>
> > wrote:
> > > Thanks all for the great suggestions.
> >
> > Do you think using a parent pom for the settings would also be a
> > workable solution?
> >
> > I'm already going to have to use a parent pom anyways, for the default
> > distributionManagement (since that can't go in settings.xml), so maybe
> > I should just do all my company-wide settings in a shared pom that
> > every project includes using <parent>.
> >
> > Phillip
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Company-wide settings
Posted by "Thiessen, Todd (Todd)" <tt...@avaya.com>.
I wouldn't personally. This blog at Sonatype explains why.
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
> -----Original Message-----
> From: Phillip Hellewell [mailto:sshock@gmail.com]
> Sent: Monday, October 04, 2010 12:55 PM
> To: Maven Users List
> Subject: Re: Company-wide settings
>
> On Mon, Oct 4, 2010 at 9:11 AM, Phillip Hellewell <ss...@gmail.com>
> wrote:
> > Thanks all for the great suggestions.
>
> Do you think using a parent pom for the settings would also be a
> workable solution?
>
> I'm already going to have to use a parent pom anyways, for the default
> distributionManagement (since that can't go in settings.xml), so maybe
> I should just do all my company-wide settings in a shared pom that
> every project includes using <parent>.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
On Mon, Oct 4, 2010 at 9:11 AM, Phillip Hellewell <ss...@gmail.com> wrote:
> Thanks all for the great suggestions.
Do you think using a parent pom for the settings would also be a
workable solution?
I'm already going to have to use a parent pom anyways, for the default
distributionManagement (since that can't go in settings.xml), so maybe
I should just do all my company-wide settings in a shared pom that
every project includes using <parent>.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
Thanks all for the great suggestions.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Company-wide settings
Posted by "Thiessen, Todd (Todd)" <tt...@avaya.com>.
We ask maven devs to checkout to their maven/conf folder. Their ~/.m2 can contain things like their personal passwords and profile information so we try not to copy the global settings.xml file to the local location.
> -----Original Message-----
> From: Nathan Sowatskey (nsowatsk) [mailto:nsowatsk@cisco.com]
> Sent: Monday, October 04, 2010 6:55 AM
> To: Maven Users List
> Cc: Maven Users List
> Subject: Re: Company-wide settings
>
> In our project we have a project wide settings.xml in Subversion, and we
> ask all developers to put that into their ~/.m2 directory.
>
> Regards
>
> Nathan
>
> Nathan Sowatskey (nsowatsk@cisco.com) - Technical Leader, ScanSafe - +34-
> 638-083-675
>
> On 4 Oct 2010, at 12:30, "Anders Hammar" <an...@hammar.net> wrote:
>
> > One issue with this approach is that m2eclipse will not use this
> > settings.xml file (by default, as it has it's own embedded Maven). I
> guess
> > this could be solved by configuring the standalone Maven installation
> in
> > m2eclipse.
> >
> > Anyone that has actually tried the approach of having a "corporate"
> > settings.xml bundled with a custom Maven distro?
> >
> > /Anders
> >
> > On Mon, Oct 4, 2010 at 11:46, Wendy Smoak <ws...@gmail.com> wrote:
> >
> >> On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell <ss...@gmail.com>
> >> wrote:
> >>> The idea is to have a shared "company-level" settings.xml with
> >>> settings like profiles that most developers will want, and to have
> >>> them automatically available. The alternative is for everyone to
> >>> manually append it to their global or user-level settings.xml.
> >>
> >> One way is to make a custom Maven distribution for your organization,
> >> with a modified settings.xml.
> >>
> >> This also has the advantage of having all developers use the same
> >> version, which makes support easier.
> >>
> >> Many organizations don't allow developers to download and install
> >> random stuff off the internet anyway, so this becomes your
> >> corporate/approved/official Maven distro.
> >>
> >> --
> >> Wendy
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by "Nathan Sowatskey (nsowatsk)" <ns...@cisco.com>.
In our project we have a project wide settings.xml in Subversion, and we ask all developers to put that into their ~/.m2 directory.
Regards
Nathan
Nathan Sowatskey (nsowatsk@cisco.com) - Technical Leader, ScanSafe - +34-638-083-675
On 4 Oct 2010, at 12:30, "Anders Hammar" <an...@hammar.net> wrote:
> One issue with this approach is that m2eclipse will not use this
> settings.xml file (by default, as it has it's own embedded Maven). I guess
> this could be solved by configuring the standalone Maven installation in
> m2eclipse.
>
> Anyone that has actually tried the approach of having a "corporate"
> settings.xml bundled with a custom Maven distro?
>
> /Anders
>
> On Mon, Oct 4, 2010 at 11:46, Wendy Smoak <ws...@gmail.com> wrote:
>
>> On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell <ss...@gmail.com>
>> wrote:
>>> The idea is to have a shared "company-level" settings.xml with
>>> settings like profiles that most developers will want, and to have
>>> them automatically available. The alternative is for everyone to
>>> manually append it to their global or user-level settings.xml.
>>
>> One way is to make a custom Maven distribution for your organization,
>> with a modified settings.xml.
>>
>> This also has the advantage of having all developers use the same
>> version, which makes support easier.
>>
>> Many organizations don't allow developers to download and install
>> random stuff off the internet anyway, so this becomes your
>> corporate/approved/official Maven distro.
>>
>> --
>> Wendy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Anders Hammar <an...@hammar.net>.
One issue with this approach is that m2eclipse will not use this
settings.xml file (by default, as it has it's own embedded Maven). I guess
this could be solved by configuring the standalone Maven installation in
m2eclipse.
Anyone that has actually tried the approach of having a "corporate"
settings.xml bundled with a custom Maven distro?
/Anders
On Mon, Oct 4, 2010 at 11:46, Wendy Smoak <ws...@gmail.com> wrote:
> On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell <ss...@gmail.com>
> wrote:
> > The idea is to have a shared "company-level" settings.xml with
> > settings like profiles that most developers will want, and to have
> > them automatically available. The alternative is for everyone to
> > manually append it to their global or user-level settings.xml.
>
> One way is to make a custom Maven distribution for your organization,
> with a modified settings.xml.
>
> This also has the advantage of having all developers use the same
> version, which makes support easier.
>
> Many organizations don't allow developers to download and install
> random stuff off the internet anyway, so this becomes your
> corporate/approved/official Maven distro.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Company-wide settings
Posted by Wendy Smoak <ws...@gmail.com>.
On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell <ss...@gmail.com> wrote:
> The idea is to have a shared "company-level" settings.xml with
> settings like profiles that most developers will want, and to have
> them automatically available. The alternative is for everyone to
> manually append it to their global or user-level settings.xml.
One way is to make a custom Maven distribution for your organization,
with a modified settings.xml.
This also has the advantage of having all developers use the same
version, which makes support easier.
Many organizations don't allow developers to download and install
random stuff off the internet anyway, so this becomes your
corporate/approved/official Maven distro.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Anders Hammar <an...@hammar.net>.
There is no such way as part of Maven.
However, you could have a settings.xml in your scm (or similar) and write a
simple script/program that copies it.
If you don't want to do this yourself, then there is such a feature as part
of Nexus Pro (the repo manager).
/Anders
On Sun, Oct 3, 2010 at 23:34, Phillip Hellewell <ss...@gmail.com> wrote:
> I see that Maven can have a settings.xml at both the "Global Level"
> and "User Level". Is there a way to have a settings.xml that can be
> referenced (or included) from a pom.xml, whose settings would apply
> first but could be overridden by a global or user settings.xml.
>
> The idea is to have a shared "company-level" settings.xml with
> settings like profiles that most developers will want, and to have
> them automatically available. The alternative is for everyone to
> manually append it to their global or user-level settings.xml.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Company-wide settings
Posted by David Jencks <da...@yahoo.com>.
Can't you put all these settings into a company wide parent pom that is the parent of each project pom (but not located in the file system parent)? You can certainly do this with profiles. All the apache projects that use maven that I know of do this. And, there's an apache wide pom that sets up stuff shared by pretty much all apache projects that use maven.
david jencks
On Oct 3, 2010, at 2:34 PM, Phillip Hellewell wrote:
> I see that Maven can have a settings.xml at both the "Global Level"
> and "User Level". Is there a way to have a settings.xml that can be
> referenced (or included) from a pom.xml, whose settings would apply
> first but could be overridden by a global or user settings.xml.
>
> The idea is to have a shared "company-level" settings.xml with
> settings like profiles that most developers will want, and to have
> them automatically available. The alternative is for everyone to
> manually append it to their global or user-level settings.xml.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
On Wed, Oct 6, 2010 at 11:33 AM, Phillip Hellewell <ss...@gmail.com> wrote:
>
> I probably should play it safe because I really don't want any
> artifacts to be incomplete in the repository, even if it is only the
> snapshot repository where this could happen.
Ok, I had another idea that could make developers happier. Tell me if
this is possible. I can keep my idea of having ${build.platform} and
${build.config} properties in the parent pom. Developers could
override these on the command-line or in their settings file so that
it only builds e.g., Release Win32. Developers can also do an install
to their local repo with an artifact that technically is incomplete.
However, since I never want incomplete artifacts in a remote repo, I
am wondering, can I put in a rule somewhere (e.g., in the parent pom)
that enforces it so that the deploy step will fail unless
${build.config} = "all" and ${build.platform} = "all"?
Please say yes!
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
On Wed, Oct 6, 2010 at 1:35 PM, Anders Hammar <an...@hammar.net> wrote:
> http://maven.40175.n5.nabble.com/how-to-centralize-configuration-accross-multiple-modules-td3199398.html#a3199398
>
> Searched Nabble for "separate configuration".
Thanks Anders. I read that thread.
I think I should be ok with my idea of allowing developers to create
"incomplete" artifacts that can be installed locally, but never
deployed to a remote repo. I found the enforcer plugin which I think
I can use to make the deploy phase fail immediately if ${build.config}
!= "all" or ${build.platform} != "all".
The other route would be to split every pom into four poms, and then
have the release-win32 pom files depend on other release-win32 pom
files, etc. etc. But this would take a lot of extra work to maintain,
and has even more questions like whether the headers should be
packaged with all the poms or could they be separate.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Anders Hammar <an...@hammar.net>.
http://maven.40175.n5.nabble.com/how-to-centralize-configuration-accross-multiple-modules-td3199398.html#a3199398
Searched Nabble for "separate configuration".
Anders
On Wed, Oct 6, 2010 at 19:33, Phillip Hellewell <ss...@gmail.com> wrote:
> On Wed, Oct 6, 2010 at 9:37 AM, Phillip Hellewell <ss...@gmail.com>
> wrote:
> >
> > I could set up the poms so they always build for all
> > platforms/configs, but that won't change anything because developers
> > will simply stop using Maven to do the build step. They just open the
> > .sln and use Visual Studio so they only have to build for one
> > platform/config.
>
> Ok, I still haven't found that other thread, but I'm thinking I may
> want to play it safe and have maven always build all 4 configurations
> (debug/release, win32/x64). In the day-to-day operations a within
> VStudio can of course do just one build at a time as they are
> debugging and testing, but in order to do an install or deploy, they
> have to go through Maven which will build everything.
>
> I probably should play it safe because I really don't want any
> artifacts to be incomplete in the repository, even if it is only the
> snapshot repository where this could happen.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
On Wed, Oct 6, 2010 at 9:37 AM, Phillip Hellewell <ss...@gmail.com> wrote:
>
> I could set up the poms so they always build for all
> platforms/configs, but that won't change anything because developers
> will simply stop using Maven to do the build step. They just open the
> .sln and use Visual Studio so they only have to build for one
> platform/config.
Ok, I still haven't found that other thread, but I'm thinking I may
want to play it safe and have maven always build all 4 configurations
(debug/release, win32/x64). In the day-to-day operations a within
VStudio can of course do just one build at a time as they are
debugging and testing, but in order to do an install or deploy, they
have to go through Maven which will build everything.
I probably should play it safe because I really don't want any
artifacts to be incomplete in the repository, even if it is only the
snapshot repository where this could happen.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
On Wed, Oct 6, 2010 at 8:22 AM, Anders Hammar <an...@hammar.net> wrote:
> No, never to a build for a specific environment! It's "One build fits all"!
> There was a recent thread about that; you might want to have a look to get
> the details.
Point me to that thread if you could, but I don't see how it will be a
problem. All the release builds (non-snapshot) will only be done by
official build machines, which will always use the default setting of
always building binaries for all platform/config environments.
Only developers in their day-to-day builds will want to do builds for
a specific environment, to save time.
I could set up the poms so they always build for all
platforms/configs, but that won't change anything because developers
will simply stop using Maven to do the build step. They just open the
.sln and use Visual Studio so they only have to build for one
platform/config.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Anders Hammar <an...@hammar.net>.
No, never to a build for a specific environment! It's "One build fits all"!
There was a recent thread about that; you might want to have a look to get
the details.
/Anders
On Wed, Oct 6, 2010 at 15:39, Phillip Hellewell <ss...@gmail.com> wrote:
> On Tue, Oct 5, 2010 at 2:56 AM, Vincent Latombe
> <vi...@gmail.com> wrote:
> > To handle distributionManagement, I define the url as a property that is
> > defined in settings.xml.
> > This allow me to define the whole connectivity from settings.xml. If ever
> my
> > repository changed, I just need to update settings.xml on my build
> machines,
> > instead of releasing a new parent and bumping parent version in all
> > projects.
>
> Just a reminder, this was the email thread about settings in general,
> for things like profiles. Also it seems to be agreed that
> <repositories> belong in the settings.xml.
>
> We weren't really talking about <distributionManagement>. That was in
> another thread. The comments in that other thread suggest that using
> settings.xml for <distributionManagement> is "wrong"; it should be
> done in a parent pom instead.
>
> One thing I am planning to have is a couple properties to determine
> what type of build to do, ${build.platform} and ${build.config}.
> ${build.platform} will be one of "Win32", "x64", or "all".
> ${build.config} will be one of "Release", "Debug", or "all". Based on
> what I have read in both these email threads, I believe the "correct"
> way to do this is to define those properties in my parent pom with
> default values ("all"), and then to override them if desired using
> profiles in settings.xml.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Company-wide settings
Posted by Phillip Hellewell <ss...@gmail.com>.
On Tue, Oct 5, 2010 at 2:56 AM, Vincent Latombe
<vi...@gmail.com> wrote:
> To handle distributionManagement, I define the url as a property that is
> defined in settings.xml.
> This allow me to define the whole connectivity from settings.xml. If ever my
> repository changed, I just need to update settings.xml on my build machines,
> instead of releasing a new parent and bumping parent version in all
> projects.
Just a reminder, this was the email thread about settings in general,
for things like profiles. Also it seems to be agreed that
<repositories> belong in the settings.xml.
We weren't really talking about <distributionManagement>. That was in
another thread. The comments in that other thread suggest that using
settings.xml for <distributionManagement> is "wrong"; it should be
done in a parent pom instead.
One thing I am planning to have is a couple properties to determine
what type of build to do, ${build.platform} and ${build.config}.
${build.platform} will be one of "Win32", "x64", or "all".
${build.config} will be one of "Release", "Debug", or "all". Based on
what I have read in both these email threads, I believe the "correct"
way to do this is to define those properties in my parent pom with
default values ("all"), and then to override them if desired using
profiles in settings.xml.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Company-wide settings
Posted by Vincent Latombe <vi...@gmail.com>.
To handle distributionManagement, I define the url as a property that is
defined in settings.xml.
This allow me to define the whole connectivity from settings.xml. If ever my
repository changed, I just need to update settings.xml on my build machines,
instead of releasing a new parent and bumping parent version in all
projects.
2010/10/5 Siegmann Daniel, NY <Da...@fja-us.com>
> Hi Phillip,
>
> This is easy enough to solve IME. Commit a Maven installation to your
> preferred repository (CVS, SVN, etc.), then all your developers can
> obtain that installation by checking it out of the repository. If
> something is changed you can modify settings.xml and commit to the repo,
> then everyone just has to update.
>
> If you need multiple versions just keep multiple copies in the repo.
>
> (This is how it works at my company. When Maven 3.0 is released I'll put
> it in my local workspace, update the settings.xml to point to our Nexus
> installation, and commit everything. Then I'll send out an email letting
> everyone know it's there.)
>
> Note that if you're using m2eclipse you'll want to point it to this
> installation (rather than using the embedded installation).
>
> ~Daniel
>
> -----Original Message-----
> From: Phillip Hellewell [mailto:sshock@gmail.com]
> Sent: Sunday, October 03, 2010 5:34 PM
> To: Maven Users List
> Subject: Company-wide settings
>
> I see that Maven can have a settings.xml at both the "Global Level"
> and "User Level". Is there a way to have a settings.xml that can be
> referenced (or included) from a pom.xml, whose settings would apply
> first but could be overridden by a global or user settings.xml.
>
> The idea is to have a shared "company-level" settings.xml with settings
> like profiles that most developers will want, and to have them
> automatically available. The alternative is for everyone to manually
> append it to their global or user-level settings.xml.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Vincent
RE: Company-wide settings
Posted by "Siegmann Daniel, NY" <Da...@fja-us.com>.
Hi Phillip,
This is easy enough to solve IME. Commit a Maven installation to your
preferred repository (CVS, SVN, etc.), then all your developers can
obtain that installation by checking it out of the repository. If
something is changed you can modify settings.xml and commit to the repo,
then everyone just has to update.
If you need multiple versions just keep multiple copies in the repo.
(This is how it works at my company. When Maven 3.0 is released I'll put
it in my local workspace, update the settings.xml to point to our Nexus
installation, and commit everything. Then I'll send out an email letting
everyone know it's there.)
Note that if you're using m2eclipse you'll want to point it to this
installation (rather than using the embedded installation).
~Daniel
-----Original Message-----
From: Phillip Hellewell [mailto:sshock@gmail.com]
Sent: Sunday, October 03, 2010 5:34 PM
To: Maven Users List
Subject: Company-wide settings
I see that Maven can have a settings.xml at both the "Global Level"
and "User Level". Is there a way to have a settings.xml that can be
referenced (or included) from a pom.xml, whose settings would apply
first but could be overridden by a global or user settings.xml.
The idea is to have a shared "company-level" settings.xml with settings
like profiles that most developers will want, and to have them
automatically available. The alternative is for everyone to manually
append it to their global or user-level settings.xml.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org