It's also worth mentioning that Nexus Professional's Procurement feature is built for exactly the use case you have. It's meant to have a hard firewall like separation between internal and external artifacts and rules that allow you to approve whitelist/blacklist style, or by wildcard or other runtime evaluation to define what can be used internally.
On Thu, May 19, 2011 at 9:24 AM, Ron Wheeler <rwhee...@artifact-software.com> wrote: > If you followed my directions or Wendy's, you will have a repo that contains > only the dependencies (artifact and exact versions) that your software > requires and nothing else. > I don't know Artifactory but I do use Nexus so you will have to translate my > instructions. > > In Nexus, you can see each of the artifacts that you have requested and > extract the license information. > If you start at the top of the list and work your way down in order, you > will not miss anything unless you skip one by mistake. Keep a spreadsheet as > a checklist if you worry about that. > > A bit of a PITA but not as bad as you are envisioning. > > You will also see where you are using more than one version of an artifact > so you can limit the dependencies that you may want to clean up. > > Ron > > > > On 19/05/2011 3:23 AM, Nicola Musatti wrote: >> >> Once you had Maven collect all the dependencies for you you can use >> something like >> >> find repository_storage_root -name '*.jar' >> >> if you are on Linux/UNIX or Windows's search tool to obtain a list of all >> your dependencies. With that you can use something like >> http://mvnrepository.com/ to gather information about each jar and make your >> decisions. This would take you a lot less than your approach. >> >> Cheers, >> Nicola Musatti >> >> Heck, Gus (Patrick) wrote: >>> >>> Hi Wendy, >>> >>> I don't have a requirement to build from source, but in the case of the >>> maven plugins, nowhere on the web seems to point to a place where I can >>> download the finished product (aside from letting maven find it, and who >>> knows what other dependencies). I am adverse to letting maven just pull >>> things because then I have a very long list of items to check and verify >>> arranged in a tree, and it's all too easy to miss a subtree and think >>> I've got everything covered. Basically the problem is I make a really >>> crappy computer when it comes to tree-traversals and not losing my place >>> when someone comes over to chat, I go to lunch, or I have to go home at >>> the end of the day. :-) I don't want to trust that I won't make a >>> mistake, I'd rather take a bit more time and let the build system ensure >>> that I didn't miss anything. >>> >>> If I act as gatekeeper, I know that the project won't build properly >>> until I've applied each dependency required to build the project. (and >>> then same for test... etc). This shouldn't be any more burdensome than >>> finding the transitive dependencies for a good sized ant project, which >>> I've done many times before, except that maven plug-in folks seem to >>> squirrel their stuff away where only maven can find it, so I'm having >>> trouble getting maven working to start with. >>> >>> -Gus >>> >>> -----Original Message----- >>> From: Wendy Smoak [mailto:wsm...@gmail.com] >>> Sent: Wednesday, May 18, 2011 6:35 PM >>> To: Maven Users List >>> Subject: Re: Bootstraping a repository manager >>> >>> On Wed, May 18, 2011 at 5:21 PM, Heck, Gus (Patrick) >>> <gus.h...@aspentech.com> wrote: >>>> >>>> I can't seem to find a place to >>>> download something that I can upload directly to artifactory, so I >>> >>> tried >>>> >>>> to start with the first plugin that was failing, and build that and >>> >>> see >>>> >>>> if mvn deploy would deploy it to artifactory. (First, question... is >>>> that a reasonable idea?) >>> >>> That would be: http://repo1.maven.org/maven2 >>> >>> However it is not going to be fun to find each thing you need and >>> upload it to your internal repository manager. (I work with a company >>> that does it this way.) Especially for plugins. Is there any middle >>> ground? Let the repository manager proxy into a segregated directory, >>> vet everything in there and then move it to the pristine internal >>> repo? >>> >>>> Unfortunately, as soon as I did >>>> >>>> svn checkout >>>> >>> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-clean-plugin-2. >>>> >>>> 4.1 maven-clean-plugin >>>> cd maven-clean-plugin >>>> mvn deploy >>> >>> Hmm... first, do you *really* have a requirement to build everything >>> from source? >>> >> >> >> Chi riceve il presente messaggio e' tenuto a verificare se lo stesso non >> gli >> sia pervenuto per errore. In tal caso e' pregato di avvisare >> immediatamente >> il mittente e, tenuto conto delle responsabilita' connesse all'indebito >> utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso >> contenute, voglia cancellare l'originale e distruggere le varie copie o >> stampe. >> >> The receiver of this message is required to check if he/she has received >> it >> erroneously. If so, the receiver is requested to immediately inform the >> sender and - in consideration of the responsibilities arising from undue >> use >> and/or disclosure of the message and/or the information contained therein >> - >> destroy the original message and any copy or printout thereof. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
