I recently asked this list about segregating project dependencies based on scope type, i.e. for e.g., ensuring that maven only downloads test dependencies from one repository and other normal dependencies from another repository. I did not get an answer - which can only mean 1 of 3 things:
1. It is a silly question and that everyone is trying to save me the embarrasment by not answering me. 2. It is possible to do this but those who know can't be bothered answering. 3. No-one on this list knows how to do this 4. It is just not possible in maven Now, I am always open to the possibility that point 1 is the correct answer - I have been known to ask stupid questions before and if this is one then it is most definitely not going to be my last. Hopefully, if the answer is 2 then this email will prompt someone to finally answer my tiresome questions just to shut me up. If the answer is 3 then that is quite troubling if no-one in the whole list can answer this question. However, I fear, that the real answer is 4. I work on a commercial product, as such we have to tightly control the kinds of dependencies that developers include in the product - usually for licensing restrictions (the most obvious case is GPL'd libraries). However, on the other hand, there is no such restriction on the build process itself, so, for e.g., we are free to link to GPL'd libraries for our maven plugins, test dependencies, code coverage, quality checks etc - AFAIK there is nothing legally wrong with that. IMHO this is an important and useful use-case for many projects that are interested in tighter control on dependency management. Given that a major part of maven is taking care of dependencies one would think that this use-case would be handled quite easily, wouldn't one? Unfortunately, I am coming close to the conclusion that maven has this fatal flaw when it comes to dependency management; i.e, it is impossible to setup maven to use relaxed dependency control on build/test artifacts while maintaining tight control on the core compile/runtime-scope dependencies of a project. Till a few minutes ago I was coming to the rueful impression that relaxed test-dependencies were probably not solvable but that plugin dependencies are still probably solvable - given that plugins can be configured to use their own dependencies in the pom. However, it turns out even plugins are problematic. Like most other dependencies, plugins have their own transitive dependencies which invariably are not plugin dependencies themselves - maven (rather unhelpfully IMHO) tries to download these dependencies from the normal repository instead of the plugin repository. I have a feeling (happy to be proven to be wrong) that the core maven developers have not really considered this use-case at all. This comment from the maven documentation is what prompts this conclusion: * ".... Because of this, plugin repositories may be separated from other repositories (although, I have yet to hear a convincing argument for doing so)."* (copied from http://maven.apache.org/settings.html#Plugin_Repositories). In other words, this is what I am trying to pose as a useful use-case for a dependency management system: If I have a project with the following compile-time dependencies: C1, C2, C3 and the following test dependencies: T1, T2, T3 and uses the following plugins: P1, P2, P3 then, it should be possible to configure separate repositories that maven would use exclusively for them. If each of those dependencies have dependencies of their own maven should not jump repositories in trying to resolve them. Does anyone else out there agree that this is a sane and desirable thing to have in a build system? Regards, Ishaaq
