Ansgar, I'm not new to building stuff, just new to maven. Unrolling transitive dependencies is old hat for folks who grew up on ant :).
It's more work, but in the end there's no question of what is or is not in your project, and I want to be sure that I only pull the dependencies I actually need, since I will likely wind up filling out an approval form for each of them at some point. Another concern of course is which FOS licenses are being depended upon. Another facet of this is the need to provide a location that can be scanned with a tool that detects GPL'd code, or other such problems. I don't understand your bit about test dependencies. I don't need to run the tests for things I am using. The release engineers for those projects presumably did that already. Note that the only reason I went to the source for the plugin was I couldn't find a binary. -Gus -----Original Message----- From: Ansgar Konermann [mailto:ansgar.konerm...@googlemail.com] Sent: Wednesday, May 18, 2011 6:34 PM To: users@maven.apache.org Subject: Re: Bootstraping a repository manager Am 18.05.2011 23:21, schrieb Heck, Gus (Patrick): > In our company, our > policies make it very important that I know exactly what is going into > the project, so I can't just let maven go slurping things up from > anywhere it feels like on the web. In a network allowed to access the outside world: - clean out your local repository (rm -rf ~/.m2/repository) - run your build - review what's inside your local repository and decide whether that's okay according to your policies The other way round (upload everything which is needed manually) completely thwarts the idea of automatic dependency management. To make it short: this is probably a dead end. The approach you outlined would mean to download and build from source each and every project your build is depending upon. Unless you are a world-class-superhero-build-and-release-manager with a lot of spare time, or your project has only a tiny set of (transitive) dependencies, this probably won't work. I doubt one person can accrue the knowledge required to build all these software modules which get deployed to the central maven repository in a reasonable time. If you don't believe, run mvn dependency:tree on your project, this will give you the dependency tree for compile-time dependencies. Add to this the test-dependencies needed to execute the tests of your compile-time dependencies which happens before packaging (i. e. you won't get a JAR if the tests don't run). If this is not enough to stop you from pursuing your initial approach, add all the maven plugins which make up your build system, and their dependencies. Best regards Ansgar --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
