It seems to me to be a management problem rather than a technical problem although the technical tools could help the manager identify the problem.
If you inform your developers that they can only use certain libraries and have to check with your (or someone) if they want to use other libraries, you are responsible for verifying that and dealing with it as a manager. You go to them, tell them they broke the rules and apply some deterrent. Perhaps you make them take out the dependency. Perhaps you fire them. All, it seems to me, Maven needs to do is give you the tools to determine whether any unapproved libraries are in use. The dependency report generated for the maven site tells you all the libraries used. You can read it, detect any non-approved libraries and then get back with whomever added it in. Job done. Maven works as is. I know, that's a pain and a lot of tedious work and you have to do it every day. I can imagine a minimal plugin to deal with this that compares all dependencies to a list of approved stuff. You post the list to your repo whenever the lawyers change it. The plugin could kill the build or send you an email or post a report to the maven site or whatever seems right. You still have to make sure nobody hacks the list (or accidentally changes it). And you still have to make sure nobody changes the POM to remove the reference to this lawyer approval plugin. I suspect there are a few more ways to get the check disabled that you would have to guard against. Ultimately, whatever the tools do, its up to the manager. I just don't think the way to solve the problem is by limiting which repo gets used for what. Thanks. -- Lee On Mon, Jun 30, 2008 at 1:08 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > >1. A locked down repo in which only "approved" versions of some deps > exist. > > >2. An open repo which proxied on to maven central. > > This is commonly done where the CI system uses only the approved > versions and the devs are free to use the proxied one. It simply means > that they must be sure that the dependencies are in the approved version > before they commit/merge or obviously the CI will fail (as it should) > > >Note that the process of approving an artifact is not trivial - we need > to > >vet each dep and each transitive dep of said deps - don't really want > to do > >all this rigmarole in the case of test-scope and plugin deps. > > This simply isn't possible at the moment. As you discovered, even the > pluginRepository separation isn't working perfectly because it tries to > find the plugin's deps in a normal repo. Further, the pluginRepository > separation is deprecated in 2.1 because it doesn't really get any > benefit and generally makes a mess of things. > > You have a valid use case here, but it simply hasn't been proposed or > coded. This is something that could be done, but more likely in the 2.2 > timeframe. > > >Even if maven somehow communicated the scope of the artifact it is > >requesting to the repository I could work around this at the repository > >level; i.e., for e.g., the open-proxied repo would reject all requests > for > >compile/runtime dependencies and only allows requests for test and > plugin > >dependencies and their transitive dependencies, but maven swallows up > this > >information before making the call to the repository. > > >Is sending this information along with the call to the repository > difficult? > >I have no idea how maven resolves dependencies so have no idea as to > how > >easy/difficult this is. > > This would require a new wagon implementation to be tightly tied to a > repository manager like Nexus as the current defaults are using regular > http gets and convey no information other than the file they want. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
