I'm rather new to Maven and I often find myself wanting to see what's actually there in terms of goals.
So, is there a command which lists all available goals for e.g. a given prefix?
Since Maven is an open system of plugins, the best answer is probably "Google" ;-). If you mean all build lifecycle phases, they are static, and can be found at http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html and at other places.
Then, for a given plugin, the help plugin can be used to get the possible goals and all their parameters:
mvn help:describe -DgroupId=org.apache.maven.plugins \
-DartifactId=maven-war-plugin \
-Ddetail=true
But this doesn't really answer your question, especially the "for a given prefix" part. For this, the best solution might be to use **auto completion with BASH (**not sure it will be exhaustive though). See for example the Guide to Maven 2.x auto completion using BASH. To get bash completion working under Windows, you'll need CYGWIN. See Maven Tab Auto Completion in Bash for detailed setup steps (and a "better" working auto completion script).
A shorter way
As an alternative, you can also use the -Dplugin parameter to display the list of available goals.
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-war-plugin\
-Ddetail=true
See Maven help plugin.
More and more Maven plugins propose an help goal as alternative to the verbose
mvn help:describe command.
You can read from the Maven doc:
Recent Maven plugins have generally an help goal to have in the
command line the description of the plugin, with their parameters and
types
That is really more natural and pleasant to use.
It works of course for Maven core plugins.
Some examples :
to list goals of the dependency plugin :
mvn dependency:help
to have detail about the javadoc goal of the javadoc plugin :
mvn javadoc:help -Ddetail -Dgoal=javadoc
And it works also for third party plugins.
For example, to list goals of the spring-boot-maven-plugin :
mvn org.springframework.boot:spring-boot:help
[INFO] Spring Boot Maven Plugin 2.0.0.RELEASE Spring Boot Maven
Plugin
This plugin has 6 goals:
spring-boot:build-info
Generate a build-info.properties file based the content of the
current MavenProject.
spring-boot:help
Display help information on spring-boot-maven-plugin. Call mvn
spring-boot:help -Ddetail=true -Dgoal= to display
parameter details.
spring-boot:repackage
Repackages existing JAR and WAR archives so that they can be
executed from the command line using java -jar. With layout=NONE can
also be used simply to package a JAR with nested dependencies (and
no main class, so not executable).
.....
Or to get detailed information about the build goal of the dockerfile-maven-plugin :
mvn com.spotify:dockerfile-maven-plugin:help -Ddetail -Dgoal=build
[INFO] Dockerfile Maven Plugin 1.3.6
Adds support for building Dockerfiles in Maven
dockerfile:build
Available parameters:
- archive
The archive configuration to use for the Docker info JAR. This can be used
to embed additional information in the JAR.
....
You could note that the syntax to get a detailed output of the help and to focus on a specific goal (-Ddetail -Dgoal=myGoal) is exactly the same as this used for the core maven plugins.
Of course some esoteric plugins may not provide the help goal but in most of well designed plugins this is present.
Related
When building a Maven plugin, where can I find documentation for the built-in expressions that can be used for #parameter expression="${...}" constructs?
You might also try the help:evaluate goal of the maven help plugin to quickly show the values of one of these properties from the command line. For example
mvn help:evaluate -Dexpression=project.build.outputDirectory
would echo the output directory of the current project.
There is the Maven Properties Guide. Check also the chapter 9.2. Maven Properties of Maven: The Complete Reference.
I'd like to generate liquibase's dbdoc as part of my maven site build, but I cannot figure out how to do this. My thoughts were to add maven-antrun-plugin to the reporting section of the pom, but I cannot have an node under plugin in the reporting section. Any ideas?
This is not supported by the Maven LiquiBase Plugin so either create your own report plugin or use the dbDoc Ant Task and the Maven AntRun Plugin to generate the documentation under target/site/.
In the later case, bind the plugin on one of the phases of the Site Lifecycle (this will require some testing but I think that pre-site, site or post-site would be ok) and add an entry in the left menu in the site descriptor.
You can create your own reports plugin, more information here:
http://docs.codehaus.org/display/MAVENUSER/Write+your+own+report+plugin
I'm new to Maven and have skimmed over the documentation as I am following the Hibernate tutorial at http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#tutorial-firstapp-mvn.
I have installed Maven and successfully setup a web-app but this does not contain all of the standard directories mentioned in the tutorial. Am I going mad?
When building my Maven project I am using the maven-archetype-webapp. This gives me the arh-webapp\src\main\resources and arh-webapp\src\main\webapp directories but I'm missing quite a few directories mentioned on the link http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html.
Surely I don't have to manually add these? If not then the Hibernate documentation does not mention what archetype to use in order to achieve the directory structure used in their tutorial. Please can someone enlighten me.
What archetype do I need to use in order to have the above directory plus the src/main/java directory? If there is no such archetype then can easily append these using Maven? and how?
Surely you'll have to manually add these.
Just create those directories that according to the Maven convention are missing. Remember, a Maven Archetype is just a starting point to save you time configuring your workspace. After encountering many problems in some Archetypes myself I've been accustomed to just use a basic-web-app-archetype and then customize it myself, as a beginner with Maven you'll be better off doing that, and will learn a lot.
Regards.
Not all the directories mentioned are required for your standard web application. In fact, the reason behind the presence of the src/main/java, src/main/resources and the src/main/webapp directories is due to the archetype that you've used.
IMHO, the book titled "Better Builds with Maven" will serve you better; the Sonatype books on Maven might also help. The complete Maven documentation is also available as a PDF file, for future reference.
But just in case, you need some clarity on the terms used, here's some:
Archetype: A pattern for projects. Simple web applications (with no dependencies on other frameworks/libraries) have their own archetypes, so do applications using Spring, Hibernate, Seam, etc. Some archetypes will result in creation of different directories, as they are coded that way. You might be able to change the directory structures in most cases, although I cannot vouch for every archetype. For instance, it is quite possible to place your sources in 'src' instead of 'src/main/java', although this requires additional configuration in the POM.
Lifecycles, Phases and Goals: A Maven build lifecycle is a series of phases, with each phase executing a set of goals. Maven can be commanded to execute a build phase, which results in execution of all phases until and including the specified phase.
Maven plugins: Maven plugins contain one or more goals. Goals need not be bound to phases, but usually you would bind them to particular phases. Plugins are the basis for everything operational in Maven; you're using plugins even though you are just compiling the application (the Maven compiler plugin is a core plugin that is present in the Maven distribution).
I hope the above helps, but I would suggest that the reference books be followed.
I'm building Maven projects via TeamCity/Git and trying to insert the TeamCity build numbers in the pom.xml that gets published to my repository upon a successful build. Unfortunately I can't determine how to publish a pom.xml with the substitutions inserted.
My pom.xml contains info like:
<version>${build.number}</version>
where build.number is provided by TeamCity. That all builds ok, and if (say) build.number = 0.1, then the deployment is a pom.xml to a directory with 0.1. All well and good.
However, the pom.xml that is deployed is the pom.xml without the substitutions made. i.e. Maven is running with a pom.xml with appropriate substitutions, but deploys the initial version and so I get
<version>${build.number}</version>
in the final pom.xml. How can I get the build version number in the pom.xml ?
I wouldn't use this approach because it makes building a project checked out from the SCM not possible without providing the build.number property. I don't think that this is a good thing. Maybe I'm missing something though.
Actually, I don't get what you are trying to achieve exactly (why don't you write the build number in the manifest for example). But, according to the Maven Features on the Teamcity website:
By default, it also keeps TeamCity build number in sync with the Maven version number (...).
Couldn't that be helpful? There is another thread about this here.
Try to use generateReleasePoms property of maven-realease-plugin, maybe that helps a little.
I'm currently working on two projects simultaneously:
My main project (built with maven)
A spike of an open source project, which my main project depends on (not build with maven)
How do I set up maven to use the OSS project as a dependency with the least amount of friction, given that I'm often developing the two in tandem?
I can think of several solutions:
Mavenize the existing OSS project. This is of course the "ideal" option but often not feasible (even if you introduce the new build system in parallel of the existing one). The project has likely an existing project structure that differs from Maven's standard layout. Changing the existing layout and build script may not be desired by developers, adapting a Maven build to use a non standard layout can be painful. In both case, you're screwed.
Wrap the existing Ant build with Maven. This can be nice if you want to include the build of the OSS project in the lifecycle of your project and have both of them built in one step. You can check this answer on SO for details on how to do this.
Use Apache Ivy or Maven Ant Task in the existing build to produce and install a Maven artifact in your local repository. Use this artifact as a regular dependency in your Maven project (except that you'll have to declare its transitive dependencies manually). This is maybe the quicker and less intrusive approach if building both project separately is not a problem.
It looks like you choose option 3. I think it's a good choice for a quick win.
The solution I've used is the maven-ant tasks (http://maven.apache.org/ant-tasks/).
I added an install task onto the build.xml file, which installs the compiled .jar into the local repo.
While adding a full-fledged pom to the project would defintely be the best approach, this is a major chunk of work, and inflicts maven on the project (where the other users would prefer not to use it).
I think you probably need to bite the bullet and set up a POM for your OSS project tree. This is the painful part (as you would need to hunt down the details of specifying resources paths for various plugins involved depending on the OSS app type (i.e. web, etc.)). Good news is that this is a one time effort.
Once that is done, your main project can refer to the (wrapped) OSS project as a dependency. Here a (standard maven) multi-project structure would apply.
If OSS project has dependencies - create a POM with those dependencies (your project will use them as transitive dependencies) and install that artifact and pom in local repository. If OSS project hasn't any other dependencies is even simpler - the POM is generated automatically during installing.
For both cases use maven-install-plugin.
mvn install:install-file -Dfile=your-artifact-1.0.jar \
[-DpomFile=your-pom.xml] \
[-Dsources=src.jar] \
[-Djavadoc=apidocs.jar] \
[-DgroupId=org.some.group] \
[-DartifactId=your-artifact] \
[-Dversion=1.0] \
[-Dpackaging=jar] \
[-Dclassifier=sources] \
[-DgeneratePom=true] \
[-DcreateChecksum=true]