– Problem
In the last couple weeks, I’ve used 3 different “repository” tools (listed in alphabetical order):
- gradle
- ivy
- maven
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.
5
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.
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.
2