First of all, let me say I'm not a maven hater. If I was working on a java project I'd use it.
1) The problem is that until you lock down the dependencies you can never be sure exactly which versions will be used. When you use bundler it generates a file specifying all of the versions that should be used. This gets checked into your repository so everyone is sharing exactly the same versions. This means you don't get situations where you check some code in and you break the build because the build server has downloaded a newer version of a dependency(used to happen a lot for me).
2) It's true it would be possible to start a "anyone can upload anything" repository. Having seen how well rubygems.org works in this scenario I think the java community should really get one organised. Either by enhancing the central maven repository or replacing it entirely(it's always been damn slow to browse anyway).
3) In my experience Github projects tend to be pretty persistent, if you have any concerns though you can always hit the fork button and depend on that. Having said that, using git dependencies is definitely the plan B option.
>1) The problem is that until you lock down the dependencies you can never be sure exactly which versions will be used. When you use bundler it generates a file specifying all of the versions that should be used. This gets checked into your repository so everyone is sharing exactly the same versions. This means you don't get situations where you check some code in and you break the build because the build server has downloaded a newer version of a dependency(used to happen a lot for me).
So how's this different from using non-snapshot dependencies in maven? You mentioned checking for new versions as an advantage for bundler, but you can do that with a single command in maven.
1) The problem is that until you lock down the dependencies you can never be sure exactly which versions will be used. When you use bundler it generates a file specifying all of the versions that should be used. This gets checked into your repository so everyone is sharing exactly the same versions. This means you don't get situations where you check some code in and you break the build because the build server has downloaded a newer version of a dependency(used to happen a lot for me).
2) It's true it would be possible to start a "anyone can upload anything" repository. Having seen how well rubygems.org works in this scenario I think the java community should really get one organised. Either by enhancing the central maven repository or replacing it entirely(it's always been damn slow to browse anyway).
3) In my experience Github projects tend to be pretty persistent, if you have any concerns though you can always hit the fork button and depend on that. Having said that, using git dependencies is definitely the plan B option.