maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wayne Fay <wayne...@gmail.com>
Subject Re: Properties in settings.xml does not work for system scoped dependencies
Date Sat, 12 Nov 2011 04:34:24 GMT
What else do you need? Why not full client + some reasonable (small)
handful of other dependencies?

Wayne

On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav <bengt@rodehav.com> wrote:
> It works but the full client is not enough for us to be able to build our
> application.
>
> Den 11 nov 2011 23:11 skrev "Ryan Connolly" <rynam0@gmail.com>:
>>
>> Does this no longer work?
>> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
>>  On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <bengt@rodehav.com> wrote:
>>
>> > Stephen and Wayne,
>> >
>> > I agree that using system scope is undesirable. However, there is a
> reason
>> > why maven has had this  support - it is needed in real life. In my
> case, I
>> > use Weblogic. When first trying to migrate our old ant based build
> system
>> > to maven, I started out by trying to put the Weblogic jar:s in the maven
>> > repo. It just wasn't doable. They have split the big, all encompassing,
> jar
>> > file from previous versions into hundreds of individual jar files. I
> gave
>> > up after a while. I guess if I could find a tool that could convert all
>> > these jars into one "super jar" then I could put that jar in the maven
>> > repo. I'm not sure that Oracle's licensing rules would allow it though.
>> >
>> > Dropping support like this because you don't think it's the best way to
>> > handle things will not give you a loyal user base. We need to solve
> these
>> > kind of issues somehow. Before you remove support you must provide an
>> > alternate solution. Requiring that hundreds of proprietary jars have to
> be
>> > put in the maven repo (and updated each time we upgrade Weblogic) is
> just
>> > not realistic. I've been searching for a good tool that can traverse the
>> > manifest classpath's and create a single jar from all individual jars.
> Do
>> > you know of any such tool?
>> >
>> > The transitive dependency problem is not exactly the way you describe it
>> > Stephen. I don't need transitive dependencies from a system scoped
>> > dependency but I want the transitive dependencies to work up to the
> system
>> > scoped dependency:
>> >
>> > If A depends on B that depends on S (via a system scoped dependency),
> then
>> > maven should be able to include S on A's build classpath.
>> >
>> > The way maven works right now I tend to agree that system scoped
>> > dependencies are useless. This is because their location must be hard
> coded
>> > in the POM. Naturally system scoped dependencies reside in different
> places
>> > in different environments. In our case it resides where the user has
>> > installed Weblogic.
>> >
>> > /Bengt
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2011/11/11 Stephen Connolly <stephen.alan.connolly@gmail.com>
>> >
>> > > On 11 November 2011 16:31, Wayne Fay <waynefay@gmail.com> wrote:
>> > > >> System scoped dependencies are dead. Ignore their zombie like
> walking
>> > > >> about. Stop fighting maven and just install the jars into a repo
>> > > >
>> > > > I agree, but shouldn't we kill system entirely at some point (I mean
>> > > > in the code) -- if we see a system-scoped dependency, we just fail
> the
>> > > > build with an appropriate error message? It is a dead concept IMO
> and
>> > > > is simply confusing to users who try to use it.
>> > >
>> > > Yes I agree... but lets get 3.0.4 out first ;-)
>> > >
>> > > To answer the OP
>> > >
>> > > Think of it like this, when you specify a "system" scope dependency
>> > > then you are stating that the system is responsible for providing that
>> > > dependency _and_ all its dependencies -> transitive stops at system
>> > >
>> > > Similarly, with provided scope, you are saying that somebody else is
>> > > taking care of providing that dependency at run time, and so therefore
>> > > maven doesn't have to worry about it or its dependencies.
>> > > >
>> > > > Wayne
>> > > >
>> > > >
> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > > > For additional commands, e-mail: users-help@maven.apache.org
>> > > >
>> > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: users-help@maven.apache.org
>> > >
>> > >
>> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message