I did it, but Weblogic jar does not work that way, It looks for other
jars in there WL_HOME/server/lib directory, reason why? it needs to be
taken from there.
Wayne Fay wrote:
> We are suggesting that you install the weblogic jar(s) into your
> vendor repo. And stop using system scope...
>
> Wayne
>
> On 10/12/06, Manuel Ledesma <[EMAIL PROTECTED]> wrote:
>>
>> 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]
>>
>>
>
> ---------------------------------------------------------------------
> 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]
