Well, not knowing who else uses maven out there I have no reasonable way to verify or deny your claim that this is not useful for 95%. I can only say that I find it hard to believe that only 5% of maven users would conform to both of the following criteria - but then again, I don't really know:
1. You're writing a commercial app (or any app for that matter which has a potentially incompatible license with some or all of its dependencies, so, for e.g. a BSD app with a GPL dependency). and 2. If said app is supposed to be redistributable (or, in some other way, violate the license agreement with its dependencies). If you are in the unfortunate situation of satisfying both criteria then you only have 3 options w.r.t. implementing your build system with maven: 1. Just continue to use the standard maven dependency system and don't worry about dependencies with incompatible licenses and hope that no lawyer notices. Possibly works for a lot of small projects, not really an option for me - and I'm sure not a practice that Apache or Maven would be officially encouraging. 2. Same as 1 above, but have a post-build manual process to make sure that no incompatible dependencies have crept in. The problem with this approach is that you have to make sure you catch these incompatible dependencies early on else it may be hard to fix your source code after-the-fact. Note also that incompatible dependencies can creep in due to an updated transitive dependency, not just a dependency explicitly listed in your own pom.xml. 3. Lock down your repository completely so that all dependencies will have to be vetted - a bit over the top IMHO - considering that in reality you only need to vet the compile/run-time scope dependencies - and certainly not the test-scope and the plugin dependencies (along with their respective transitive dependencies). As for your solution of setting up multiple environments, I am not sure that it is practical - I have a large multi-project build that I need to be able to run in one go using my continuous build environment. That build not only compiles the projects but also runs tests, check coverage, metrics, publishes site info etc. It would be really hard and cumbersome to have to split this out into multiple environments. In short, I'd have to do this in at least two passes - one pass would compile the build and the second pass would run tests etc. However, even this is problematic as the first pass still requires plugins (for e.g. the Antlr plugin) whose transitive dependencies would leak across into the non-plugin repository (as mentioned in my previous post). Am still happy for someone to tell me I am being an idiot and that this is really simple to setup with maven (that would solve a number of issues for me), but I fear this is not the case. Regards, Ishaaq 2008/6/30 Wayne Fay <[EMAIL PROTECTED]>: > 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] > >
