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
