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). 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 On Tue, Apr 5, 2011 at 6:32 PM, Andy Goodspeed <[email protected]>wrote: > Thanks again, Leo. > > I am pretty sure that this jar (db2jcc.jar for AIX DB2 V9) does not have > any dependencies of its own other that the Java SE java.sql package. The > main benefit I am looking for is to stop carrying it around in every project > lib directory that needs to access the database. > > I would like to support disconnected builds so that developers (like me) > can work off-line when needed. My understanding is that if I do a connected > build before having to go off-line my dependencies should be available in > the Gradle cache. If I am correct then repository (un)availability should be > manageable. Having developers set up a local Ivy repository on their laptops > is also a possibility, but that seems redundant with the Gradle cache so I > am not pursuing that unless I learn differently. > > 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. > - 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. > - 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. > > > -Andy > > > *Leonard Axelsson <[email protected]>* > > 04/05/2011 11:37 AM > Please respond to > [email protected] > > To > [email protected] > cc > Subject > Re: [gradle-user] Placing an arbitrary file into Ivy > > > > > You're welcome. > > Check out Nexus from Sonatype, its an open source version of their > Repository manager. I've worked a little with it and it seems okay. There's > also Artifactory from the JFrog guys, but I havent got any experience with > that one. > > To be honest I'm not sure what the best practice is in your case. There's > probably other people on the list with more experience with this kind of > problem, maybe they can answer what the best approach is. > > To me it seems like having to maintain someone else artifact in your local > Repository would mean extra work without getting much benefit. With other > dependencies you can just go in and configure your repository to cache the > dependencies from Maven Central but in the case of a custom artifact that > you do not control yourself you'll either have to set up a project to deploy > to your repository or just deploy it manually when you need to update it. > That might not seem like a big deal, but it will mean that you're software > can't build without the repository available which wouldn't be the case with > all your other dependencies (unless you're on a restricted network, then my > point is kinda moot in the first place). > > Finally, both options should work just fine. You know more about your use > case than I do so you're much better equiped to figuring out the what the > best approach is in your case. > > Regards, > /Leo > -- ------------------------------------------------------- Leonard Axelsson Agical AB Västerlånggatan 79, 2 tr 111 29 Stockholm, SWEDEN Mobile: +46-708-754008 E-mail: [email protected] Blog: http://xlson.com/ Twitter: xlson
