Thanks for the advide, I already create a similar layout (application
repo,
vendor repo and public). Back to the case of weblogic, It needs to be
taken
from its installation directoy and I'm having hard time writing
puglins for
it. The workaround that I found it's using the Ant java task to fork and
setting the right classpath for it. But it would be great that system
scope
artifacts could go beyond compile (runtime).
Max Cooper wrote:
>
> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/System-scope-and-transitive-dependencies-tf1326219.html#a6787577
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
