Re:[uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
James Wennmacher jwennmacher at unicon.net writes: As background, I found that the issue is with a change to the HTTP client after Maven 2.2 timeframe that doesn't follow HTTP redirects to HTTPS. So any repos that are HTTP may generate a redirect to an HTTPS URL, and Maven poorly interprets that as a response. See the many issues, duplicates, cross-linked issues, etc. athttp://jira.codehaus.org/browse/WAGON- 314http://jira.codehaus.org/browse/MNG-4838 etc. If you can provide the segment of the console output of the build that deals with the artifact, we might be able to find out if there are changes we can make to not use (or fix the use of) the specific repos causing trouble. From Drew's original post, I'm still a proponent of removing the snapshot repos from the build. I am not sure if it would permanently solve the issue though. I'll submit a pull request for it.James Wennmacher - Unicon 480.558.2420 On 06/17/2014 01:08 PM, Joe Novalany wrote: Not sure if this is helpful or not but here's what I found. My POM file located at: C:\Documents and Settings\novalajo\.m2\repository\net\sf\ehcache\ehcache-web- parent\2.0.4\ehcache-web-parent-2.0.4.pom contained the following: html headtitle301 Moved Permanently/title/head body bgcolor=white centerh1301 Moved Permanently/h1/center hrcenternginx/1.4.1/center /body /html I found what I believe it should have contained over at: http://svn.terracotta.org/svn/ehcache/tags/ehcache-web-2.0.4/pom.xml I then copied the XML from the URL above to the POM file on my machine and then the build seem to complete successfully. I'm not sure where in I need to change the location so Maven knows where to look for the correct POM file but it seems the URL has been moved which is causing the build issues. Hope this helps! -- You are currently subscribed to uportal-dev at lists.ja-sig.org as: gcjjud-jasig-dev at m.gmane.orgTo unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev Here ya go: [echo] Artifact 'D:\portal\uPortal\uportal-search-api\target/uportal- search -api-4.1.0-SNAPSHOT.jar' is up-to-date [artifact:install] [INFO] Installing D:\portal\uPortal\uportal-search- api\target \uportal-search-api-4.1.0-SNAPSHOT.jar to C:\Documents and Settings\novalajo\.m2 \repository\org\jasig\portal\uportal-search-api\4.1.0-SNAPSHOT\uportal- search-ap i-4.1.0-SNAPSHOT.jar [artifact:dependencies] [INFO] artifact org.codehaus.woodstox:stax2-api: checkin g for updates from codehaus [artifact:dependencies] [INFO] artifact org.codehaus.woodstox:stax2-api: checkin g for updates from maven [artifact:dependencies] [INFO] artifact org.codehaus.woodstox:stax2-api: checkin g for updates from central [artifact:dependencies] An error has occurred while processing the Maven artifac t tasks. [artifact:dependencies] Diagnosis: [artifact:dependencies] [artifact:dependencies] Unable to resolve artifact: Unable to get dependency inf ormation: 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: nul l:ehcache-web:jar:null for project null:ehcache-web:jar:null [artifact:dependencies] net.sf.ehcache:ehcache-web:jar:2.0.4 [artifact:dependencies] [artifact:dependencies] from the specified remote repositories: [artifact:dependencies] central (http://repo1.maven.org/maven2), [artifact:dependencies] sonatype-nexus-snapshots (https://oss.sonatype.org/con tent/repositories/snapshots), [artifact:dependencies] apache-snapshots (http://repository.apache.org/snapsho ts) [artifact:dependencies] [artifact:dependencies] Path to dependency: [artifact:dependencies] 1) org.jasig.portal:uportal-war:war:4.1.0- SNAPSH OT [artifact:dependencies] 2) org.jasig.resourceserver:resource-server- util s:jar:1.0.38 [artifact:dependencies] [artifact:dependencies] [artifact:dependencies] Not a v4.0.0 POM. for project net.sf.ehcache:ehcache-web -parent at C:\Documents and Settings\novalajo\.m2\repository\net\sf\ehcache\ehca che-web-parent\2.0.4\ehcache-web-parent-2.0.4.pom [artifact:dependencies] BUILD FAILED D:\portal\uPortal\build.xml:140: The following error occurred while executing th is line: D:\portal\uPortal\build.xml:635: The following error occurred while executing th is line: D:\portal\uPortal\build.xml:1437: The following error occurred while executing t his line: D:\portal\uPortal\build.xml:1372: The following error occurred while executing t his line: D:\portal\uPortal\build.xml:1315: The following error occurred while executing t his line: D:\portal\uPortal\build.xml:1318: The following error occurred while executing t his line: D:\portal\uPortal\build.xml:1375: The following error occurred while executing t his line: D:\portal\uPortal\build.xml:1227:
Re:[uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
Any luck fixing this issue? My university has begun investigating an upgrade to 4.1 and it's preventing me from successfully building. Thanks! -- 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
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
On 06/17/2014 09:56 AM, Joe Novalany wrote: Any luck fixing this issue? My university has begun investigating an upgrade to 4.1 and it's preventing me from successfully building. I received some new insights/information this morning that may help me fix it. - https://github.com/Jasig/uPortal/commit/1f415eaecd5edebec40639c4e0198800fed31abb drew -- 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
Re:[uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
Awesome. I'll take a look as well in the meantime. If you find a solution an update here would be greatly appreciated. :) -- 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
Re:[uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
Not sure if this is helpful or not but here's what I found. My POM file located at: C:\Documents and Settings\novalajo\.m2\repository\net\sf\ehcache\ehcache-web-parent\2.0.4\ehcache-web-parent-2.0.4.pom contained the following: html headtitle301 Moved Permanently/title/head body bgcolor=white centerh1301 Moved Permanently/h1/center hrcenternginx/1.4.1/center /body /html I found what I believe it should have contained over at: http://svn.terracotta.org/svn/ehcache/tags/ehcache-web-2.0.4/pom.xml I then copied the XML from the URL above to the POM file on my machine and then the build seem to complete successfully. I'm not sure where in I need to change the location so Maven knows where to look for the correct POM file but it seems the URL has been moved which is causing the build issues. Hope this helps! -- 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
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
As background, I found that the issue is with a change to the HTTP client after Maven 2.2 timeframe that doesn't follow HTTP redirects to HTTPS. So any repos that are HTTP may generate a redirect to an HTTPS URL, and Maven poorly interprets that as a response. See the many issues, duplicates, cross-linked issues, etc. at http://jira.codehaus.org/browse/WAGON-314 http://jira.codehaus.org/browse/MNG-4838 etc. If you can provide the segment of the console output of the build that deals with the artifact, we might be able to find out if there are changes we can make to not use (or fix the use of) the specific repos causing trouble. From Drew's original post, I'm still a proponent of removing the snapshot repos from the build. I am not sure if it would permanently solve the issue though. I'll submit a pull request for it. James Wennmacher - Unicon 480.558.2420 On 06/17/2014 01:08 PM, Joe Novalany wrote: Not sure if this is helpful or not but here's what I found. My POM file located at: C:\Documents and Settings\novalajo\.m2\repository\net\sf\ehcache\ehcache-web-parent\2.0.4\ehcache-web-parent-2.0.4.pom contained the following: html headtitle301 Moved Permanently/title/head body bgcolor=white centerh1301 Moved Permanently/h1/center hrcenternginx/1.4.1/center /body /html I found what I believe it should have contained over at: http://svn.terracotta.org/svn/ehcache/tags/ehcache-web-2.0.4/pom.xml I then copied the XML from the URL above to the POM file on my machine and then the build seem to complete successfully. I'm not sure where in I need to change the location so Maven knows where to look for the correct POM file but it seems the URL has been moved which is causing the build issues. Hope this helps! -- 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
[uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
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), apache-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 as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
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://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), apache-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 as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
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 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://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), apache-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 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
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
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
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
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
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
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
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
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
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
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 holdo...@unicon.net mailto: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#__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 holdo...@unicon.net mailto:holdo...@unicon.net mailto: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
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
I know I asked this one previous time, but I don't recall the answer ... Can we remove from uPortal the snapshot repositories? sonatype-nexus-snapshots (https://oss.sonatype.org/content/repositories/snapshots), apache-snapshots (http://repository.apache.org/snapshots) I don't think we should EVER get a dependency fulfilled from one of these repos, at least in our use cases. Am I missing something? James Wennmacher - Unicon 480.558.2420 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), apache-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 as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
