I would expand that a bit to say that there are three types of repos that I think are common for teams using maven:

* the public repos like ibiblio

* a repo that your team maintains for your project or organization (often using the "local repo" part of a "maven-proxy" or "proximity" instance), to serve as a common place to store jars that are neither built as part of your project nor available on public repos (due to license restrictions, etc.). This is a good place to put proprietary db driver libs, weblogic.jar, project-that-does-not-publish-on-ibiblio.jar, etc.

* Your own personal local repo. Don't try to share it. It caches artifacts from the other repos, and it is where jars end up when you 'mvn install' your project.

-Max

Manuel Ledesma wrote:
There cases where jars needs to be taken from there installation directory
otherwise, It won't work. That's the case for weblogic.jar, which will load
jars are need it base of its own path.


Simon Kitching-2 wrote:
On Thu, 2006-03-23 at 04:28 -0800, Richard Sladek wrote:
Thanks for your opinion, it seems to me that I am gonna to abondon the
use of
system scope then.

However, I still think there should be a way how to define dependencies
that
are specific to a certain project only and you do not want to store them
in
a repository. This is maybe because of my bad underastanding of what a
repository is intended to be for: I understand it as a store where I can
place my SHARED /=common/ libraries so that I have a central management
point over them.

For project specific libs, I do not want to have them in a repo as they
are
pretty unlikely to be used in any other project and I don't see a point
to
have a lib in repo just because of one specific project.
Another reason for this might be some kind of encapsulation when I want
to
have all my project-related stuff on one place only (so that I can back
it
up easily, for instance. If local repository was involved, I would have
at
least 2 things to backup: repo and project itself.)

But as I said, this is probably just my bad understanding of things and
ALL
depenendies in Maven /both common and special/ shall be stored in repo.
Any
discussion on this is welcome :)
There are two types of repository:
* "remote" ones, such as ibiblo, or a repo for your development team
* the local repository on your development machine (really a "cache").
  It typically exists in directory ~/.m2

If your project has dependencies on something available from a remote
repository, then declare that as normal; the dependencies will
automatically be downloaded to your local repository.

If your project has dependencies on other projects you've developed,
however, you can simply check those out and run "mvn install" to get the
jar that project generates installed into your *local* repository. That
is much tidier than trying to use "system" scope.

If the local projects you have dependencies on are not built with maven,
then you can take each jar and run a command to install it into your
local repo anyway (a pom is created for it). I can't remember the actual
command for the moment, but it has been discussed on this list in the
last day or two.
If the process of installing jars into a local repo is inconvenient
because there are lots of them, or a development *team* that needs to do
this, then you should look at setting up a real shared repository
instead. A repository is just a webserver or ftpserver; nothing
complicated.

There's really no reason to use "system" scope at all, except for libs
that may vary from machine to machine, eg the "tools.jar" of whatever
the locally installed JDK is.

And there is no need to back up the "local repository"; it is only a
cache of stuff that is already available elsewhere.

Regards,

Simon


---------------------------------------------------------------------
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]

Reply via email to