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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> Kenney Westerhof
> http://www.neonics.com
> GPG public key: http://www.gods.nl/~forge/kenneyw.key
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
