Not that I am needing to do this but in order to further my understanding...
If you create an Uber JAR - then you can end up in classpath hell - as the dependencies aren't correct (it could include common-io 1.2 and you need commons-io 1.3 which is declared transitively) This then means that even though you don't depend on commons-io you need to start adding all transitive dependencies to your pom just incase the app server ships with a different one and the uber jar takes precedence over the transitive dependency. The J2EE container should allow you to override some bits of the provide jars should they not? /James -----Original Message----- From: Stephen Connolly [mailto:[email protected]] Sent: 15 November 2011 08:26 To: Maven Users List Subject: Re: Properties in settings.xml does not work for system scoped dependencies the correct scope for those deps should be provided imho. the problem you have is getting the deps you need, system scope is just a workaround. ideally you would create an uberjar from the geologic jar and just install that into your repo manager. the focus should be on taking a jar and making an uberjar from its manifest classpath... should be easy, then install that uberjar in your repo. forget about identifying which of the 480 odd jars has your dep, when you depend on geologic specific classes, that's what you need. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 15 Nov 2011 03:19, "Stephen Coy" <[email protected]> wrote: > Hi there, > > I've been a maven user since the early 1.0 days and have contributed > patches at various times for the ejb-plugin, ear-plugin and others. > > I've also had the unfortunate experience of having to use WebLogic 10+ > to create useable maven poms for our projects. In fact, when I read > the OP I knew he was talking about Weblogic even though he did not mention it. > > The *only* way I've been able to do this successfully was with a > system scoped dependency on the weblogic.jar. > > This is because weblogic contains a maze of relative manifest class > paths that are truly mind boggling. > > The very first class path entry in weblogic.jar looks like: > > ../../../modules/features/weblogic.server.modules_10.3.5.0.jar > (plus a dozen or more others) > > That modules directory contains 465 (very OSGI looking) jars and sub > directories. Do you really think it's practical to install all of > these into a repository manager? How would you generate the > dependencies for each pom? > > This would not be an issue for any "plain old JEE" application. > However, if you have any need at all for weblogic specific APIs then a > system scoped dependency is the only practical way. Even when you do > figure out which one of those ~500 jars contains your API, you then > need to read it's manifest and pick out its dependencies, and then the > dependencies' dependencies, etc. > > If someone has a simple solution to this then I'd like to hear it too. > Otherwise, *please* restore the system scope functionality. > > > Cheers, > > Steve C > > > On 14/11/2011, at 2:55 AM, Benson Margulies wrote: > > > No possible licensing restriction can prevent you from having your > > own shared repository with nexus or archiva or artifactory and > > pushing whatever you want to it. > > > > For that matter, it's not too hard to write a script that calls > > install:install-file on each of a pile of jar files. You can't do > > this in the reactor and then use the results (AFAIK), but you can > > run this and then run the build. > > > > In other words, anything you can do with system scope you can do > > with less headaches with a repo manager or instal:install-file. > > > > > > On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav <[email protected]> > wrote: > >> 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 <[email protected]> > >> > >>> 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 <[email protected]> > 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" <[email protected]>: > >>>>> > >>>>> 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" <[email protected]> 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 <[email protected]> > >>>>>> > >>>>>>> On 11 November 2011 16:31, Wayne Fay <[email protected]> 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: [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] > >>> > >>> > >> > > > > -------------------------------------------------------------------- > > - 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] > > ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [email protected] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ************************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
