5

- Problem

In the last couple weeks, I've used 3 different "repository" tools (listed in alphabetical order):

I'm calling them "repository" tools because I've also used sbt -- which fortunately uses ivy to manage it's cache or local repository.

Each of these tools will create it's own repository. The defaults are:

  • ~/.m2/repository for maven
  • ~/.gradle/cache
  • ~/.ivy2/cache

Why can't they all use the same cache?

- Goal

I'd like to change the world so that all three build tools could use the same cache. I'm looking for advice about issues I'm likely to run into and smart ways to get around them.

By "use the same cache", I do not mean "retrieve from another build tool's cache".

I mean "retrieve from and store in another build tool's cache".

While I could go ahead and submit issues to the three projects, I know from experience (as a developer on an open source project), that if you want something done, you're best off getting it done yourself.

Also, it seems like I need to get all 3 communities on board to some degree.

- Question

What is the recommended approach for getting this kind of thing done? How do I approach the different communities? Do I work on patches for the 3 different projects, or would it be better off to create my own "interface" project that deals with these issues and have the 3 tools interface with that? Is this a standards question that I need to address on that front?

Lastly, if I'm missing something and this is possible (in an globally configurable fashion), then please let me know.

Improve this question
5
  • 2
    You'd like to change the world? Go for it!
    – Florian Margaine
    Sep 22, 2012 at 11:52
  • 2
    You are more or less stating a goal. If you have a question buried in there, I suggest you rewrite your post to make it more explicit.
    – Andres F.
    Sep 22, 2012 at 14:16
  • 6
    xkcd.com/927
    – hugomg
    Sep 22, 2012 at 19:28
  • 1
    why? what's the advantage of these tools using the same cache?
    – Winston Ewert
    Sep 22, 2012 at 20:12
  • The main advantage is disk space: my maven repository is currently 8.2 Gig -- all of which are dependencies I've used in the last 120 days. I was looking at the Hibernate code (among others) recently, which uses Gradle, so that's a bunch of dependencies. Other (similarly large) projects I sometimes work with use Ant. It's annoying to have several multi gig repositories on the same laptop -- and to then know that some and maybe many of those dependencies are duplicated or triplicated. "There must be a better way.."
    – Marco
    Sep 23, 2012 at 22:07

2 Answers 2

Reset to default
3

So the thing to do is politely reach out to the three project leads of the communities in question. Jason Van Zyl from Sonatype (Maven) is certainly the sort of person who will listen to ideas and I'm sure the other project leads are the same. You need to get a social consensus from the three leads that their communities would want to do this.

Assuming you get the social consensus then start an OSS project where the ideas can be prototyped and tried out. Invite members from each community to join this project.

Usual OSS rules will then apply, hopefully the most meritocratic solution will rise to the top and you've helped change the world :-).

If you remember that OSS is mainly a social activity, not a technical one you'll have a chance.

Improve this answer
2
  • terchnical? --- I'm can't seem to come up with a witty comment about that one...
    – Code-Guru
    Sep 23, 2012 at 21:39
  • thx for the catch :-)
    – Martijn Verburg
    Sep 24, 2012 at 7:46
2

I'd go for creating a separate project & interface and then provide patches for each tool.

Having a separate project makes it easier to centralize design decisions for the common format. Providing patches is necessary to show viability and iron out bugs in spec and implementation.

Additionaly, having your cache implementation separate allows even other projects to use the same cache.

Improve this answer
2
  • While true, following this advice closely will very likely lead into n+1 standard problem hinted at by the xkcd-link above. You need social buy-in for this to actually work (i.e. for this to reduce the total numbers of repository-copies in use).
    – Joachim Sauer
    Sep 24, 2012 at 8:19
  • @joachim: Of course. I focused on the technical part of the mplementation. It needs social buy-in to get anywhere.
    – Macke
    Sep 24, 2012 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.