Develop Reference

Classes in test package not available at compile time in IntelliJ

I have a setup like the following:
Where I have two modules: modulea and moduleb, in this case, moduleb has a dependency to modulea defined as:
<dependency>
<groupId>org.example</groupId>
<artifactId>module-a</artifactId>
<version>1.0-SNAPSHOT</version>
<type>test-jar</type>
</dependency>
This allows me to use ClassInTestA in ClassInSourceB without any issues while developing:
However, when I try to build the project, this error prevents IntelliJ to complete the build:
I have come across similar questions in SO:
Question 1
Question 2
Question 3
However, none of the proposed solutions has been able to help my case. I have created an MVCE that is available here as zip and in GitHub.
The real-world project I'm working is neo4j, which follows this structure. Moreover, compilations using mvn install/package work without any issue, the problem appears when working inside IntelliJ.

In general, it makes sense to "open" a new project by building it first outside of IntelliJ with mvn clean package and then import it by just "open"ing the parent module. This worked for me:
And even after a rebuild:
If you don't want to reimport your project by deleting all IDEA folders and files and use the described way above, you can try to build the project via the Maven toolbar (clean and package on the parent module) and then use the "Reimport all Maven projects" button:
At least sometimes this works for me, but honestly not always.

Test classes aren't packed in the final artifact. To share the test classes you'll have to use the jar maven-jar-plugin in modulea:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
and add a dependency in moduleb's pom.xml:
<dependency>
<groupId>org.example</groupId>
<artifactId>module-a</artifactId>
<version>1.0-SNAPSHOT</version>
<classifier>tests</classifier>
</dependency>

Test sources are not included during the compile phase
See Apache Maven Compiler Plugin:
compiler:compile is bound to the compile phase and is used to compile
the main source files.
I think main sources should not depend on test sources. Test sources are only for testing the main sources. You could place ClassInTestA under module-a/src/main/java.

Issues with Maven In Eclipse

Am newbie in Maven and trying to build my first app with Maven using the latest version of Eclipse. After right-clicking the pom.xml file choosing Run-As and Maven Build, i get a window with the title "Edit Configuration and Launch". This window has 3 text areas "Goals","Profiles","User settings".
My question is what should i enter into these text areas to run my application successfully?
Thank you
EDIT
My application is a simple console application in Eclipse so i just want the output from the Main class to appear on the console.

Depending on your project, goals can be one of the life cycle phases phases to achieve.
To start with you can use "install" or "compile". The other two can be left empty for now.

We can attach maven-antrun-plugin:run goal to test phase. This will allow us to echo text messages for different profiles. We will be using pom.xml to define different profiles and will activate profile at command console using maven command.
Assume, we've created following pom.xml in C:\MVN\project folder.
<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.companyname.projectgroup</groupId>
<artifactId>project</artifactId>
<version>1.0</version>
<profiles>
<profile>
<id>test</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>Using env.test.properties</echo>
<copy file="src/main/resources/env.test.properties" tofile
="${project.build.outputDirectory}/env.properties"/>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
And assume, we've created following properties file in C:\MVN\project\src\resources folder.
env.properties
environment=debug env.test.properties
environment=test env.prod.properties
environment=prod
Now open command console, go to the folder containing pom.xml and execute the following mvn command. Pass the profile name as argument using -P option.
C:\MVN\project>mvn test -Ptest
For better clarification: http://www.tutorialspoint.com/maven/maven_build_profiles.htm

To expand on the previous answer, I would most often use 2 goals: clean install or clean compile
The clean remove all files generated by the previous build.
The install will run phases 1-7 below which copies the resulting jar into your local maven repository (usually a .m2 directory in your home directory) so that it is available and can be referenced as a dependency to other maven projects.
The compile will only run phase 1-2 below which compiles your code, but stops before running any configured tests.
Other options are copied from the Maven site below for convenience.
A Build Lifecycle is Made Up of Phases
Each of these build lifecycles is defined by a different list of build
phases, wherein a build phase represents a stage in the lifecycle.
For example, the default lifecycle comprises of the following phases
(for a complete list of the lifecycle phases, refer to the Lifecycle
Reference):
validate - validate the project is correct and all necessary
information is available
compile - compile the source code of the
project
test - test the compiled source code using a suitable unit
testing framework. These tests should not require the code be
packaged or deployed
package - take the compiled code and package it
in its distributable format, such as a JAR.
integration-test - process and deploy the package if necessary into an environment where integration tests can be run
verify - run any checks to verify
the package is valid and meets quality criteria
install - install
the package into the local repository, for use as a dependency in
other projects locally
deploy - done in an integration or release
environment, copies the final package to the remote repository for
sharing with other developers and projects.

Increment version in every Jenkin's build and update dependencies

I have a number of Maven projects being built my Jenkins server. These projects have dependencies on each other, e.g.
service-base -> java-base -> pom-base
In other words, the Maven project service-base depends on the Maven project java-base. Naturally, my POM files look like this:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>my.com</groupId>
<artifactId>service-base</artifactId>
<dependencies>
<dependency>
<groupId>my.com</groupId>
<artifactId>java-base</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</project>
The issue is that none of my Maven projects have "releases" per-se, since I'm using continuous integration to release my changes. Currently, I allow artifact overwriting in my Maven repo and keep all of my versions at 1.0.0. This is because I release my packages many times a day and changing the versions in all the POM files each time I submit a new package version.
Ideally, what I would like is for Jenkins to generate a new version, e.g. 1.0.{BUILD_NUMBER} and then for it update the dependencies all the way up the dependency tree.
Question: Is this possible? Or does anyone have any other solutions to versioning?

Here is how I achieved the same, using Maven profiles, Maven classifiers and Jenkins parametrized builds.
You can define a jenkins profile (or whatever name you prefer) in the pom of the concerned projects. This profile will not be active by default, so your local builds will keep on working as usual. However, this profile will be activated on the Jenkins builds (via the -Pjenkins option on the Maven execution).
How this profile look like in the project at the top of the hierarchy:
<profiles>
<profile>
<id>jenkins</id>
<properties>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<packaging>${project.packaging}</packaging>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>generate-default-version</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>${BUILD_NUMBER}</classifier>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>install-default-version</id>
<phase>install</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<file>${project.build.directory}/${project.build.finalName}-${BUILD_NUMBER}.${project.packaging}</file>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
What is the profile doing?
We are using the Maven Jar Plugin to generate on the package phase yet another artefact for the same project, so the project will create the normal jar plus another jar having as classifier the BUILD_NUMBER (i.e. myproject-1.0.jar and myproject-1.0-4567.jar)
We are also using the Maven Install Plugin to install the additional artefact (the myproject-1.0-4567.jar) into the local Maven cache (so it will be visible to other dependent projects)
We need to define some properties for the Install Plugin, otherwise the install-file will not work
Hence, when on your Jenkins build you will execute the following:
mvn clean install -Pjenkins -DBUILD_NUMBER=${BUILD_NUMBER}
Jenkins will actually pass its BUILD_NUMBER to Maven, which will use it as defined in the jenkins profile and create (and install) an additional artefact for us using it as classifier.
Fine, now we have a dynamically created artefact using the Jenkins build number and available for other projects/builds.
But how other projects can use it?
We define in the dependent projects another profile (or again called jenkins for coherency) and re-define the dependency we now need at runtime:
<profiles>
<profile>
<id>jenkins</id>
<dependencies>
<dependency>
<groupId>com.sample</groupId>
<artifactId>test</artifactId>
<version>1.1.0</version>
<classifier>${BUILD_NUMBER}</classifier>
</dependency>
</dependencies>
</profile>
</profiles>
Note: we are actually overriding as part of the profile a dependency and saying we want that specific classifier for it. Which classifier? The BUILD_NUMBER classifier, which will be available in the local Maven cache of the Jenkins server because installed by the previous build.
But how can the dependent build know which build number and as such which classifier to use, dynamically?
Using Jenkins parametrized builds and the Jenkins Parametrized Trigger plugin.
So, to summarize:
Provider project defines the profile to create additional classifier
Consumer project defines the profile to use as dependency a specific classifier
If a project is Provider for others and Consumer of others, it can then merge the two approaches above in the same profile
The first Jenkins build activates this specific profile and pass to Maven its build number
The downstream Jenkins builds are triggered by the first, which is passing them its build number via the Parametrized Plugin
Each downstream build would then resolve the classifier specified by the parameter and, if required, also create yet another classifier for its own build (according to its profile)
Using this approach, you local builds will keep on working as usual and no classifier would be used, while Jenkins builds would use an additional classifier used across them.

Is there a Maven plugin that runs a non-fat jar?

Imagine a normal java maven project with a Main class that produces the artifact project-a.jar. This project has a dependency on project-b.jar.
Is there a Maven plugin that allows to run that jar by a command like that?
mvn run-plugin:run org.mygroup:project-a:3.1 <args>
The plugin would resolve the runtime dependencies (using META-INF/maven/(...)/pom.xml), install the project and its dependencies to the local maven repository (if not already there), construct the classpath and invoke
java -cp (...)/project-a-3.1.jar;(...)/project-b-2.1.jar org.mygroup.Main <args>
I know that the usual way is to build an executable (fat) jar that contains the dependencies, but that's not what I am asking for.
Actually, it is not even necesary to read the pom from the jar, because maven can download it from the repositories given the coordinates.
Why this question is different to the Maven Run Project question:
I do not want to start from having the project's source already checked out. So the usual use of the exec plugin is not applicable. The OP of the Maven Run Project question obviously assumed the presence of a source code project folder. Her purpose was testing and she accepted an answer that clearly needs a project. The wording of both questions is correct, too. There is a difference between the words "project" and "jar" and their actual meaning in their respective contexts is quite different.

You can use the appassembler-maven-plugin plugin, it creates a shell script that has the dependencies in the classpath for you. Heres an example config
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>appassembler-maven-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>assemble</goal>
</goals>
</execution>
</executions>
<configuration>
<extraJvmArguments>-Xms256m -Xmx1536m</extraJvmArguments>
<programs>
<program>
<mainClass>com.package.MyMainClass</mainClass>
<name>TestFormattingUtils</name>
</program>
</programs>
</configuration>
</plugin>
You can find the output script in .../target/appassembler/bin You can manually inspect the script and you'll see that its doing the type of command you wanted where it adds the jars to classpath via the command line. ie java -jar (...)/project-a-3.1.jar -cp (...)/project-b-2.1.jar <args>

I'm not a fan of jars-in-jar either, but I do maintain various tools with lots of dependencies. So, at one point, I decided to write an executable AppBoot jar which puts all the jars from a lib-subdirectory in a class-loader and then calls the main-method of the desired (executable) jar. This question prompted me to investigate if the exec-maven-plugin could do something similar, and it can.
The exec-maven-plugin does not require a "Java project" directory, but a pom.xml in a directory is required. The pom.xml I used is shown below, note that it can be placed in any (empty) directory and the application can be started by opening a shell/prompt in that directory and executing mvn exec:exec. Use mvn -X exec:exec to review the classpath used by the exec-maven-plugin.
<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.descartes</groupId>
<artifactId>exec-embed-demo</artifactId>
<version>1.2.2-SNAPSHOT</version>
<packaging>pom</packaging>
<!-- Start the demo using Maven repository artifacts, execute with "mvn exec:exec" -->
<properties>
<demo.version>1.2.1.GH</demo.version>
<mainclass>com.descartes.basicjsp.embed.demo.Launch</mainclass>
<appname>${project.artifactId}</appname>
<homedir>${project.basedir}/</homedir>
</properties>
<dependencies>
<dependency>
<!-- exec-maven-plugin will get all required (runtime) jar-files from this dependency. -->
<groupId>com.descartes</groupId>
<artifactId>basic-jsp-embed-demo</artifactId>
<version>${demo.version}</version>
</dependency>
</dependencies>
<build>
<!-- The "outputDirectory" is added to the classpath by the exec-maven-plugin. -->
<!-- Add this pom's directory to the classpath instead of "./target/classes". -->
<!-- The directory should contain "logback.xml" to prevent a million lines of debug output from Tomcat. -->
<outputDirectory>${homedir}</outputDirectory>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<!-- mvn exec:exec configuration -->
<!-- Embedded Tomcat will not stop with "ctrl-c" -->
<!-- Use http://localhost:8080/shutdown instead -->
<configuration>
<executable>java</executable>
<arguments>
<argument>-Dapp.name=${appname}</argument>
<argument>-Dapp.home.dir=${homedir}</argument>
<argument>-Dapp.conf.dir=${homedir}</argument>
<argument>-cp</argument>
<classpath/>
<argument>${mainclass}</argument>
</arguments>
</configuration>
<!-- mvn exec:java configuration -->
<!-- "ctrl-c" stops Tomcat but embedded Tomcat fails to start properly, probably a classloader issue. -->
<!--
<configuration>
<mainClass>${mainclass}</mainClass>
<systemProperties>
<systemProperty>
<key>app.name</key>
<value>${appname}</value>
</systemProperty>
<systemProperty>
<key>app.home.dir</key>
<value>${homedir}/</value>
</systemProperty>
<systemProperty>
<key>app.conf.dir</key>
<value>${homedir}/</value>
</systemProperty>
</systemProperties>
</configuration>
-->
</plugin>
</plugins>
</build>
</project>
AppBoot is part of the basic-jsp-embed project that uses embedded Tomcat and that project can be found here (to install, download the latest release, unpack the zip-file and run "mvn install" in the root directory of the multi-module project).
On a side-note: managing a jar-set is tricky, use tools like jHades to verify you will not run into trouble with multiple versions of the same class in different jar-files.

You are looking for the maven exec plugin.
mvn exec:java -Dexec.mainClass="com.example.Main" [-Dexec.args="argument1"]
would run your program

Maven can not do what you want, simply because it has no way to resolve the dependencies of project A once it has been built into a final jar.
Maven does not magically download libraries from the Internet: what makes it work are the definition of repositories inside the pom.xml. Without pom.xml, like you seem to suggest, how would it know where to download libraries from? Maven is not a downloading tool, it is a project management tool and what you have is no longer a project but a final library.
Since you have control over project A, you should really rely on Maven conventions and either build a fat jar or an assembly (with maven-assembly-plugin).
By the way, the pom.xml file located under META-INF is not guaranteed to exist, and, in fact, it is not there if you look at Spring artifacts. Take a look at Maven Archiver documentation: the presence of this pom file is controlled by the addMavenDescriptor boolean attribute. Set this attribute to false and your main artifact will not have this pom file.

Disable maven build number plugin

Currently we are working on the big maven project that has about 100 modules, some of them have submodules as well.
Some of modules use Maven Build Number plugin. The project is hosted under subversion.
Recently we started to use git locally in our development team.
After cloning subversion repo and trying to build the Project, we received following well known error:
The svn command failed.
Command output:
svn: ‘.’ is not a working copy
Unfortunately in our case it is not an option to create a new profile or just remove plugin definition from POM (this will follow to messing up hundreds of POM files).
I found the following article http://abstractionextraction.wordpress.com/2012/09/27/git-svn-vs-maven-build-number-plugin/ but honestly, it's not something that I would really like to do...
Is there any smart way to disable this plugin. Like command-line parameter?

I think you may skip failure on obtain revision without change project pom.xml - buildnumber-maven-plugin has option revisionOnScmFailure which you may use like:
mvn -Dmaven.buildNumber.revisionOnScmFailure=no-scm package
In that case value no-scm will be used if scm call was unsuccessful. Off course you may change it and provide any other string.

Per the mojo documentation, you could use the revisionOnScmFailure property.
However, it doesn't have a command line option. You'll have to modify those pom.xml files.
See "Defining Parameters Within a Mojo" in the Maven Java Plugin Development Guide

One approach would be to use a property in your pom to specify the execution phase of the build number plugin, as shown below.
<project>
..
<properties>
<buildnumber.plugin.phase>validate</buildnumber.plugin.phase>
..
</properties>
..
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<phase>${buildnumber.plugin.phase}</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
..
</configuration>
</plugin>
</plugins>
..
</project>
Then provide the property on the command line to disable the plugin, as shown in the following example.
mvn install -Dbuildnumber.plugin.phase=none