On Mon, 2008-03-24 at 13:16 -0700, buzzterrier wrote: > Hi Simon, > > Thx for the reply. I did define a custom pom, that declared the > dependencies, e.g. > > common_dependencies.xml > > <?xml version="1.0" encoding="UTF-8"?> > <project xmlns="http://maven.apache.org/POM/4.0.0" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd"> > <modelVersion>4.0.0</modelVersion> > <groupId>com.foo</groupId> > <artifactId>common-dependencies</artifactId> > <packaging>pom</packaging> > <version>1.0</version> > <dependencies> > <dependency> > <groupId>log4j</groupId> > <artifactId>log4j</artifactId> > <version>1.2.12</version> > </dependency> > <dependency> > <groupId>axis</groupId> > <artifactId>axis</artifactId> > <version>1.3</version> > <scope>compile</scope> > </dependency> > ... > > </project> > > but when I deploy this pom to the internal repository the dependencies are > stripped out and I am left with: > > <project> > <modelVersion>4.0.0</modelVersion> > <groupId>com.foo</groupId> > <artifactId>common-dependencies</artifactId> > <packaging>pom</packaging> > <version>1.0</version> > </project> > > If I install the pom to my local repository all the dependency declarations > are still there. I cannot figure out how to install the pom to the internal > repository with the dependency declarations.
I just tried it, and got the same problem: mvn deploy:deploy-file -DgroupId=foo -DartifactId=foo -Dversion=1 -Dpackaging=pom -Dfile=pom.xml -Durl=file:///home/simon/mockm2 Then I added -DgeneratePom=false on the end, and it worked as expected. The generatePom option is true by default, so I think maven is generating a pom for the pom, and overwriting the one just deployed:-). Looks like a JIRA issue is needed for maven-deploy-plugin to ensure generatePom defaults to false when -Dpackaging=pom is specified! > > Also, thx for your insight on why this approach may be problematic. Can you > suggest a more appropriate approach for sharing common libraries across > several projects. For example, all the projects are going to use log4J so it > seems like it should be automatically made available to all of them. I would personally just add log4j as an explicit dependency. If a project uses log4j, then why not add a dependency for it? This then means that poms declare their *real* dependencies, and don't pull in stuff that they don't need. Some people then start worrying about "keeping the version up to date", but I think that's not an issue at all. If a project functions fine with a specific version, then there is no need to keep updating the version - in fact, it's dangerous. And if something else depends on that lib but itself uses log4j, then it will automatically override the version anyway. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]