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 <holdo...@unicon.net> 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#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: > eric.ape...@dalquist.org > 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
