oh - and I should also clarify, the use case is not as you said: "specify which repos may/must contain specific artifacts"
that, I agree, would be overkill, but rather: "specify which repos may/must contain dependencies of a certain scope type (considering plugin as an additional scope-type for the purposes of this discussion)" and additionally: "transitive dependencies must not jump scoped repositories, i.e. a plugin's dependencies cannot be pulled from a compile-scope repo or vice-versa." Regards, Ishaaq 2008/6/30 Ishaaq Chandy <[EMAIL PROTECTED]>: > 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] >> >> >
