Open dkager opened 8 years ago
This particular case (slf4j-jdk14) isn't a plugin but a test dependency. But anyway, regardless of what type of dependency but especially for build-time dependencies (which includes plugins and test dependencies), it is important that they are unambiguously defined in order to have deterministic builds. Sometimes it is possible to remove some version declarations because a parent already defines it and that inherited version is fine (what you did in https://github.com/snaekobbi/pipeline-mod-braille/commit/4833336252cbe8609036a9cd6c7c1c170be5393d for example). But sometimes a version needs to be overridden because the managed version is wrong. slf4j-jdk14 is an example of that I believe.
Describing why the managed version is wrong is indeed a good idea. In this slf4j-jdk14 case I think I didn't know why the managed version didn't work.
I haven’t had any issues thus far (which doesn’t say much), but please add stuff back that shouldn’t have been removed. I’m taking the dumb approach of trusting my IDE, so this will definitely not strip every version declaration.
Eclipse gives me a lot of these warnings:
This is not an issue of course, one can ignore this warning. But it brings up the question if we need specific versions of plugins that are either the same as what it found anyway, or that are older without a comment describing why the newer version doesn't work. Can we rely on the 'managed' aspect and let the build system figure it out, e.g. as I've done in the ascii_table branch? The fewer things to keep track of, the better.