These approaches both involve resolving each jar as an individual separate dependency, a large amount of manual effort for a couple of reasons. I'd have to specify 50 new dependencies in the POM, and then I'd have to stage these artifacts separately in our internal repository. This jar collection is certified by our internal QA process, although some of them are probably sitting out on Maven central, we're not just going to take whatever comes off a public repository without certifying it first.
So basically what I'm needing to do is specify a single dependency that is composed of 50-something arbitrary jars. I was able to do this in Ivy, I figured Maven would likewise have a way to accomplish this result. > -----Original Message----- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 26, 2008 10:27 AM > To: Maven Users List > Subject: Re: Best practice to represent an arbitrary collection of jars as > a single dependency? > > Just make a project with type pom and specify these dependencies. > Then, depend on this project in your other projects, and it will bring > in those dependencies transitively. > > If you're certain about those versions, you can lock them down with > <version>[1.2.3]</version>. > > Wayne > > On 2/26/08, Brown, Carlton <[EMAIL PROTECTED]> wrote: > > Hi all, newb question here... > > > > Somewhere long ago, an internal dev project started depending on > > foo-corp/lib/**/* of a 3rd-party framework, which ends up being a random > > collection of 50 jars or so. What's the Maven best practice for > > representing a "big bag o' jars" as a single dependency? > > > > I know it would be ideal to resolve our dependency graph with greater > > granularity, but until someone has copious free time to do that, we'd > > need a simple interim solution to move us forward on the Maven track. > > > > Just to make it clear, the repository dir would look something like: > > /foo-corp/bigbagofjars/5.7/ > > > > And it would contain a random selection of goodies such as: > > apache-commons-codec_1.3.jar > > apache-commons-discovery_1.1.jar > > apache-commons-logging_1.1.jar > > axis-jaxrpc_1.1.jar > > axis-saaj_1.1.jar > > axis-wsdl4j_1.1.jar > > axis_1.1.jar > > bsh_1.3.0.jar > > jdom_b8.jar > > junit_3.8.1.jar > > ldapjdk_5.2.jar > > log4j_1.2.8.jar > > oracle_9.2.0.5.jar > > xalan_2.6.0.jar > > xerces-xml-apis_2.6.2.jar > > xerces_2.6.2.jar > > xpp3_min-1.1.3.4.I.jar > > xstream-1.1.3.jar > > > > If I'm missing some obvious best practice, please feel free to point it > > out, this is just the best I've been able to come up with so far. > > > > Thanks in advance... > > > > ----------------------------------------- > > ==================================================== > > This message contains PRIVILEGED and CONFIDENTIAL > > information that is intended only for use by the > > named recipient. If you are not the named recipient, > > any disclosure, dissemination, or action based on > > the contents of this message is prohibited. In such > > case please notify us and destroy and delete all > > copies of this transmission. Thank you. > > ==================================================== > > > > --------------------------------------------------------------------- > > 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]
