As I explained in another response, I want the software to tell me when I've got enough stuff to build (much like test driven development), rather than trusting I covered everything post-hoc. As for doing it with ant projects, I've certainly been there. At one job I wrote a custom ant task that looked at /lib, a properties file and a directory called /licenses. If the jar in lib didn't have an entry in the properties file, or the value for that jar in the properties file didn't match the name of a file in /licenses, the build failed. Not really that hard to implement. As you say, the big time sink is in hunting down the licenses, but in the current job I have to do that anyway to include a copy of the license with the approval form for the lawyers... nothing maven can do about that. The only irritation is that some basic artifacts seem to be hard to find and instead of an answer such as "the artifacts you need can be found here" I get a chorus of "don't do that"
By the way, I am a bit irritated that maven put's the repository information out on the developer's settings.xml. I'd much rather be able to manage that centrally, and not leave it as something that they could screw up, or forget to do after their hard drive fails and the set things up a second time. Is there a way to lock things into a single repository without settings.xml? Malicious circumvention is of course a whole different topic, and would be impossible to prevent without an encrypted form of the pom anyway. -Gus -----Original Message----- From: Benson Margulies [mailto:[email protected]] Sent: Wednesday, May 18, 2011 7:35 PM To: Maven Users List Subject: Re: Bootstraping a repository manager 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] This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify the sender and permanently delete the original copy and any copy of any e-mail, and any printout thereof.
