On 28 Sep 07, at 10:17 AM 28 Sep 07, Rollo, Dan wrote:
Sorry to reply to this listing, but I saw some messages about the
enforcer now enforcing no repo data in the pom and then read the link
below:
MNG-2381 improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
and I got worried. I've commented that jira issue with my current
practice of defining repo settings in a shared parent pom and
wondering
if there's some other "best practice" to share and update a common
settings.xml file across the organization. (I thought using the shared
parent with repo settings was the "best" way to do it.)
If this is the wrong place to ask this question, please tell me
where to
go.
I don't recommend anyone put repositories in the POMs. As a
corporation you should know all the repositories that you use, and
ultimately you should be using a repository manager and should move
toward having only one configuration element for dealing with
repositories and that's pointing at a repository manager.
Having repositories is initially convenient but lead to a lot of
potential pain, in addition to the chicken and egg problem.
Case in point in the OSS arena are projects like Tomcat and Axis
releasing with repositories in their POMs and then removing them.
Making their builds completely un-reproducible. If you move these
repositories at any point in the future you are bound to make sure
these repositories exist forever.
It is far easier to know the repositories up front and manage these
configurations for your users. No repositories in the POMs make the
builds far more stable because they are managed externally. Move your
repositories for builds created 3 years ago. No problem, as you have
managed them in settings.xml files for your developers. In the long
run it leads to a boatload of problems and makes the artifact
resolution process 10x more complicated then it needs to be. No other
artifact mechanism allows this, Ivy, and OSGi knows these values up
front and in a corporate environment you should definitely know all
your repositories up front.
What does this mean in practice? It means that everyone has to have a
configuration which satisfies repository requirements. In OSS it
means that projects would have to guarantee things are in the central
repository, or make sure project devs have settings for their
projects. In a corporate environment this is easy and have found
managing repositories in settings to be far more reliable, and safer
for the future reproducibility of builds. If you do not have 100%
over your IT, which most devs don't then don't put repositories in
your POMs or you will eventually get screwed. Hence the enforcer rule
which I've put into effect for all our corporate clients.
Thanks,
Dan
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 27, 2007 10:40 PM
To: dev@maven.apache.org
Subject: [jira] Subscription: Design & Best Practices
Issue Subscription
Filter: Design & Best Practices (29 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184 Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-2381 improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-2125 [doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-2584 Rebuild on pom change
http://jira.codehaus.org/browse/MNG-2584
MNG-139 server definitions should be reusable - review use of
repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1381 best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-1563 how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-1931 add a reportingManagement section
http://jira.codehaus.org/browse/MNG-1931
MNG-1950 Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-3198 ${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-3198
MNG-1867 deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-1885 Uniquely identify modules by module name and version
number
http://jira.codehaus.org/browse/MNG-1885
MNG-647 Allow Maven 2 to be monitored using JMX.
http://jira.codehaus.org/browse/MNG-647
MNG-868 Use uniform format for <properties> and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-1441 Starting thinking about a proper distributed repository
mechanism a la CPAN
http://jira.codehaus.org/browse/MNG-1441
MNG-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-1425 best practices: the location of configuration files vs
resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1439 Organization Object Model (OOM)
http://jira.codehaus.org/browse/MNG-1439
MNG-1468 best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
MNG-1463 best practices: plugin inheritance for a multi project
build
http://jira.codehaus.org/browse/MNG-1463
MNG-1423 best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1440 Developer Object Model (DOM)
http://jira.codehaus.org/browse/MNG-1440
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-1569 Make build process info read-only to mojos, and provide
mechanism for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
--------------------------------------------------
This e-mail and any files transmitted with it may contain
privileged or confidential information.
It is solely for use by the individual for whom it is intended,
even if addressed incorrectly.
If you received this e-mail in error, please notify the sender; do
not disclose, copy, distribute,
or take any action in reliance on the contents of this information;
and delete it from
your system. Any other use of this e-mail is prohibited.
Thank you for your compliance.
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
