Maven - Remove unused jars from repository

[Jaikiran Pai]

I have just started using Maven for one of my projects. I am happy with the way dependencies with other libraries can be handled. But within the past one month, since i have started on this project, i already have downloaded a lot of jars in the repository. All these jars are mainly from dependencies that are/were present in the pom. However, majority of these jars in the repository are now old versions (i.e. no longer required in the project). Is there some Maven goal or some other way these unused jars can be cleaned up? How do other users of Maven handle this?

[Peter Johnson]

The only way I know of is to delete the repository and let Maven rebuild it.

The problem with having an automated mechanism to do this is that a pom.xml can specify a dependency on a particular version of an artifact. For example, if you have 4 versions of a particular artifact, the only way you could tell if any of those versions were no longer needed is to look at every pom.xml on your system (this would be a transitive lookup starting from your projects' pom.xml file and going through every pom.xml for every dependency).

But then I could see the benefit in having a script that removes all but the most recent version of each artifact, and if a certain build required an older version, letting Maven reload just that version. Doing this would be better than deleting the entire repository.

(By the way, I have this same issue with Eclipse - after a few months of updates I have over a GB of files in the eclipse directory with no clear way to remove older versions that no longer required.)

[Tim Holloway]

In the land of serious enterprise computing, application source code can sit unreferenced for long periods of time - some COBOL apps have gone for literally years. Then all of the sudden a bug pops up, there comes a demand for a feature, or compliance with some new law has to be added. Or maybe just a machine crashed and the backups (if any) were unusable. Then the app source gets pulled and used to build a new executable.

This is in fact, the primary reason I gave up on developing Microsoft-specific apps. Too many times the older code could only be compiled by using an older IDE and sometimes even you even needed an older OS to run it on. Sun and IBM understand this problem. Microsoft has never seriously tried to address it.

But I digress. The point is, the Maven repository is primarily a cache. So as long as it's not the primary source for a module, you can usually safely mass-delete its contents. Though the inrush to replace the deleted modules for the first few builds is likely to be ferocious.

If you want something less extreme, you could simply delete all modules which haven't been referenced within a given period of time. Most corporations should make that at least 13 months, since some programs are only used at the end of the physical or fiscal years.

Caution

Maven repository components are organized in directories. So when using a last-reference-time, do it for the directory, not the files. Otherwise you could end up with internal cracks in the repository.

[Jaikiran Pai]

Originally posted by Peter Johnson:
The only way I know of is to delete the repository and let Maven rebuild it.

That's a good point and probably the only feasible way to do it.

Originally posted by Peter Johnson:
The problem with having an automated mechanism to do this is that a pom.xml can specify a dependency on a particular version of an artifact. For example, if you have 4 versions of a particular artifact, the only way you could tell if any of those versions were no longer needed is to look at every pom.xml on your system (this would be a transitive lookup starting from your projects' pom.xml file and going through every pom.xml for every dependency).

Maybe, the other way this could have been handled by Maven was to "clean-first-download-next" type of approach. Something like:
- pom.xml has a dependency on artifact "xyz" of version 1.2.4
- Since the download location is standard, Maven could have allowed an configuration to decide whether the download location for "xyz" (within the repository) should be first cleared (of earlier downloads)
- Next download the version 1.2.4

Haven't given much thought as to what issues this might cause.

Originally posted by Tim Holloway:
So as long as it's not the primary source for a module, you can usually safely mass-delete its contents. Though the inrush to replace the deleted modules for the first few builds is likely to be ferocious.

Yes, i remember waiting for around an hour for my first build of this project Most of the time was spent in downloading the jars.

Originally posted by Tim Holloway:
If you want something less extreme, you could simply delete all modules which haven't been referenced within a given period of time. Most corporations should make that at least 13 months, since some programs are only used at the end of the physical or fiscal years.

At this point, i think we are OK with deleting and recreating the entire repository.
[ August 22, 2008: Message edited by: Jaikiran Pai ]

[John Chambers-Malewig]

Just as a thought, you might want to look at the dependency plugin. The purge-local-repository goal might be what you are looking for.

http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html

[Jaikiran Pai]

Originally posted by John Chambers-Malewig:
Just as a thought, you might want to look at the dependency plugin. The purge-local-repository goal might be what you are looking for.

http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html

John,

Thanks for pointing us to this. Going by the documentation, this looks to be what i was looking for. Let me give this a try and see how it goes.