Yup, you're assuming that maven works as it currently does - i.e. it is unable to remember the context of how the dependency was originally pulled down.
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. 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 >
