If a dependency is only used for building, such as an annotation processor, it should be a maven <plugin>, or <dependency> thereof. Otherwise, if it is in the compilation classpath, it will be necessary for linking the generated class file at runtime. Then, there are two cases: It is always necessary to load that class … Read more
I would suggest to use http://search.maven.org
I had a similar requirement to run some plugins in the child but not the parent POM. i achieved this by stating <skip>true</skip> in the parent POM. the parent pom entry is below <plugin> <groupId>eviware</groupId> <artifactId>maven-soapui-plugin</artifactId> <version>4.0.0</version> <inherited>false</inherited> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.8.2</version> </dependency> </dependencies> <configuration> <skip>true</skip> </configuration> </plugin> The child project pom entry is … Read more
The javadocs for NoSuchMethodError say, Normally, this error is caught by the compiler; this error can only occur at run time if the definition of a class has incompatibly changed. So this is probably being caused by incompatible versions of slf4j being loaded. Rather than looking at your classpath and guessing where classes are loaded, … Read more
If you use a BOM which is used by scope import which means only to take into account the dependencyManagement part. Excerpt from the docs: This scope is only used on a dependency of type pom in the section. It indicates that the specified POM should be replaced with the dependencies in that POM’s section. … Read more
Create a pom-only (<packaging>pom</packaging>) project that has the compiler settings (and any other default settings) you want. You give treat it like any other project (release it; deploy it to your Maven repo, etc.). Put a parent declaration at the top of your pom files: <parent> <groupId><!– parent’s group id –></groupId> <artifactId><!– parent’s artifact id … Read more
Edit, complete rewrite, as i understand the question now. See this forum post: profile activation is based on SYSTEM properties. you cannot activate profiles based on properties defined in your pom you cannot activate profiles based on system properties defined after the build plan has started execution
I hope you have good reason not to follow the standard directory layout, otherwise consider to rearrange the folders: it will make your life a lot easier (as well as for your co-workers). My guess is that nothing has been compiled. In that case: removing the configuration of the maven-compiler-plugin should be enough.
Define a dummy SCM and then use buildNumber item to get sequential build number instead of value defined by revisionOnScmFailure property. pom.xml: <project …> <scm> <connection>scm:svn:http://127.0.0.1/dummy</connection> <developerConnection>scm:svn:https://127.0.0.1/dummy</developerConnection> <tag>HEAD</tag> <url>http://127.0.0.1/dummy</url> </scm> <build> <plugins> … <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>buildnumber-maven-plugin</artifactId> <version>1.1</version> <executions> <execution> <id>buildnumber</id> <phase>validate</phase> <goals> <goal>create</goal> </goals> </execution> </executions> <configuration> <format>{0,number}</format> <items> <item>buildNumber</item> </items> <doCheck>false</doCheck> <doUpdate>false</doUpdate> <revisionOnScmFailure>unknownbuild</revisionOnScmFailure> </configuration> … Read more