5 ms·

Maybe a misunderstanding. What is the difference between putting a jar as a dependency (pure binary or with sources) or putting its actual content into the pr

by okr 9y ago

Maybe a misunderstanding. What is the difference between putting a jar as a dependency (pure binary or with sources) or putting its actual content into the project, that uses it?

tapirl 9y ago
view/modify/improve the dependency sources at any time, easily.
- okr 9y ago
  Hm. Okay. Interesting idea. I would argue, that it defeats the purpose of a shared library, if you have a branched copy of a dependency with your own patches in your own library project. Plus if you work on, say, 10 libraries at the same time, each having its own branched copy with individual patches, oh well, i wouldnt want to do that manually. You would have to send the patches upstream, so that all other libraries can also profit from it. And you blow up the final jar size. And you get in namespace conflicts (maybe modularization solves it) and so on. Did you mean that?
  - tapirl 9y ago
    Could you share your experiences on how you improve your dependency libraries of your projects?
    - 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

Maybe a misunderstanding. What is the difference between putting a jar as a dependency (pure binary or with sources) or putting its actual content into the project, that uses it?

tapirl 9y ago

view/modify/improve the dependency sources at any time, easily.

okr 9y ago
Hm. Okay. Interesting idea. I would argue, that it defeats the purpose of a shared library, if you have a branched copy of a dependency with your own patches in your own library project. Plus if you work on, say, 10 libraries at the same time, each having its own branched copy with individual patches, oh well, i wouldnt want to do that manually. You would have to send the patches upstream, so that all other libraries can also profit from it. And you blow up the final jar size. And you get in namespace conflicts (maybe modularization solves it) and so on. Did you mean that?
- tapirl 9y ago
  Could you share your experiences on how you improve your dependency libraries of your projects?
  - 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.