Hi,
Here are some ways it can be done, but certainly other possibilities:
1) If you use our Build Integration plugin for Jenkins, TeamCity or Bamboo
(actually standalone Maven3 works also), you could identify all artifacts
used in builds easily:
http://wiki.jfrog.org/confluence/display/RTF/Build+Integration
In conjunction with the Build navigation REST
API<http://wiki.jfrog.org/confluence/display/RTF/Artifactory%27s+REST+API#Artifactory%27sRESTAPI-BUILDS>,
or a dedicated job as Users
Plugins<http://wiki.jfrog.org/confluence/display/RTF/User+Plugins>(Groovy
scripts executed inside Artifactory) you could automate the process.
2) If you manage to make sure all dependencies are downloaded from
Artifactory when you are building a product version (using a clean private
local repository for Maven), then you can use All Artifacts Not Downloaded
Since<http://wiki.jfrog.org/confluence/display/RTF/Artifactory%27s+REST+API#Artifactory%27sRESTAPI-AllArtifactsNotDownloadedSince>
REST
API to identify old artifacts that are not used for the last 6 months.
Instead of directly deleting them you could move them to a to_be_deleted
local repository that is readable only to admin (security) or not visible
from any virtual repositories used for resolution. And then delete them
after a month of no complaints (from builds and developers).
3) Using Build Integration, you could rebuild product version to deploy only
the build info object, and then using build promotion isolate the product
version and all their real dependencies to a safe local repo that will not
be deleted. Then using method 2 will be faster and safer.
There may be more techniques, so please keep us updated on
your preferred solution,
Fred.
On Tue, May 31, 2011 at 2:23 PM, schroeder <[email protected]>wrote:
> We are using Maven to handle our native builds, their dependencies and
> artifacts. Our typical dependency trees are quite deep and the typical
> artifacts are large (compared with Java artifacts). In addition we have
> several non-snapshot builds per artifact. Alltogether our repository size
> is
> growing very fast (too fast for us).
>
> On the other hand, we only need to store those artifact versions
> permanently
> that are part of a published version of the top level products. Therefore
> we
> want to clean up our repository from time to time. To be able to do this,
> we
> have to know which artifacts (and versions) are not part of any dependency
> tree of any published product version (and that are older than let's say 6
> month).
>
> Has anybody an idea how we can solve this? Or is there already a solution
> for this problem?
>
> Thanks a lot,
> Andreas
>
> --
> View this message in context:
> http://forums.jfrog.org/Cleanup-of-the-Maven-Repository-tp6422462p6422462.html
> Sent from the Artifactory - Users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Artifactory-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>
--
JFrog Ltd
http://www.jfrog.org/
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
