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]
