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 <repository> 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).
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: [email protected]
For additional commands, e-mail: [email protected]
