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 <[email protected]
<mailto:[email protected]>> 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 [email protected]
<mailto:[email protected]> as: [email protected]
<mailto:[email protected]>
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 [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
