As far as I know, the answer is 4. Generally I expect your problem(s) can be solved by setting up multiple environments, each with its own repo manager and liberal use of "rm -rf ~/.m2/repository" (or dependency:purge-local-repository). Then you would specify which repo to connect to with a profile or settings.xml file. Someone will have to take on the job of managing the artifacts in those various repos to meet your exact requirements, of course.
I don't find the "specify which repos may/must contain specific artifacts" use case to be useful for 95% of users. Since this is an open-source tool, the developers are going to spend the majority of their time working on features that target the large population of users (along with their own personal whims), and much less time on things like this. I think people who need to solve this particular problem are solving it with multiple environments and strictly-controlled Maven repos as I've suggested above. Perhaps someone else will chime in with more specifics. Wayne On 6/29/08, Ishaaq Chandy <[EMAIL PROTECTED]> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
