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
