Von: Jason van Zyl <ja...@sonatype.com>
An: Maven Developers List <dev@maven.apache.org>
Gesendet: Freitag, den 30. Oktober 2009, 17:16:51 Uhr
Betreff: Re: [DISCUSS] Handling of repositories in POMs of
dependencies
There are three primary variants of how the artifact resolution can
work with
respect to repositories where RS is the set of remote repositories
that will be
used for artifact resolution:
1) RS is what's available in the effective POM. Easy.
2) RS is collect from inspecting metadata transitively and
reconciling the
repositories found as a set before artifact resolution. Difficult.
3) RS is collection of partitions of sub-trees where the individual
repositories
are found. The reconciliation process becomes a backchaining
mediation.
Extremely difficult.
1) Pretty simple, and works with repository managers. Most large
organizations
will use one within a year. I love this idea from a Sonatype
perspective, but
from a Maven user perspective we potentially cripple OSS projects.
What we
decide to do here has long lasting effects. A variation on what
Josh Bloch says
about APIs. API design (and corresponding behavior) is like sex.
Make one
mistake and you support it for the rest of your life. If we pick
this method it
will categorically change the internals of the repository system
and it will
make it pretty much impossible to change to 2) or 3) in a practical
way. Based
on empirical observations in that aside from Oleg, Benjamin, Igor,
and myself
(all Sonatype at the time of implementation) no one has contributed
anything.
This is just not something that can be tinkered with so thinking we
can try this
method and then back it out and make it more sophisticated later is
a pipe
dream.
I think 2) and 3) require a lot of discussion. So really I think it
boils down
to are we going to really make 1) the way it works? Otherwise I
think we are
also obliged to look at the models in P2 and OBR because it
probably doesn't
make sense to re-invent another mediation and reconciliation
mechanism.
On 2009-10-29, at 12:27 PM, Brian Fox wrote:
It's amazing how google's thread compression of a discussion can
cause
me to overlook a huge thread so near and dear to my heart.
To start, Benjamin has hit the nail on the head of a discussion
point
Jason and I have had going for quite some time. In fact, we even
wrote
up a proposal for it months ago that got little feedback. I've also
blogged on this subject before.
Written and suggested reading in this order:
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery
I won't rehash all of what I've already written, and leave it to the
reader to follow the above urls for the majority of the points
however
I think there is one key argument that is worth reiterating:
The ability of a user to checkout an open source project with no
prior
knowledge of it and simply be able to build it, run the tests and
patch it the first try is the most powerful way to demonstrate the
Maven to new users. Simply removing or ignoring repositories in the
poms will break this functionality that I feel pretty strongly
about.
All of the arguments so far in this thread mostly revolve around
issues in corporate / enterprise use, and for these issues
repository
managers are the best solution. I don't think its in the best
interest
of the community to break OSS use to support Enterprise use,
particularly when that problem is already covered.
Specifically, I'm pretty strongly in favor of continuing to support
repositories declared in poms, however they should be scoped for
only
the subtree of dependencies introduced by the pom declaring the
repo.
Further, I recognize that having urls burned into immutable poms is
not the best way to accomplish this, and I think we need to find a
better one pretty quickly.
--Brian
On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly
wrote:
2009/10/28 Brett Porter
On 29/10/2009, at 2:08 AM, Daniel Kulp wrote:
On Wed October 28 2009 10:53:10 am John Casey wrote:
I tend to agree, they should not really be used. It seems like
these
third-party repositories have a strong potential for causing
network
errors (in cases where the repo is down or on a private
network), and
they definitely push the user in the direction of trusting
anything that
comes from anywhere on the internet without thinking
twice...not a great
idea, and an understandably unpopular one with companies.
I think the role of the declaration in the POM should be
shifted in Maven 3. I think this along the same lines that
Brett was
talking, but I'd really like to see them take on an advisory
role rather
than actively participate in resolution. In other words, if an
artifact
cannot be found, then display the list of third-party
repositories which
MIGHT contain the artifact, along with the POM that lists that
repository.
I'm OK with that EXCEPT for repositories defined in the current
pom+parents.
For transitive dependencies, yes, but not for building the
current
project.
+1
This avoids fudging with settings.xml, which has other problems
that others
have mentioned, and also because you start building a long list of
repositories then used on *every* project (unless Maven adds
some other gid
restriction on repositories).
+1... though this has the side-effect that if you checkout a
project who's
parent is only in a repository specified in the parent... well
hey, it's not
our fault! ;-)
On 29/10/2009, at 4:22 AM, Dan Rollo wrote:
To advocate the other side: I like the ability to define
repositories in
the pom.xml because team members (oss or corporate) can simply
"get latest"
from the source bank and things work OOTB.
I don't like the idea that the only way for things to work OOTB
is if all
artifacts MUST come from 'central'. There are other open source
repo's in
wide use. Same with private/corporate repos.
Forcing an edit to settings.xml (usually located in the user
home dir) is
also a maintenance issue for automated builds.
Agreed - I think the proposal above gives a balance between the
two
concerns.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org