Hi I think we are doing something similar to what you want on our local web server for those non-publicly-available jars and it is easy and works well. The only difference is we us a "maven" repository instead of an "ivy" one, but for your simple case I don't think you will care. There is a "deploy-file" task built in to maven that will let you put that jdbc jar into the appropriate directory with its associated POM and such files. Gradle doesn't care, and can use a maven repository just as well as an ivy one. Then you just need to add your local web server url as a mavenRepo like:
mavenRepo urls: "http://www.internal.example.com/software/maven2"; Here is a web page with more info, http://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html and with an example: mvn deploy:deploy-file -DgroupId=<group-id> \ -DartifactId=<artifact-id> \ -Dversion=<version> \ -Dpackaging=<type-of-packaging> \ -Dfile=<path-to-file> \ -DrepositoryId=<id-to-map-on-server-section-of-settings.xml> \ -Durl=<url-of-the-repository-to-deploy> So something like: mvn deploy:deploy-file -DgroupId=com.example -DartifactId=myBigJar -Dversion=1.2.3 -Dpackaging=jar -Dfile=myBigJar-1.2.3.jar -DrepositoryId=myLocalM2Repo -Durl=scp:// www.internal.example.com/var/www/html/software/maven2 and if you want to send source as well: mvn deploy:deploy-file -DgroupId=com.example -DartifactId=myBigJar -Dversion=1.2.3 -Dpackaging=jar -Dfile=myBigJar-1.2.3-sources.jar -DrepositoryId=localM2Repo -Durl=scp:// www.internal.example.com/var/www/html/software/maven2 Obviously change all the stufff that is different, and you can use I think file:// if you are actually on the same machine as the repo. Pretty easy, and sure is nice to let gradle pull those jars when it needs them. Doubly nice when you decide to move to the next version of the jar and only have to deploy it and update the build.gradle. Philip On Thu, Apr 7, 2011 at 3:12 AM, Leonard Axelsson <[email protected] > wrote: > I see no reason for not doing the web-server/UrlResolver-thing if you feel > that's all you need. It's simple and should just work. In that case you only > need a way to get the file on the server, either manually or by using ftp or > scp with gradles ant integration which should be fairly simple. > > Ivy is a library/tool for managing dependencies but it's not really an > "enterprise repository manager". Then again it doesn't sounds like you'd > want one now. My suggestion is taking the UrlResolver approach that you seem > to like and try it out for real, see if it works for you and just run with > it until it doesn't. There's really no wrong options as long as you keep it > simple. > > Roughly what you need to do is: > 1. Setup an inhouse server with httpd or something like that > 2. Expose an UrlResolver-comptabile directory strucuture using the server > (As you have already got UrlResolver working I presume you know how to do > this) > 3. Put the jar-file into the directory structure (do this manually to start > with and automate when you find yourself re-doing it) > 4. Add the UrlResolver to your build-scripts > 5. Add the dependency to your build > > As you're planning to use your own webserver as a repo you don't really > need any specific ivy/maven tasks. It should be easy to just do the uploads > using ant.scp or something like that. In the long run it might be worth your > time to look at a "real" repository manager. They have the advantage of > caching all external dependencies which sometines is really really nice. It > will also allow you use the built-in maven plugin for easy deploys of > artifacts to your own central repos. > > Do what feels right to you. You can always change it later :) > > Regards, > /Leo > > On Wed, Apr 6, 2011 at 3:36 PM, Andy Goodspeed <[email protected]>wrote: > >> Thanks for the link! I will definitely keep an eye on that issue. >> >> I'm sorry if I implied it, but I did not have any problem setting up a URL >> resolver for what I could get into Ivy. I just pointed Apache HTTP Server to >> the repo as the root directory and it resolves just fine. >> >> I can find lots of references to using Maven but is there no way to just >> use Ivy as my enterprise repository? I am starting from scratch - since >> attending some of Hans Dockter's sessions at Devnexus a couple weeks back in >> fact - and was hoping to keep things simple as stressed in the pitches. To >> me that seems like Ivy and Gradle, avoiding first hand implementation of >> Maven (and Ant) if possible. Perhaps this is just wishful thinking. It was >> looking good until I ran into this one rogue jar file. >> >> Again, my goal is to put this jar into Ivy referenceable as: >> >> group: 'com.ibm.db2', name: 'db2jcc', version: '9' >> >> Since I am not yet very familiar with repositories and Ivy I guess the Ant >> approach would use the Ivy Ant task "publish". Is that correct? Then my >> artifact pattern would need to include the group (com.ibm.db2) and version >> (9) in the appropriate places? >> >> Sorry for making this so difficult. My denseness factor is not budging >> very much. ;-) >> >> -Andy >> >> >> *Leonard Axelsson <[email protected]>* >> >> 04/06/2011 03:07 AM >> Please respond to >> [email protected] >> >> To >> [email protected] >> cc >> Subject >> Re: [gradle-user] Placing an arbitrary file into Ivy >> >> >> >> >> I took a quick peek at the issue tracker and it would seem that offline >> mode is coming in 1.0-milestone-2 (* >> http://issues.gradle.org/browse/GRADLE-320*<http://issues.gradle.org/browse/GRADLE-320>). >> The request isn't marked as resolved yet tho, so no guarantees. >> >> From what I recall Ivy will after a set of time (I think 24 hours is >> default) check if the dependency has been updated and if it can't get a >> connection at that time the build will fail. I'm not 100% percent sure on >> this and you can probably figure it out yourself. But if that is the case >> you might get problems with offline builds from time to time. >> >> So I think that the options you are presenting are: >> >> - A repository management tool - This is a worthwhile approach, but it >> seems like overkill for addressing this one (for now) file. >> >> Installing a repository management tool on a central server is really easy >> and will provide faster access to your dependecies as the tool will cache >> them for you. You'll have to figure out if its worth it, but its generally a >> no biggie to setup. >> >> >> - A Gradle build for deploying to the repository - This is the >> direction I was headed when I got frustrated and posted here. Any details >> or >> documentation on doing this would be appreciated. >> >> Take a look at the maven plugin if you use the repository. Or perhaps just >> do it manully using ant tasks. The ant integration in gradle is stellar. >> >> >> - A manual deployment - This is a direction I am willing to take too >> but got similarly frustrated trying to figure this out. Again, any details >> or documentation would be appreciated. >> >> The URL resolver should be pretty easy to setup, what kinds of problems >> did you have with it? You could just put the dep somewhere on your dev >> computer, outside of the project structure and depend on the jar being >> there. Perhaps even adding a custom task that checks for the file and >> downloads it from the internet if its not there. That would provide a >> seamless (albeit somewhat hacky) and offline compatbile solution. >> >> Regards, >> /Leo >> > > > > -- > > ------------------------------------------------------- > Leonard Axelsson > Agical AB > > Blog: http://xlson.com/ > Twitter: xlson > > >
