Hi everyone,

I have an OSS project with "mixed" dependencies—some in central, and some
in our public Maven repo (because they are still in incubation or
beta). Every time this discussion arises, I find myself wondering the same
thing: how can you achieve an "out-of-the-box" build for such a project,
without specifying <repositories>? All the alternatives I see people
suggest (e.g., checking in settings.xml to the repository) would require
each and every new developer to perform some one-time bootstrap before the
project will build. This will turn away many new & inexperienced developers
if they try to import the project into their favorite IDE and it fails to
build.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Mon, Oct 17, 2016 at 4:48 PM, Manfred Moser <manf...@simpligility.com>
wrote:

> If you really feel you need to control the source of where you download
> components from within the source control system
> I would still NOT use the repositories definition in the POM since that is
> them transferred to the target repo on deployment (unless you use flatten).
>
> Instead I would check in a specific settings.xml as part of the project...
> or even multiple ones for different build scenarios..
>
> Manfred
>
> KARR, DAVID wrote on 2016-10-17 14:42:
>
> >> -----Original Message-----
> >> From: Manfred Moser [mailto:manf...@simpligility.com]
> >> Sent: Monday, October 17, 2016 1:35 PM
> >> To: users@maven.apache.org
> >> Subject: Re: Comparing specifying repositories in pom vs. settings.xml?
> >>
> >> http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-
> >> is-a-bad-idea/
> >
> > The point about open-source projects is well-taken.  I would never
> specify
> > repositories in a POM for a public project.
> >
> > The section about "Enterprise" just seems odd to me.  It seems very
> focused on
> > "central", when that might not be the case at all.  We use many
> open-source
> > projects, but those aren't very volatile.  We use dozens of internal
> artifacts,
> > and there isn't a lot of doubt about what repos to get particular kinds
> of
> > artifacts from.  I find build repeatability more important (specifying
> all
> > requirements in the build script).  The requirement about "generally
> will want
> > all your developers using the same set of repositories" is pretty
> important to
> > me, but the recommended solution just seems counterproductive.
> Specifying it
> > in the POM for the project seems to be the most direct way to ensure
> that.
> >
> >> KARR, DAVID wrote on 2016-10-17 13:03:
> >>
> >> > One thing I run into when jumping between different projects is
> >> > different expectations for what maven repos I need to be using.  In
> >> > the past, I had to have multiple copies of "~/.m2/settings.xml" lying
> >> > around, and I would hack the specified repos when I needed to.
> >> >
> >> > Recently, I saw a situation where the required repositories were
> >> > simply defined in the top-level pom for the project.  If this is done
> >> > consistently, there's no longer any need to hack the settings.xml
> >> file.
> >> >
> >> > I seem to remember seeing some advice that specifying repositories in
> >> > the POM is a bad practice.  If I'm remembering this correctly, this
> >> > seems odd.  Forcing the correct repos to be defined in the
> >> > settings.xml works against "repeatable builds".
> >> >
> >> > What is the recommended advice here?
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: users-h...@maven.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Reply via email to