Managing a maven build under these constraints is prohibitively expensive for a small operation if you apply it to maven itself. The thing you are building may have a modest enough dependency collection, but maven itself? I think you are looking an an inventory in the hundreds.
It's a gigantic undertaking. Hmm, maybe someone could make some money selling 'trusted maven' -- a canned repo full of plugins and their deps where the seller takes legal responsibility for license and provenance :-) Again, a question here is provenance versus license. Say that you carefully set up an environment to load dependencies only from central. You run a build. You use the available tools to load the contents of your repo into a repo manager, and you tell everyone else to configure maven to load from that and nowhere else. Now you have provenance settled (if you trust central). Maven doesn't 'load things from anywhere'. It loads things from where you tell it to load things from. By default, that's central, period. Could a rogue developer circumvent? Of course, on their local machine. Can they push unwanted things into your repo? Not if you set the access control properly. Next you have dependency licenses to worry about. Well, even if you converted back to ant, you'd still have dependencies to worry about. At least maven will make you a nice report of the licenses of the dependencies as declared in the pom. With ant, you'd be googling away tracking down the original sources and licenses of all the dependencies. So I don't see how the maven-ness of this thing makes your problem materially harder. It's a big problem either way. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
