You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Stephen Duncan <st...@gmail.com> on 2005/09/30 15:20:49 UTC
Best Solution to Parent POM Chicken & Egg Problem
What is truly the preferred/best solution to the chicken & the egg
problem with parent POM's? (Where your parent POM might define the
internal repository to use, but a project defines it's parent as this
POM, which is stored in the internal repository, and therefore how do
you get it the first time?)
Brett Porter said in one mailing list entry:
for information common to all projects, we recommend using an
organisation-wide parent POM that declares all the information. Of
course, this is a chicken and egg probem - you need the repository to
define the repository. The advantages to this are still:
- if you want to change the repository location you only need to
update that pom, not individual users computers (they get the new pom
from the old repository, and that is used for the new definition)
- you can share standard settings - organisation information, plugin
configuration, source layout, among all projects
Kenney Westerhof said in another mailing list entry:
This can cause a problem though: you usually define the artifact
repository in the root pom; if you check out a submodule, m2 might not
find the root pom in the correct repository; kinf of a chicken and egg
problem. A solution is to specify a company wide (or project
local) repository in your settings.xml.
I had started going down the route of always specifying the internal
repository in every POM I have, so that they could all be built
without requiring the user to know the details of the repository and
setting that up in settings.xml. When I changed to
password-protecting this internal repository, I've now required the
person checking out a project to at least define the password in the
sites section of settings.xml, so that benefit seems decreased.
Is the proper compromise to specify the team-wide repository in the
Parent POM, and then specify the repository to get that POM in
settings.xml?
--
Stephen Duncan Jr
www.stephenduncanjr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best Solution to Parent POM Chicken & Egg Problem
Posted by Brett Porter <br...@gmail.com>.
On 10/1/05, Chris Berry <ch...@gmail.com> wrote:
> As I've said previously, I do not believe that repository info has
> *any* place in a POM -- at any level of the hierarchy. A POM should be
> thought of as a recipe. And with any recipe, the recipe itself does
> not prescribe where to shop for the ingredients!!
Great analogy :)
However, in this case its a recipe that recommends where to find the
ingredients, though if you are able to get substitutions you are
equally able to specify it. My supermarket gives out recipes listing
where to find the ingredients in their preferred brands, though I know
their competitor also stocks canned tomatoes :)
> This is especially important for projects, because one cannot tell the
> different points in the product cycle to use the same repos. E.g.
> where I work, there is a build team that wants to explicitly build all
> packages headed into integration testing and finally on into
> Production. They will never point at any repos that development uses.
> Conversely, Dev has it's own repos -- for interim packages, for
> SNAPSHOTS, etc. One can think of the Production repo as a subset of
> the Dev repo, etc.
I think this is a misunderstanding of the enabled/disabled flag. We've
anticipated that repositories might be split into dev and prod (and
more). The enabled flags for snapshots/releases is not to say which
should be used for the project but rather whether to search that
repository when it is requested. It is still what the dependency
version is declared as that controls what is retrieved.
Changes to which repositories are available should be controlled by
profiles/settings which is under the control of the build engineer.
>
> IMO, repo info should *always* come from external settings.xml -- and
> that, if anything, settings.xml should allow an inherited hierarchy
> (with overrides) -- just like build.properties did in maven1. This is
> a powerful idiom. I was sorry to see it gone in m2.
This option is still available for your own projects. We did have
frequent problems with the m1 technique, though, as projects didn't
have access to deploy to central repository and wanted to share
artifacts with their users. It didn't make sense to check these
repositories for all artifacts - just those for the given project.
That said, I can see where it might be an issue for a build engineer.
I would be happy to keep working through this issue into future
releases, and also addressing some of the issues Doug raised about
wanting to only share a subset of the information (not something that
currently happens, but that we hope should eventuate in the long run).
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best Solution to Parent POM Chicken & Egg Problem
Posted by Chris Berry <ch...@gmail.com>.
As I've said previously, I do not believe that repository info has
*any* place in a POM -- at any level of the hierarchy. A POM should be
thought of as a recipe. And with any recipe, the recipe itself does
not prescribe where to shop for the ingredients!!
This is especially important for projects, because one cannot tell the
different points in the product cycle to use the same repos. E.g.
where I work, there is a build team that wants to explicitly build all
packages headed into integration testing and finally on into
Production. They will never point at any repos that development uses.
Conversely, Dev has it's own repos -- for interim packages, for
SNAPSHOTS, etc. One can think of the Production repo as a subset of
the Dev repo, etc.
IMO, repo info should *always* come from external settings.xml -- and
that, if anything, settings.xml should allow an inherited hierarchy
(with overrides) -- just like build.properties did in maven1. This is
a powerful idiom. I was sorry to see it gone in m2.
Yes, I get that arbitrary properties in build.properties can lead to
POM recipes that cannot be generally satisfied -- i.e. some prop is
required but undefined in the POM and comes from build.properties, and
thus, what value should it have?? The recipe is incomple. But
settings.xml is not arbitrary. It is limited to it's DTD.
My $.02,
-- Chris
On 9/30/05, Stephen Duncan <st...@gmail.com> wrote:
> What is truly the preferred/best solution to the chicken & the egg
> problem with parent POM's? (Where your parent POM might define the
> internal repository to use, but a project defines it's parent as this
> POM, which is stored in the internal repository, and therefore how do
> you get it the first time?)
>
> Brett Porter said in one mailing list entry:
>
> for information common to all projects, we recommend using an
> organisation-wide parent POM that declares all the information. Of
> course, this is a chicken and egg probem - you need the repository to
> define the repository. The advantages to this are still:
> - if you want to change the repository location you only need to
> update that pom, not individual users computers (they get the new pom
> from the old repository, and that is used for the new definition)
> - you can share standard settings - organisation information, plugin
> configuration, source layout, among all projects
>
>
> Kenney Westerhof said in another mailing list entry:
>
> This can cause a problem though: you usually define the artifact
> repository in the root pom; if you check out a submodule, m2 might not
> find the root pom in the correct repository; kinf of a chicken and egg
> problem. A solution is to specify a company wide (or project
> local) repository in your settings.xml.
>
>
> I had started going down the route of always specifying the internal
> repository in every POM I have, so that they could all be built
> without requiring the user to know the details of the repository and
> setting that up in settings.xml. When I changed to
> password-protecting this internal repository, I've now required the
> person checking out a project to at least define the password in the
> sites section of settings.xml, so that benefit seems decreased.
>
> Is the proper compromise to specify the team-wide repository in the
> Parent POM, and then specify the repository to get that POM in
> settings.xml?
>
> --
> Stephen Duncan Jr
> www.stephenduncanjr.com
>
> ---------------------------------------------------------------------
> 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: Best Solution to Parent POM Chicken & Egg Problem
Posted by Doug Douglass <dd...@denverdata.com>.
Chris Berry wrote:
>Kenney,
>
>It's not about taste. Defining repos in teh POM are a real problem.
>
>Here's an example; I recently got a POM from someone that had the
>SNAPSHOT repo defined in the POM. Fine, as long as you could get at
>it, which we couldn't. But that aside, this repo element defined
><snapshots>
> <enabled>true</enabled>
></snapshots>
><releases>
> <enabled>false</enabled>
></releases>
>
>So now let's assume I'm a build engineer that will *never* allow
>SNAPSHOTs. So what are they to do -- edit the POM to remove this
>statement. That seems very wrong to me. These guys don't edit POMs --
>they build things. (i.e. check out on v1.1.2 tag, build it, and deploy
>the artifacts) And if they then check this altered POM back into the
>SCM, (which they should for repeatability and proper tagging) what
>happens to teh develoer that needs to use SNAPSHOTs. They would have
>to change it back. And on and on... Does that seem right?? What am I
>missing??
>
>In my opinion, repo info is orthogonal to the project definition,
>Coupling them seems a mistake, particularly juxtaposed against large
>organizations with tight change control and production build policies.
>
>Cheers,
>-- Chris
>
>
Chris,
We haven't stepped up to actually using m2 on project, still m1, but
I've been exploring it's capabilities and the code base. This is
definitely an interesting topic for helpling to understand m2 issues and
prepare for transition.
I tend to agree with you regarding the repo info, but couldn't the same
argument be made of other POM info such as SCM URLs? Such info certainly
doesn't make sense outside of most organizations (does/could m2 filter
out such POM info when deploying to an external repo????).
Perhaps the best practice depends on the audience for the POM:
1.) If the POM will never "leave the house", I think Kenny is right.
2.) If the artifact is to be publicly published, you're on track and
either the best practice changes, or some culling of the POM info needs
to (automagically?) happen.
3.) If the POM is delivered as part of a source distribution, then I
think we're back to #1
What is the context of your example where you "received a POM from a
friend"? Was it 1,2,3 above, or something I've missed?
BTW, I hope your build engineer does more than checkout, build and
deploy otherwise their job is in jeopardy ;) Since you mention they
"will *never* allow SNAPSHOTs", is that then part of their job -- they
resolve SNAPSHOT dependencies? In which case they may very well require
checking the POM back into SCM.
DD
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best Solution to Parent POM Chicken & Egg Problem
Posted by Chris Berry <ch...@gmail.com>.
Kenney,
It's not about taste. Defining repos in teh POM are a real problem.
Here's an example; I recently got a POM from someone that had the
SNAPSHOT repo defined in the POM. Fine, as long as you could get at
it, which we couldn't. But that aside, this repo element defined
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
So now let's assume I'm a build engineer that will *never* allow
SNAPSHOTs. So what are they to do -- edit the POM to remove this
statement. That seems very wrong to me. These guys don't edit POMs --
they build things. (i.e. check out on v1.1.2 tag, build it, and deploy
the artifacts) And if they then check this altered POM back into the
SCM, (which they should for repeatability and proper tagging) what
happens to teh develoer that needs to use SNAPSHOTs. They would have
to change it back. And on and on... Does that seem right?? What am I
missing??
In my opinion, repo info is orthogonal to the project definition,
Coupling them seems a mistake, particularly juxtaposed against large
organizations with tight change control and production build policies.
Cheers,
-- Chris
On 9/30/05, Kenney Westerhof <ke...@apache.org> wrote:
> On Fri, 30 Sep 2005, Stephen Duncan wrote:
>
> Brett's anwer (define repo @ pom) is the way to go.
> My 'settings.xml' solution is merely a convenient way
> to help locate that parent pom the first time - if you don't
> have that repository on the list, you're going to have to
> manually download (or use a lengthy commandline) to install
> the desired pom and it's parents.
>
> On the other hand, having a company wide repo specified in settings.xml
> gives them the power to decide what you can and cannot use (beside
> company-created artifacts).
>
> I think it's a matter of taste and convenience what's best for you.
>
> -- Kenney
>
> > What is truly the preferred/best solution to the chicken & the egg
> > problem with parent POM's? (Where your parent POM might define the
> > internal repository to use, but a project defines it's parent as this
> > POM, which is stored in the internal repository, and therefore how do
> > you get it the first time?)
> >
> > Brett Porter said in one mailing list entry:
> >
> > for information common to all projects, we recommend using an
> > organisation-wide parent POM that declares all the information. Of
> > course, this is a chicken and egg probem - you need the repository to
> > define the repository. The advantages to this are still:
> > - if you want to change the repository location you only need to
> > update that pom, not individual users computers (they get the new pom
> > from the old repository, and that is used for the new definition)
> > - you can share standard settings - organisation information, plugin
> > configuration, source layout, among all projects
> >
> >
> > Kenney Westerhof said in another mailing list entry:
> >
> > This can cause a problem though: you usually define the artifact
> > repository in the root pom; if you check out a submodule, m2 might not
> > find the root pom in the correct repository; kinf of a chicken and egg
> > problem. A solution is to specify a company wide (or project
> > local) repository in your settings.xml.
> >
> >
> > I had started going down the route of always specifying the internal
> > repository in every POM I have, so that they could all be built
> > without requiring the user to know the details of the repository and
> > setting that up in settings.xml. When I changed to
> > password-protecting this internal repository, I've now required the
> > person checking out a project to at least define the password in the
> > sites section of settings.xml, so that benefit seems decreased.
> >
> > Is the proper compromise to specify the team-wide repository in the
> > Parent POM, and then specify the repository to get that POM in
> > settings.xml?
> >
> > --
> > Stephen Duncan Jr
> > www.stephenduncanjr.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> --
> Kenney Westerhof
> http://www.neonics.com
> GPG public key: http://www.gods.nl/~forge/kenneyw.key
>
> ---------------------------------------------------------------------
> 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: Best Solution to Parent POM Chicken & Egg Problem
Posted by Kenney Westerhof <ke...@apache.org>.
On Fri, 30 Sep 2005, Stephen Duncan wrote:
Brett's anwer (define repo @ pom) is the way to go.
My 'settings.xml' solution is merely a convenient way
to help locate that parent pom the first time - if you don't
have that repository on the list, you're going to have to
manually download (or use a lengthy commandline) to install
the desired pom and it's parents.
On the other hand, having a company wide repo specified in settings.xml
gives them the power to decide what you can and cannot use (beside
company-created artifacts).
I think it's a matter of taste and convenience what's best for you.
-- Kenney
> What is truly the preferred/best solution to the chicken & the egg
> problem with parent POM's? (Where your parent POM might define the
> internal repository to use, but a project defines it's parent as this
> POM, which is stored in the internal repository, and therefore how do
> you get it the first time?)
>
> Brett Porter said in one mailing list entry:
>
> for information common to all projects, we recommend using an
> organisation-wide parent POM that declares all the information. Of
> course, this is a chicken and egg probem - you need the repository to
> define the repository. The advantages to this are still:
> - if you want to change the repository location you only need to
> update that pom, not individual users computers (they get the new pom
> from the old repository, and that is used for the new definition)
> - you can share standard settings - organisation information, plugin
> configuration, source layout, among all projects
>
>
> Kenney Westerhof said in another mailing list entry:
>
> This can cause a problem though: you usually define the artifact
> repository in the root pom; if you check out a submodule, m2 might not
> find the root pom in the correct repository; kinf of a chicken and egg
> problem. A solution is to specify a company wide (or project
> local) repository in your settings.xml.
>
>
> I had started going down the route of always specifying the internal
> repository in every POM I have, so that they could all be built
> without requiring the user to know the details of the repository and
> setting that up in settings.xml. When I changed to
> password-protecting this internal repository, I've now required the
> person checking out a project to at least define the password in the
> sites section of settings.xml, so that benefit seems decreased.
>
> Is the proper compromise to specify the team-wide repository in the
> Parent POM, and then specify the repository to get that POM in
> settings.xml?
>
> --
> Stephen Duncan Jr
> www.stephenduncanjr.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best Solution to Parent POM Chicken & Egg Problem
Posted by Brett Porter <br...@gmail.com>.
On 9/30/05, Stephen Duncan <st...@gmail.com> wrote:
> Is the proper compromise to specify the team-wide repository in the
> Parent POM, and then specify the repository to get that POM in
> settings.xml?
That was what I was getting at. I will address Chris' concerns separately.
A better solution to the problem of propogating changes to all the
user's settings.xml is probably something we will look to address
separately and can currently be handled by using
$M2_HOME/conf/settings.xml and a shared maven installation (on a
network drive, from a cvs checkout, etc).
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org