> 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]
