This is a very valid scenario and one that I need to address before I formally replace our Ant build with Maven. The build currently runs about 600Mb before it's done and will (fairly) quickly exhaust the diskspace on our build machine. Even today, the last thing we do is archive the complete build and move it "offline", to make room for the next one.
What I had thought I might to is to tweak the settings xml so that a single release build went to it's own repository folder structure, say ~/.m2/b20080331-123046. Then the cleanup is a simple rmdir. Does that seem like a plausible answer? Robert Egan "EJ Ciramella" <[EMAIL PROTECTED]> wrote on 03/31/2008 01:29:56 PM: > Pretend for a moment maven will still be in use in 10 years - you > will truly keep around something generated today? > > Additionally, that's just repo1, what about people managing their > own repositories? For organizations managing a live site, a jar > artifact or set of web binaries from a year ago are typically > useless as they have been updated maybe 100 times since the original install. > > -----Original Message----- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Monday, March 31, 2008 12:44 PM > To: Maven Users List > Subject: Re: deleting things out of a repository > > Almost by definition, Maven does not support "undeploy". That would > imply that the repo is not write-once but rather changeable. While > this is acceptable for SNAPSHOTs, it is not acceptable for releases. > > So, I think you'll have to do this manually. I just don't see this > EVER making it into a core Maven plugin, for good reasons. > > Wayne > > On 3/31/08, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > Well, we manage a live site so artifacts released a month ago are > more often than not, useless cruft. > > > > We don't have a snapshot repository (just yet) so that isn't a > problem (just yet). > > > > But I don't want to go in with a sword and start chopping out bits > when there is data about said bits everywhere (in the metadata files). > > > > It'd be great if there was a "mvn undeploy groupId:artifactId: > version" type command. Or if the deploy or release plugins would be > configurable to say, "purge stuf X days old" or something. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Tamás Cservenák > > Sent: Sunday, March 30, 2008 6:23 PM > > To: Maven Users List > > Subject: Re: deleting things out of a repository > > > > And not to mention the "recipe" that remote repo (even those > > "inhouse", locally managed ones [probably hosted by one of MRMs or > > even web server]) should only "advance forward" in time and > > _have_no_artifact_deleted_. > > > > Exception for those are SNAPSHOTs, as Wendy said. > > > > ~t~ > > > > On Sun, Mar 30, 2008 at 10:42 PM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > > > > > On Sun, Mar 30, 2008 at 1:41 PM, EJ Ciramella > <[EMAIL PROTECTED]> wrote: > > > > > > > What's the best way to remove, say, 10 or so old builds out of the > > > > repository (a locally run/managed one)? > > > > > > > > is there a "mvn undeploy" command? > > > > > > Can you explain more about what you're looking for? Are these > > > snapshots or releases? (And is this a remote repository, or > > > ~/.m2/repository?) > > > > > > Two things that come to mind are Apache Archiva's ability to purge > > > snapshots from the repos it manages, and the recent discussions of the > > > need for a tool to keep the local repo size under control. > > > > > > -- > > > Wendy -- This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
