This is a very good point. We utilize similar pom projects of jar clusters for dependencies that we find ourselves using repeatedly in several projects, just to make our lives easier when building new projects and dealing with upgrades of artifacts across multiple projects.
Wayne On 5/25/06, Eric Redmond <[EMAIL PROTECTED]> wrote:
You bring up a very good point, and one I have recently begin using. I have gotten to creating pom projects (they don't have to be parents or multimodule projects, for that matter) for all sorts of jar clusters, specifically, implementations of APIs. For example, our org has yet to land on a JDBC driver implementation. After switching twice, I created a "jdbc" project that contains the required JDBC jars as dependencies (usually just one, in one case three). This way, all of our projects contain that one dependant pom, "jdbc". After they decided to change JDBC implementations again, viola, I switched the "jdbc" dependencies, and all of the projects are automagically updated transitively. Feel free to add that to the much-needed book, "Maven 2 Hacks" :) Eric On 5/25/06, Doug Douglass <[EMAIL PROTECTED]> wrote: > > Well, you'll have to deal with the 20 jars individually when you > install:install-file (or deploy:deploy-file). But don't bother installing > the dctm.jar if it truely is just class path entries (I don't recall back > in > 5.2.x) > > For your projects that use DFC, create a parent pom with the 20 > dependencies > listed there, perhaps also using dependencyManagement. This way you > projects > inherit all the DFC baggage needed. > > OR > > Create a new project of your own with the packaging set to "pom" and those > 20 jars as dependencies. Call it something like groupId "com.documentum", > artifactId "dfc-bundle" or "DocumentumFoundationClasses" as you were > thinking. Then your projects need only declare a dependency on this one > project. > > As bad as it may seem to have to install:install-file 20 jars, in the long > run and with multiple developers, it will save immense amounts of time. > Maven gives you options -- take advantage of them ;) > > -Doug > > On 5/25/06, vdiprenda - optonline <[EMAIL PROTECTED]> wrote: > > > > Thanks Doug, > > > > The problem is the complexity that Documentum adds to the mix. To use > the > > API, they claim you only need to add the > > c:\Program Files\Documentum\dctm.jar and c:\Program > > Files\Documentum\shared\dfc.jar file to your classpath. > > > > Of course the dctm.jar is nothing but a manifest that adds 20 jars or so > > to > > your classpath. That's where the mess really is. > > > > I was hoping that I could add all the jar files individually using the > > install:install-file goal. At that point, keeping in the spirit of > > thinking > > in terms of artifacts instead of jar files is that I would be able to > > reference > > all the jars as a dependency such as: > > > > GroupId=com.documentum ArtifactId=DocumentumFoundationClasses > > versionId=5.3sp2 > > > > If I had to deal with only the 2 jars, I could work with 2 dependencies. > > The > > alternative of dealing with 20 doesn't seem to really accomplish > anything. > > > > > > Vinnie > > > > -----Original Message----- > > From: Doug Douglass [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 25, 2006 2:29 PM > > To: Maven Users List > > Subject: Re: Using mvn install:install-file > > > > > > Ah, good ol' Documentum. I haven't worked with those jars in a while. > > > > Vinnie, each jar is a separate artifact, so each jar must be installed > > separately. You'll want to add -DgeneratePom=true to the mvn command to > > generate a minimal POM and prevent maven from looking for that POM in > > remote > > repositories. Use a groupId like " com.documentum", or have they changed > > there packaging now to com.emc.document!?!??! > > > > FYI, if you're not the only developer in your organization, you'll be > well > > served to create an intranet repository and place the Documentum (and > > other) > > jars there so everyone benefits from your work. In addition, you could > > create a POM-only project to bundle the various Documentum jars so they > > can > > be added to your projects transitively via a single dependency. > > > > -Doug > > > > On 5/25/06, vdiprenda - optonline <[EMAIL PROTECTED]> wrote: > > > > > > I understand the mvn install:install-file should be used for third > party > > > jar > > > files. I'm assuming that things like classes12.jar from oracle would > be > > > something I would have to install to use hibernate if I was in fact, > > > looking > > > to talk to Oracle. I'm assuming that's the intention for the command. > > > > > > What about a third party product that consists of multiple jar files. > > For > > > instance, if I want to use a product like Documentum that has several > > jar > > > files, would this be the way of loading the jars into the repository? > > I'm > > > assuming that the way to look at the dependency is by the GroupId, > > > ArtifactId and the versionId. > > > > > > Should/could the mvn install:install-file command be used to load > > several > > > jars into one dependency? > > > > > > > > > Thanks > > > Vinnie > > > > > > > > > --------------------------------------------------------------------- > > > 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]
