... and lo - I can't even read - http://maven.apache.org/plugins/maven-enforcer-plugin/rules/bannedDependencies.html
On Mon, Jun 30, 2008 at 4:48 PM, Nigel Magnay <[EMAIL PROTECTED]> wrote: >> 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. > > 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. > >> 2008/7/1 Stuart McCulloch <[EMAIL PROTECTED]>: >> >>> 2008/6/30 Ishaaq Chandy <[EMAIL PROTECTED]>: >>> >>> > Well, assuming that a hypothetical implementation of maven only downloads >>> > compile/runtime deps from the repo that we actively control and restrict >>> > access to, wouldn't that be safe enough? I can't think of a scenario >>> where >>> > this would lead to accidents unless someone somehow "accidently" got the >>> > permission to deploy to this restricted repo and then "accidently" >>> deployed >>> > an unvetted artifact to it. Even if you mark something as a compile-scope >>> > dep when it should really have been a test-scope dep you would >>> immediately >>> > hit a problem because then this hypothetical implementation of maven >>> would >>> > abort because the artifact would not be in the vetted repo (even though >>> it >>> > may legitimately exist in the test/plugin repo). >>> > >>> >>> just off the top of my head, here's one possibility: >>> >>> developer A adds test dependency to artifact Foo, which has a restrictive >>> license >>> >>> developer B updates and rebuilds - Foo is downloaded from central to his >>> local repository >>> >>> developer B thinks Foo would be useful in his code and adds compile >>> dependency to it >>> >>> now because Foo is already in his local repository, IIUC Maven won't bother >>> checking >>> the remote repositories and developer B will happily start writing code >>> that >>> uses Foo. >>> >>> Of course, I admit that just because I can't see a way for this to >>> > reasonably "accidently" happen does not mean that it is impossible. >>> > >>> >>> -- >>> Cheers, Stuart >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
