Well yes, that's all good and definitely encouraged for any maven
project you are in control of.
But I also think it's worth standing up an artifact repository at your
own organization and having that 'mirror' every repository. So that you
actually don't go out and hit any repository directly yourself. Instead
you only hit your own artifact repository, and that repository in turn
will hit the internet. This is kind of the equivalent of fixing, at an
organizational level the difference between a developer who has been
around for a while and has a pretty full personal maven repo, and his
builds work, and a new developer who has an empty personal maven
repository and his build does not work.
I'm NOT suggesting this is INSTEAD of putting things into central, but
more of an additional thing an organization can do to help bring new
developers on board.
---- Cris J H
On 06/13/2014 11:01 AM, Andrew Petro wrote:
Cris,
True, dependencies in Central can have dependencies on external repos.
But that is at least discouraged:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement
and in some happy future might even be enforced or at least mostly
respected such that getting a dependency from Central is an indication
that it doesn't have this problem.
So, you're all right: getting the dependencies from Central doesn't
solve all problems, but the more dependencies are entirely realizable
via only-in-Central dependencies, the better.
:)
Kind regards,
Andrew
On 6/13/14, 12:54 PM, Cris J Holdorph wrote:
It's not just a simple matter of putting YOUR dependencies into
central and not putting repositories into YOUR pom files. With
transitive dependencies, ESPECIALLY specific versions, this can happen
through a dependency that came in from a transitive dependency.
Example:
I specify I want to use "Foo" version "1.1". At the time of my
using it, it is in central, so I don't think anything more of it.
I do not notice, but Foo version 1.1, uses "bar" 2.0.
Bar 2.0 uses crud 3.0.
crud 3.0 specifies a respository in it's pom.xml file to go get
"blah" version 1.2.3 from some weird repo.
Final result, my project is now dependent on some weird repo for
version 1.2.3 of "blah".
---- Cris J H
On 06/13/2014 09:57 AM, Eric Dalquist wrote:
This highlights the very real danger of adding extra repositories. It
may be more work up front to get all the deps you need into central but
it is very much worth it long term to avoid this sort of dependency hell
pain.
On Fri, Jun 13, 2014 at 9:49 AM, Cris J Holdorph <holdo...@unicon.net
<mailto:holdo...@unicon.net>> wrote:
This is probably not your problem, but I thought I would share some
recent experience with maven, repositories and dependency debugging.
I was trying to set up a local artifact repository to do mirroring
of maven dependencies. This is useful for dependencies that are not
in central, that might disappear.
Anyway, to fully test my 'mirror' I started with an empty repository
and would try to build my projects. I discovered a really
interesting situation. Take a look at these two pom files from two
different maven repos.
http://repo1.maven.org/maven2/__commons-dbcp/commons-dbcp/1.2.__2/commons-dbcp-1.2.2.pom
<http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.2.2/commons-dbcp-1.2.2.pom>
http://jcenter.bintray.com/__commons-dbcp/commons-dbcp/1.2.__2/#commons-dbcp-1.2.2.pom
<http://jcenter.bintray.com/commons-dbcp/commons-dbcp/1.2.2/#commons-dbcp-1.2.2.pom>
Notice how the second one is different then the first. I suspect
the second one must have been autogenerated. In any case though, it
causes a really big problem if that is where the dependency gets
pulled down from.
So, my overall point is, when you're starting from an empty maven
repo, you can definitely get really weird and odd things happening.
It can be really hard to debug. (in the above problem, it
'manifested' as a junit test failure about a missing class!)
---- Cris J H
On 06/13/2014 09:37 AM, Drew Wills wrote:
Folks,
I'm encountering a new Maven dependency issue with echcache. It
seems
to happen always (small sample size) on a machine that
doesn't have
these artifacts cached in the local repo.
These items do seem to be in m2 central. I'm not sure how
Maven is
getting the 'null:ehcache-web:jar:null' (see below) but I
suspect it's a
factor in the issue.
drew
---
BUILD FAILED
/home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:635: The
following
error occurred while executing this line:
/home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1437: The
following
error occurred while executing this line:
/home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1372: The
following
error occurred while executing this line:
/home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1315: The
following
error occurred while executing this line:
/home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1318: The
following
error occurred while executing this line:
/home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1375: The
following
error occurred while executing this line:
/home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1227:
Unable to
resolve artifact: Unable to get dependency information: Unable
to read
the metadata file for artifact
'net.sf.ehcache:ehcache-web:__jar': Cannot
find parent: net.sf.ehcache:ehcache-web-__parent for project:
null:ehcache-web:jar:null for project null:ehcache-web:jar:null
net.sf.ehcache:ehcache-web:__jar:2.0.4
from the specified remote repositories:
central (http://repo1.maven.org/maven2__),
sonatype-nexus-snapshots
(https://oss.sonatype.org/__content/repositories/snapshots
<https://oss.sonatype.org/content/repositories/snapshots>__),
apache-snapshots (http://repository.apache.org/__snapshots
<http://repository.apache.org/snapshots>)
Path to dependency:
1) org.jasig.portal:uportal-war:__war:4.1.0-SNAPSHOT
2)
org.jasig.resourceserver:__resource-server-utils:jar:1.0.__38
--
You are currently subscribed to uportal-dev@lists.ja-sig.org
<mailto:uportal-dev@lists.ja-sig.org> as: eric.ape...@dalquist.org
<mailto:eric.ape...@dalquist.org>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/__display/JSG/uportal-dev
<http://www.ja-sig.org/wiki/display/JSG/uportal-dev>
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
holdo...@unicon.net
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
