3 ms·

If i own the code of a library, then i have a git repository. I have a build server and i always publish the binary and the source jar to an artifact repository

by okr 9y ago

If i own the code of a library, then i have a git repository. I have a build server and i always publish the binary and the source jar to an artifact repository. Now, when i use this library, my IDE knows how to lookup the source jar, so i can always browse the source code. When i see a bug or need a feature, i go to the repository, patch the code and release a new version of that library. And then i bump up the version number of that library in my own project as well. If i do not own the code, then i ask for a change with a patch (in best case). And use a workaround in the meantime in my project. Earlier or later the updated version of thr library has been shipped (maven repo) and i bump version number as well and remove my patch. And worst case: owner does not want to change, well, then i fork the code and add it myself, tag the library, release it to my artifact repository and so on. But i barely do that. In any way, it all relates to my artifact repository (which proxies through official repos such as maven repo) and dependency management from maven, gradle, ant, and so on. How do you do it?

tapirl 9y ago
My Go way is similar but I don't maintain such artifact repository things. I directly fork the dependency project on github (or elsewhere), then change the dependency path from something like "others.com/projects/foo" to "github.com/myaccount/foo". But the fork will only be made if I have confirmed the fork is worthy to make. Before the potential fork, I temporarily modify the code in the local clone of "others.com/projects/foo" directly. If I find my modifications are useless, I will revert the modifications so no forks will be made. Other processes are like what you described. Yes, there is still not a perfect dependency management tool in Go world, but there is one official dependency management tool in developing, which will be released alongside with Go 1.10.

by okr 9y ago

tapirl 9y ago

My Go way is similar but I don't maintain such artifact repository things. I directly fork the dependency project on github (or elsewhere), then change the dependency path from something like "others.com/projects/foo" to "github.com/myaccount/foo". But the fork will only be made if I have confirmed the fork is worthy to make. Before the potential fork, I temporarily modify the code in the local clone of "others.com/projects/foo" directly. If I find my modifications are useless, I will revert the modifications so no forks will be made. Other processes are like what you described. Yes, there is still not a perfect dependency management tool in Go world, but there is one official dependency management tool in developing, which will be released alongside with Go 1.10.