On 4/25/06, Wayne Fay <[EMAIL PROTECTED]> wrote: > > Since you're a paying customer, I'd ask your vendor to set up a Maven > repo protected by HTTPS (or something similar to only allow valid > customers to access it) that you can utilize. Put the onus back on > them to handle the Maven repo with upgrading components etc.
I can try, but I won't hold my breath. ;-) In particular, there's no one way that would make sense for all of their customers to partition the ~5,000 files that are not jars. If this isn't realistic, I'd write a little Perl or Ruby script to > accept a version number and a directory containing the jars, and make > system calls to install each jar in turn into your corporate repo. > When it has finished installing them, it could output a <dependencies> > xml node that you can cut and paste into your project pom.xml files to > pull in all the newly installed modules. (Someone actually sent a Ruby > script to do the first half of this a few weeks ago, check the User > list archive.) Yeah, that's where I figured I'd end up having to go. One thing that's a bit annoying on that front, though, is that I found that when I put a bunch of 'mvn foo' commands in a Windows batch file, only the first one executes, even if that first one is successful. ;-( As for "dependency plugin does not add dependencies"... I'm wondering > where that's coming from... If your third-party jars were "proper" > Maven dependencies, they would each have a pom file describing their > dependencies. So you could include in your pom a dependency on modA, > which has deps on modB, modC; and modC has deps on modD and modE. > Simply by adding the modA dep in your project's pom file, you would > have modA-modE pulled in and used automatically as needed during > compilation, testing, etc. Sorry, that's not what I mean at all. I can use dependency:copy or dependency:unpack to get artifacts from the repo, but as far as I can determine, there is zero relationship between those artifacts and my build dependencies. Certainly anything I obtain that way is not treated as a dependency for build purposes. So I don't understand why they're in a plugin called a 'dependency' plugin. I understand that the '-dependencies' versions of these goals are based on declared dependencies, but that wasn't what I was referring to. Admittedly, I wasn't clear about that. Sorry. -- Martin Cooper Only because you are not creating proper poms for each module, > declaring what specifically is dependent on what else etc, Maven > cannot build a dependency tree to discover these transitive > dependencies. So instead you have to declare every single module > individually in your pom, I guess. This is not a fault of Maven, > rather, it is a failure related to your current usage of the tool. > (imho) > > We use some "commercial toolkit" jars as well, but check them into our > Corporate repo, and just deal with it. Its not that big of a deal for > us. The 1hr work of one person turns into hours saved not emailing > jars around to all the various members of different development teams > to make sure their project lib folders are up to date, dealing with > large quantities of binary files checked into source control, etc. So > for us it is an advantage. > > Wayne > > On 4/25/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 4/24/06, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > > > > It is *strongly* suggested that you do not utilize scope system. This > > > is available for the rare use case which actually requires it. > > > > > > In general, you should add dependencies to your local repo (or a > > > corporate repo, if you are using one) and use <dependency> in the > > > normal manner. > > > > > > So what do people do when they're using commercial libraries that aren't > > just jars? We use a commercial toolkit that comprises just under 5,000 > > files, 40 of which are jar files. Right now, just so that I can use the > > Maven repo, I have to manually deploy each of those jar files to our > > internal repo, adding version numbers, creating group and artifact ids, > etc. > > Then I have to package the other files up as a few zip files that I can > > download using the Maven dependency plugin, and deploy those to the repo > as > > well. This is a painful manual process that needs to be repeated each > time > > we get a new version from the vendor. > > > > Things might be simpler if the dependency plugin actually related to > > dependencies. ;-) What I mean is that, in theory, I could just drop the > > whole 3rd party toolkit into the repo as a zip file, use the dependency > > plugin to grap and explode it, and then reference the jar files in my > POM. > > But doing that would require the use of system scope, because the > dependency > > plugin doesn't actually add dependencies to your build. (Actually, I > really > > don't understand why it's called the 'dependency' plugin, unless I've > missed > > something quite fundamental about it. ;) > > > > Since I can't imagine that using a commercial toolkit could be > considered a > > "rare use case", I'm wondering if I'm missing something rather basic. > What > > are other people doing in similar circumstances? > > > > -- > > Martin Cooper > > > > > > Wayne > > > > > > On 4/24/06, Kristian Nordal <[EMAIL PROTECTED]> wrote: > > > > On 4/24/06, Brandon Goodin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Is it a requirement that i use the remote repository for jars? Is > > > > > there a way to reference jars that are distributed with the code > when > > > > > checked out from the code repository? > > > > > > > > > > > > Take a look at the "system" scope: > > > > > > > > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > > > > > > > > e.g: > > > > <dependency> > > > > <groupId>foo</groupId> > > > > <artifactId>foo</artifactId> > > > > <version>1.0.0</version> > > > > <scope>system</scope> > > > > <systemPath>${basedir}/foo/foo/1.0.0/foo-1.0.0.jar</systemPath> > > > > </dependency> > > > > > > > > -- > > > > Cheers, > > > > Kristian > > > > > > > > > > > > > > > >
