Ron
On 19/05/2011 10:35 AM, Brian Fox wrote:
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 <[email protected]> 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:[email protected]] 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) <[email protected]> wrote:I can't seem to find a place to download something that I can upload directly to artifactory, so Itriedto start with the first plugin that was failing, and build that andseeif 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 checkouthttp://svn.apache.org/repos/asf/maven/plugins/tags/maven-clean-plugin-2.4.1 maven-clean-plugin cd maven-clean-plugin mvn deployHmm... 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: [email protected] For additional commands, e-mail: [email protected]--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
