Ken, good question. I should be more explicit in the The Definitive Guide about the difference. “install” and “deploy” serve two different purposes in a build. “install” refers to the process of installing an artifact in your local repository. “deploy” refers to the process of deploying an artifact to a remote repository. Example: When I … Read more
Looking at the maven-central repo, you need to specify a classifier for this dependency. Either jdk13 or jdk15, like this: <dependency> <groupId>net.sf.json-lib</groupId> <artifactId>json-lib</artifactId> <version>2.4</version> <classifier>jdk15</classifier> </dependency>
I’m sure that if you only talk about storing binaries from “mvn deploy” both will do fine. We use Artifactory very extensively with all upgrades along the way. Lots of projects, numerous snapshots deployed and external repos proxied. Not a single problem. I find it hard to explain how other people experience issues with its … Read more
With Maven 3.2.1, you can now use -pl !<module_name>,!<module_name> to exclude certain modules from the reactor build. See this feature request: https://issues.apache.org/jira/browse/MNG-5230
Overriding configurations from a parent pom can be done by adding the combine.self=”override” attribute to the element in your pom. Try changing your plugin configuration to: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <executions> <execution> <id>my-testCompile</id> <phase>test-compile</phase> <goals> <goal>testCompile</goal> </goals> <configuration combine.self=”override”> <fork>true</fork> <executable>${jdk15.executable}</executable> <compilerVersion>1.5</compilerVersion> <source>1.5</source> <target>1.5</target> <verbose>true</verbose> </configuration> </execution> </executions> </plugin> For more information on overriding plugins, see: … Read more
Try setting a property in each pom to find the main project directory. In the parent: <properties> <main.basedir>${project.basedir}</main.basedir> </properties> In the children: <properties> <main.basedir>${project.parent.basedir}</main.basedir> </properties> In the grandchildren: <properties> <main.basedir>${project.parent.parent.basedir}</main.basedir> </properties>
The buildplan-maven-plugin is an excellent tool for showing how goals are bound to phases. Below are examples of commands you can run. The commands will automatically download and install the plugin if it hasn’t already been installed. List goals by the order they will execute > mvn fr.jcgay.maven.plugins:buildplan-maven-plugin:list PLUGIN | PHASE | ID | GOAL … Read more
Here’s what’s been working for me: <plugin> <artifactId>exec-maven-plugin</artifactId> <groupId>org.codehaus.mojo</groupId> <executions> <execution><!– Run our version calculation script –> <id>Version Calculation</id> <phase>generate-sources</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>${basedir}/scripts/calculate-version.sh</executable> </configuration> </execution> </executions> </plugin>
Since version 2.1 of the Maven Dependency Plugin, there is a dependency:get goal for this purpose. To make sure you are using the right version of the plugin, you’ll need to use the “fully qualified name”: mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:get \ -DrepoUrl=http://download.java.net/maven/2/ \ -Dartifact=robo-guice:robo-guice:0.4-SNAPSHOT
One trick is to avoid activeByDefault, and instead activate the profile by the absence of a property, eg: <profiles> <profile> <id>firstProfile</id> <activation> <property> <name>!skipFirstProfile</name> </property> </activation> … </profile> </profiles> You should then be able to deactivate the profile with -DskipFirstProfile or with -P !firstProfile, but otherwise the profile will be active. See: Maven: The Complete … Read more