Last time I went through this I never came all the way to a complete list but I do remember there were lots of jars missing. I guess I'll have to reiterate this again since system scope doesn't seem to be supported anymore.
/Bengt 2011/11/12 Wayne Fay <wayne...@gmail.com> > 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 <be...@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" <ryn...@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" <be...@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.conno...@gmail.com> > >> > > >> > > On 11 November 2011 16:31, Wayne Fay <wayne...@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-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 > >
