I want to take a single directory of ~50 jars and specify that as a single dependency.
I'm explicitly trying to avoid specifying them as 50 separate dependencies in a pom file, or breaking them out in 50 different module subdirectories under an internal Archiva repository. It sounded to me as if this is what you were suggesting, quite a bit of work. Perhaps I'm not wording the question correctly, as it seems like this would be a very common situation. > -----Original Message----- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 26, 2008 11:49 AM > To: Maven Users List > Subject: Re: Best practice to represent an arbitrary collection of jars as > a single dependency? > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
