Maven site:deploy (with DIFFERENT url) during "deploy" goal (when in testing profile)? - maven

How can I make maven do a site:site and a site:deploy when the deploy is run?
Am I best off to make my own plugin (modified version of maven-release-plugin) or is there an easy way in Maven (configuration of a plugin within a profile)?
Thanks!
EDIT for clarification: I basically want a site-deploy done (to a special url) for snapshot releases. Namely the javadoc. Thanks!

Create two profiles.
The first will be active unless a property has been defined. It will use one URL.
The second one will be triggered by some property.
In each profile define the required settings for the site plugin with their respective differences.

Related

How can you chain/stitch Maven plugins?

I want to chain two Maven plugins which should execute in sequence. The output from the first plugin should be used as input for the second plugin. Let me explain:
I want to write a plugin which generates resources and sources, such as configuration files, Java classes, ... Let's call this plugin generator-plugin.
This plugin needs input information to generate all this. This information can be retrieved from file system or from a SQL database. Possibly, in the future one might introduce several other input sources. My idea is to write two plugins, one for getting all information from the file system and another from a SQL database.
This gives:
information-plugin-file ---\
|--- generator-plugin
information-plugin-sql ---/
How can this be done with Maven? Can you chain plugins? I am familiar with writing basic Mojo's, but I have no idea how to approach this, hence this question.
One possibility is to output to a standardized file in information-plugin-file/information-plugin-sql and let the subsequent generator-plugin plugin read from the same file (the Unix way of working, everything is a file).
But I am looking for more direct, Maven specific approaches of doing this. Are there such approaches?
With regards to execution order, all plugins will run in the generate-sources phases and will be defined in correct order in the <plugins> section. So that is already covered I think.
AFAIK, plugins in maven are designed to be totally independent, so the following methods of sharing the information can be used:
Sharing via maven properties:
Its possible to set a property in the first plugin, and probably it will be accessible from within the second plugin
import org.apache.maven.project.MavenProject;
// now inject it into your mojo of the first plugin
#Parameter(defaultValue = "${project}")
private MavenProject project;
// Inside the "execute" method:
project.getProperties().setProperty("mySampleProperty", <SOME_VALUE_GOES_HERE>);
Sharing via Files
The first plugin can generate some output file in the 'target' folder
And the second plugin can read this file
Write a "wrapping" plugin that executes other plugins (like both first and second plugin). After all mojos are just java code that can be called from the aggregator plugin
You can find Here more information about this method
I believe the only way you can have something ordered in Maven is through lifecycles. You could have your first plugin (for the input information) run in the generate-sources phase, and the second in process-sources phase.

How to generate/retain javadocs for one module that is built with two maven profiles?

I have two maven profiles. Each profile generates javadocs for one module. Is there a way by which I can edit the apidocs/index.html page to allow to retain the classes generated by one profile and append the new classes generated by other profile? Right now I can generate the javadocs for individual profile builds but cannot retain the older classes when we build the project with the second profile as it overrides the earlier apidocs.
One way is to use the outputDirectory property of maven javadoc plugin, to set it to a different location for each profile.
See:
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-no-fork-mojo.html#outputDirectory

How to deploy Neo4j snapshot build to a custom Maven repository?

When I try to build neo4j from sources and deploy it, the deployment phase fails since there is already a repository defined in the grandparent's pom.xml.
Is it possible to redefine (or add) the DistributionManagement properties so that I'll be able to deploy custom neo4j build to an internal non-local repository?
It is possible since maven-deploy-plugin 2.8
Just be sure to use that version of the plugin (by defining it in neo4j's pom if neo4j doesn't already do that by itself)
Then define altReleaseDeploymentRepositoryand/or altSnapshotDeploymentRepository in your maven settings.xml. (Depending on your personal preference you can also define that inside a profile).
The syntax of the alternative repositories is id::layout::url where id must match the id of a server that is also defined in your settings (giving you the chance to give user/pass for that server). Layout is default
Example:
<altReleaseDeploymentRepository>my.nexus::default::https://my.domain.com/nexus/content/repositories/releases/</altReleaseDeploymentRepository>

maven cargo integration test - how to get cargo.hostname or profile?

I'm using Maven 2 w/ cargo to deploy to different remote tomcats depending on the maven profile used.
I also have integration tests (junit w/ remote webservice calls) that I would like to automatically run.
Question: How do I setup my test code to be able to read either the cargo.hostname (preferred, changed property value based on maven profile) or the maven profile actived so it knows which url to go run the tests against?
Specifically, this is in java in the test case.
Thanks!
Either you define a fixed value for the cargo.hostname (not the best; but sometimes it workds well, cause using a fixed test server) or better define an appropriate property in Maven for it and put the information also into a properties file which will be filtered by the build process in the src/test/resources folder which can be read before the real integration tests.

Maven Variables are not replaced into installed pom file

We are using Maven(3.0.3) as build tool and we need to have different version for different environments (DEV , TEST, QA ) . If we pass version property value during build time based on environment , the installed POM doesn't have the passed property values instead it still has the ${app-version} string.
I saw already there is a bug for this http://jira.codehaus.org/browse/MNG-2971
Is there any other alternative ,because we cannot different POM file for different environments ,which will be hard to maintain..
Thanks
Vijay
Create different artifacts for the environments and use the parameter as a classifier. The pom is the same for all three artifacts but the classifier separates them.
Apparently Maven does not make any variable/property substitution when installing the POM. It is installed as is, that is the principle. You'd better not read any properties from POM (unless this is e.g. version number), bout you should configure your properties in external file (one per stage, e.g. dev.properties, test.properties, ...) and then configure Maven profiles (again, one per stage) and invoke Maven like mvn -Pdev depending on what you want to build. In profile you can package your final application with whatever properties you like (e.g. with the help of build-helper-maven-plugin:add-resource or maven-antrun-plugin + copy rule).
Alternatively you can filter your resources. For example, you can filter your Spring context XML file, which refers the properties file (so you package all property files, but Spring will refer only some specific). Or you can filter another properties file from which you will learn what is the "main" properties file to use (double indirection).
You should create the archives for your different targets within a single build and use as already mentioned the classifier to separate those artifacts from each others.

Resources