I am just using the Free version and although talking about competing
repo managers is discouraged in the form, I am a big fan of the Nexus
approach and would heartily recommend it to anyone who is using Maven
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
<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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
