I guess we don't understand what you want/need, as it sounds a lot like what we're suggesting. You can manage the artifacts themselves by using Archiva etc rather than asking Maven to download direct from the Internet.
An alternative is to unzip each jar into a shared directory and then re-jar all of it. But I don't know if that would actually work due to log4j.xml collisions etc. Wayne On 2/26/08, Brown, Carlton <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
