On Mon, Jun 30, 2008 at 5:10 PM, Ishaaq Chandy <[EMAIL PROTECTED]> wrote: > 2008/7/1 Nigel Magnay <[EMAIL PROTECTED]>: > >> > However, even if you did assume that, it would be easy to work around if >> you >> > enforced a full build from scratch to delete the local repo. As a >> developer >> > you may decide to avoid doing a full build but our continuous integration >> > environment would certainly enforce it and would catch the problem as >> soon >> > as you commit to source control. >> > >> >> No - if Foo is a test dependency in module A, and a compile dependency >> in module B, and A is built earlier than B, the testing of A will >> cause Foo to be downloaded and be in the local repo, ready to be >> compiled as a dependency against B. >> > > ... and the continuous integration environment could go the next step and > clear out the local repo between each module - possibly ugly, but doable.
Well... depends on how you do your builds, I guess. > However, these are just workarounds - if maven had some way to store > scope-context along with the repository these would be a moot-point. > I don't speak for the devs, but I just don't see this happening. Firstly, because there's too many arbitrary "scopes" that you could define that would be equally valid (license, internationalized, snapshot vs. release, 'blessed' releases, black/whitelisted versions.. and on and on). Secondly, because the repo managers are swimming in the opposite direction. They're all aggregating upstream repositories into a unified cache view - a 'I don't care where this dep came from, just gimme' view. My guess is that such adjustments would be viewed as an unnecessary complication. > >> >> The enforcer plugin is almost certainly what you want. There's a >> million and one arbitrary and conflicting rules code shops want to >> impose on their process - codifying it by parsing the (pom) >> definition(s) is the correct thing to do, rather than trying to layer >> multiply faceted selections on top of the repository mechanism. I am >> (slightly) surprised there isn't a dependency black/whitelisting >> enforcer rule - but just because I haven't seen one doesn't mean there >> isn't one out there. > > > On the contrary, I actually do want to codify this with my pom - i.e. I want > to be able to instruct maven via my pom on how to decide which of the > configured repos to use when downloading certain types of dependencies. > > And no, the enforcer plugin can't do what I want - unless I have > misunderstood its documentation. i.e., there is no way that it can stop > developers from adding compile/runtime deps that have not been previously > vetted and yet at the same time allow arbitrary test/plugin deps and their > transitive deps. i.e. a white-list for compile/runtime deps and their > transitive deps and no list for all other deps. They can add them, then the enforcer should fail the build. It's close to some of the other rules (e.g. no snapshots, dependency blacklist); it might just need a custom rule, it might need an extension (e.g. to consider particular scopes). Either way, yours is a use-case that fits entirely within the scope of the enforcer plugin - if it can't be done with a custom rule, my guess would be that you're several orders of magnitude more likely to get the enforcer plugin enhanced as opposed to the core dependency and repository layout mechanism adjusted. And it would be a useful rule to have added, since it might also encourage projects to clean up their <license> sections in the poms. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
