Artifactory is pretty good too. There's also archiva. I found this
link comparing them helpful.
http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
I went with Artifactory myself. But Nexus has been around a little
longer and seems more popular with people that don't like to pay for
software. Artifactory does have an open source option which I'm using,
but some of their "cool" features are only in the pay-for-license version.
---- Cris J H
On 06/13/2014 11:21 AM, Eric Dalquist wrote:
Oh right, running a local Nexus instance as a proxy is very valuable.
Being able to always reproduce previous builds and insulating your build
process from external failures is quite valuable.
On Fri, Jun 13, 2014 at 11:09 AM, Cris J Holdorph <[email protected]
<mailto:[email protected]>> wrote:
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#__SonatypeOSSMavenRepositoryUsag__eGuide-6.__CentralSyncRequirement
<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
<[email protected] <mailto:[email protected]>
<mailto:[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://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>
<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__
<http://repo1.maven.org/maven2__>),
sonatype-nexus-snapshots
(https://oss.sonatype.org/____content/repositories/snapshots
<https://oss.sonatype.org/__content/repositories/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>
<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]>
<mailto:[email protected]__sig.org
<mailto:[email protected]>> as:
[email protected] <mailto:[email protected]>
<mailto:eric.apereo@dalquist.__org
<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>
<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]
<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]
<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
