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.
Related
I have a project with finalised version in pom files , lets say 12.3.45 .
I have built the code for this version some time ago already, all the built jars are in the local maven repo.
Then at some point I have run mvn clean, so all the target folders are being removed.
And now I want to execute some code, as quickly as possible, using mvn exec:java. Preferably without building anything, because why not? all the jars at some point were already built, and I know there were no code changes after that. How can I force maven to execute the code as fast as possible , not recompile anything, and just reuse the jars from the local repo?
Thanks.
If your artifacts are in a local or remote repository you can use them as dependencies.
You can use exec-maven-plugin's options includeProjectDependencies or includePluginDependencies to use them in java execution
https://www.mojohaus.org/exec-maven-plugin/java-mojo.html#includePluginDependencies. includeProjectDependencies option is enabled (true) by default.
You can execute exec-maven-plugin without building anything with mvn exec:java command
Instructions:
To run exec-maven-plugin you would need a main class to run. I assume you have one in your project. If you don't - you need to make a separate project with a main class.
Create a blank maven project.
In the project add exec-maven-plugin configuration. Set the mainClass
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<goals>
<goal>java</goal>
</goals>
<configuration>
<mainClass>pack.App</mainClass>
</configuration>
</plugin>
</plugins>
</build>
Include you artifacts as dependencies to the project
<dependencies>
<dependency>
<groupId>my.group</groupId>
<artifactId>myartifact</artifactId>
<version>12.3.45</version>
</dependency>
</dependencies>
Run mvn exec:java to execute com.my.package.MyMainClass main class from my.group.myartifact artifact
Edits:
includeProjectDependencies option is enabled (true) by default
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.
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.
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.
Is there a way I can configure maven to always download sources and javadocs? Specifying -DdownloadSources=true -DdownloadJavadocs=true everytime (which usually goes along with running mvn compile twice because I forgot the first time) becomes rather tedious.
Open your settings.xml file ~/.m2/settings.xml (create it if it doesn't exist). Add a section with the properties added. Then make sure the activeProfiles includes the new profile.
<settings>
<!-- ... other settings here ... -->
<profiles>
<profile>
<id>downloadSources</id>
<properties>
<downloadSources>true</downloadSources>
<downloadJavadocs>true</downloadJavadocs>
</properties>
</profile>
</profiles>
<activeProfiles>
<activeProfile>downloadSources</activeProfile>
</activeProfiles>
</settings>
Edit: As mentioned by Jingguo Yao, this works with Eclipse IDE only - the same can also be configured in your IDE of choice. In Elcipse via Window -> Preferences -> Maven menu, though this probably has to done at every workspace level and for fresh Eclipse installations.
Alternatively configure the maven-dependency-plugin in your pom.xml in a separate profile and run it as required - keeping it in the main build will lead to build times (needlessly elongating (not to mention space) at places like your build nodes that don't need either sources or java docs. Preferable this should configured in some org or division parent pom.xml, otherwise it has be repeated everywhere in different places
In my case the "settings.xml" solution didn't work so I use this command in order to download all the sources:
mvn dependency:sources
You also can use it with other maven commands, for example:
mvn clean install dependency:sources -Dmaven.test.skip=true
To download all documentation, use the following command:
mvn dependency:resolve -Dclassifier=javadoc
Just consolidating and prepared the single command to address source and docs download...
mvn dependency:sources dependency:resolve -Dclassifier=javadoc
Answer for people from Google
In Eclipse you can manually download javadoc and sources.
To do that, right click on the project and use
Maven -> Download JavaDoc
Maven -> Download Sources
I am using Maven 3.3.3 and cannot get the default profile to work in a user or global settings.xml file.
As a workaround, you may also add an additional build plugin to your pom.xml file.
<properties>
<maven-dependency-plugin.version>2.10</maven-dependency-plugin.version>
</properties>
<build>
<plugins>
<!-- Download Java source JARs. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>${maven-dependency-plugin.version}</version>
<executions>
<execution>
<goals>
<goal>sources</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
On NetBeans :
open your project explorer->Dependencies->[file.jar] rightclick->Download Javadoc
As #xecaps12 said, the simplest/efficient approach is to change your Maven settings file (~/.m2/settings.xml) but if it is a default settings for you, you can also set it like that
<profile>
<id>downloadSources</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<downloadSources>true</downloadSources>
<downloadJavadocs>true</downloadJavadocs>
</properties>
</profile>
In Netbeans, you can instruct Maven to check javadoc on every project open :
Tools | Options | Java icon | Maven tab | Dependencies category | Check Javadoc drop down set to Every Project Open.
Close and reopen Netbeans and you will see Maven download javadocs in the status bar.
To follow up on the answer from kevinarpe this does both sources and Javadocs:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.1</version>
<executions>
<execution>
<goals>
<goal>sources</goal>
<goal>resolve</goal>
</goals>
</execution>
</executions>
<configuration>
<classifier>javadoc</classifier>
</configuration>
</plugin>
</plugins>
</build>
I think it can be done per plugin. See this chapter from the Maven book.
You might be able to configure the dependency plugin to download sources (even though I haven't tried it myself :-).
Simply modify file mvn (or mvn.cmd if in windows) and add whatever command line switches you need (as mentioned by other answers). If you don't want to modify the install files (which I'd recommend), create a mymvn (or mymvn.cmd) wrapper that invokes the regular mvn with the parameters.
Not sure, but you should be able to do something by setting a default active profile in your settings.xml
See
See http://maven.apache.org/guides/introduction/introduction-to-profiles.html
I had to use KeyStore to Download the Jars. If you have any Certificate related issues you can use this approach:
mvn clean install dependency:sources -Dmaven.test.skip=true -Djavax.net.ssl.trustStore="Path_To_Your_KeyStore"
If you want to know how to create KeyStores, this is a very good link:
Problems using Maven and SSL behind proxy
For the sources on dependency level ( pom.xml) you can add :
<classifier>sources</classifier>
For intellij users, inside the pom.xml file, right click anywhere and select Maven -> Download sources and Documentation.