Thanks Josh for taking the time to post. I have realised that I had a preconceived idea of what you were trying to achieve when I first read your blog post and that led me to think that you were using Archiva as a local machine mirror of a company wide repository.
I now see that you are using Archiva as a company repository. I have been using Artifactory at my work for exactly the same reasons you have listed, any repository seems to be better than an SCM for distributing versions of projects. My current problem is that as I regularly work from home so I do not always have access to the company repository, so I am looking at solutions that allow me to build in and out of the office. Cheers, -Mike On Mon, Jul 18, 2011 at 3:11 PM, Josh Diehl <[email protected]> wrote: > Hey Mike, I'd be glad to share some of my thinking behind setting up > an Archiva repo. > > Firstly, I was actually experimenting with using Gradle as a > deployment tool when I decided to set up a Maven repo. I have a few > standalone Java web service apps that run from the command line and > use Restlet. Until recently I had been doing a very lazy and > not-at-all scaleable technique for building an executable jar, namely > using Eclipse's UI to create a jar and directory with its > dependencies. I would then manually upload these to a remote server > as needed. My goal was to write a Gradle task that I could use to pull > down the app jar and all its dependencies, since my old method and the > alternative I had tried of using a source control system to store and > serve up all those jars was inefficient. Using Gradle allows me to > take advantage of jar caching, and also to reuse the dependency list > for my build task for the deploy as well. > > So given the goal above, I needed a real repo in order to be access it > from my various test and production environments. As you say though, > if you are a team of one and have no need to access the repo from a > test or prod environment, you are probably better off with a flat repo > (although I did actually set up one on my localhost for development, > probably for no good reason). > > Hope that sheds some light, perhaps once I get the kinks worked out I > will write another post about my deployment task. > > Josh > > @JoshDiehl - joshdiehl.com > > > > On Wed, Jul 13, 2011 at 6:49 PM, Mike Mills <[email protected]> wrote: >> Josh, >> >> Thanks for the post, I have a question that might be worth while answering >> here. >> >> I have been using a flat repo as my local repository for artifacts >> produced by my Gradle projects. Is there something about using Archiva >> locally that has advantages over a flat local repo? >> >> My biggest concerns over using a fully local repo are: >> >> 1, another product to configure for each developer. >> 2, Archiva has known security vulnerabilites (not particularly an >> issue for most developers mind you!) >> >> Knowing your reasons behind why you chose a full maven repo would be >> useful in deciding if this is a good option for myself. >> >> An advantage I can see of using a local repo manager is that if I have >> it installed on a laptop I take to and fro work, I can have a local >> build on my home developer machine that references the laptop's >> repository. >> >> Regards, >> >> -Mike >> >> On Wed, Jul 13, 2011 at 1:34 AM, Josh Diehl <[email protected]> wrote: >>> Hey, I struggled with getting Archiva working as my Gradle repository, >>> I finally figured it out and wrote it up. Here's the link if it's >>> useful to anyone: >>> >>> http://joshdiehl.com/2011/07/11/using-apache-archiva-with-gradle/ >>> >>> Josh Diehl >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
