We Keep Coding

How to install android-maven-plugin?

I need to use the android-maven-plugin for my project (especially for the multidex feature) but I can not figure out how to configure my actual pom.xml file (is is a standard file). I am using Eclipse Luna on Windows.
I did not manage to find any tutorial, does anyone has a good link about how to use and configure it ?
I want to use this plugin artifact :
<plugin>
<groupId>com.simpligility.maven.plugins</groupId>
<artifactId>android-maven-plugin</artifactId>
<version>4.3.0</version>
</plugin>
NOTE : do not confund with groupId com.jayway.maven.plugins.android.generation2
NOTE 2 : I think it is not the same problem and solution here : how to start using android-maven-plugin?

The Android Maven Plugin used to use the jayway groupId and has simply migrated to the simpligility based one.
All instructions you find are still valid apart from the differing groupId. Specifically I would suggest to look at the documentation website and the example projects.

Maven Plugin for project semantic versioning

I'm looking for a maven plugin that will help me manage version names and codes of every build that is made on our CI environment. Something that will be able to attach a prefix to the main version code or even update it (not changing the pom.xml). For example:
project version: 2.0.1
git/svn revision: 2342334
jar output: name-2.0.1-2342334.jar
maven repo: ../path/to/local/maven/repo/<package path>/2.0.1-2342334/
The main requirements to this plugin are:
Must be in Maven Repository (which means that NO additional setting required to add this plugin in my pom.xml and run maven)
Must not edit the pom, each time it's applied
A configuration file, would be great, so I could manage the versioning process
Must be able to edit the output file metadata (so the version will be applied as if it was written in the pom.xml file in the first place)
So far I found only maven-buildmetadata-pluging but unfortunately it's not in Maven Repo, so I'm stuck. Any help would be great.

Hosting your own maven repository is very easy, using either Nexus or Artifactory. You can also use the Artifactory cloud version (I'm not affiliated with them...) so it may solve your problem. BTW - a simple server with Apache does the trick as well, but with more work..,
Regarding the plugins: If you deploy snapshot applications then each gets its own version based on timestamp.
For releases another option is to run an svn info and put the result (or part of it) into the generated artifact. The information can then be accessed by the code.

If you change the version of your artifact the pom has to reflect the change, cause otherwise it's not reproducible.
If you change something in your build process (like added versions, whatever) it has to be reflected in the pom file. Otherwise you can not reproduce the build process with the same result.
You have written not to change the pom file but maintaining a separate file. So the questions is: Why not using the pom file itself, cause it's intended exactly for that purpose.
Furthermore all informations which you mentioned by the maven-buildmetadata-plugin can be achived by using existing maven plugins (like build-helper-maven-plugin, buildnumber-maven-plugin).
The SCM information can be used by using the buildnumber-maven-plugin which provides information like SCM revision number (SVN or GIT hash).
An on the other hand if you don't like to change your pom file manually you can use either the versions-maven-plugin or the maven-release-plugin which automatically can change informations in your pom file and handle all these things automatically.
To maintain metadata in your producted artifacts you can configure all plugins (like ear, war, jar) etc. more or less like this where the buildNumber is comming from buildnumber-maven-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>${maven-jar-plugin.version}</version>
<configuration>
<archive>
<addMavenDescriptor>true</addMavenDescriptor>
<index>true</index>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
<manifestEntries>
<artifactId>${project.artifactId}</artifactId>
<groupId>${project.groupId}</groupId>
<version>${project.version}</version>
<buildNumber>${buildNumber}</buildNumber>
</manifestEntries>
</archive>
</configuration>
</plugin>
And of course if you really like to use Maven you should have to use an repository manager as already mentioned like Artifactory or Nexus which make life easier.

I just would like to add (although the question is 5 years old and already has an accepted answer) that the Buildmetadata Maven Plugin was not available on the Maven Repo at first, but it is now (since late 2013). People who would like to give it a try find the artifact at the following locations :
com.redhat.rcm.maven.plugin:buildmetadata-maven-plugin
de.smartics.maven.plugin:buildmetadata-maven-plugin
Please note that the name has changed from maven-buildmetadata-plugin to buildmetadata-maven-plugin due to naming conventions.
I'm one of the "original" authors of this plugin at smartics. If you would like to use it, you probably would like to use the fork provided by Red Hat. To my knowledge the two versions do not differ very much and they have not been synced since there is just so much other stuff to do and the plugin seems to be feature stable. ;-)
The source code for both versions is also available on GitHub:
release-engineering/buildmetadata-maven-plugin
smartics/buildmetadata-maven-plugin

As already stated, you have to change the version in the pom. One way of doing that, in combination with the release plugin is:
mvn \
se.bjurr.gitchangelog:git-changelog-maven-plugin:VERSION_HERE:semantic-version \
release:prepare release:perform
Using Git Changelog Maven Plugin

m2e still gives an error saying "Plugin execution not covered by lifecycle configuration" even with explicit bindings in custom plugin

I'm building a plugin to do some code generation.
I've followed the steps here for how to create a plugin:
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
Plugin Source:
/**
* #goal helloworld
* #phase generate-sources
*/
public class SampleMojo extends AbstractMojo
{
#Override
public void execute() throws MojoExecutionException, MojoFailureException
{
getLog().info("Hello, world.");
}
}
Usage:
<plugins>
<plugin>
<groupId>com.sample</groupId>
<artifactId>sample-maven-plugin</artifactId>
<version>0.0.1</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>helloworld</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
The plugin works fine on its own, but in Eclipse, I keep getting the "not covered by lifecycle" error.
I read through "How to solve “Plugin execution not covered by lifecycle configuration” for Spring Data Maven Builds" and I assumed that if I created my own plugin and set the #phase and #goal annotations it would get rid of that error. I really don't want to put in the "lifecycleMappingMetadata" node in the pom.
Anyone have any advice on this? Is there something special that I need to write for m2e to get that error to go away?

K. Claszen's answer is correct, but I'd like to fill out some extra details.
A. Why is m2e like this?
The point of this behaviour is to prevent m2e from consuming too many resources with incremental (& potentially never-ending) changes.
B. m2e version 1.1 is not a 'release' yet
Currently m2e 1.1 is still a 'milestone'.
Users would need to install/upgrade-to it with this update site:
http://download.eclipse.org/technology/m2e/milestones/1.1
(I also had to uninstall an 'm2e SCM connector' in order to upgrade it)
Right now, this is potentially more hassle for your users than inserting the 'Quick Fix' snippet in their pom.xml files. But, in the long-term it's good to use it.
C. Overview of making your maven plugin m2e-1.1-compatible
As described by K. Claszen, most of the info is here: M2E compatible maven plugins.
Some key points:
Execution information is defined in a file - src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml - see M2E compatible maven plugins for format.
If you have enabled 'incremental execution', your Mojo will need to communicate properly with the Maven API:
Specify a dependency to org.codehaus.plexus/plexus-build-api/0.0.1 (current at time of writing)
Use org.codehaus.plexus.build.incremental.BuildContext, to:
Check whether relevant resources have changed
Notify Maven about relevant write operations executed by the plugin, so that it knows to compile sources, etc.
D. Alternatives
If 1.1 isn't a realistic option for your users, you could:
Create an 'M2E Extension Eclipse plugin' (!!), aka an 'M2E Connector', and contribute it to the marketplace. Good luck with that.
Inform your plugin users to select the M2E 'Quick Fix', and then manually change the <ignore /> line to <execute />. There are other SO questions/answers which cover this.

I think the M2E compatible maven plugins site will give you the information you need. Notice that this works first since m2e version 1.1.

switching to gradle from maven to manage a osgi big project (>200 bundles)

We have a big (~215 bundles and counting) osgi (felix+springdm) project, build with maven and maven-osgi plugin.
We've several problems with maven way:
1.　submodules pom have to inherit from parent pom to take advantage of common variables and dependencies (that's ok) but then parent pom has to include all bundles pom to be able to build everything in together. This kind of circular reference makes much hard to keep all in sync.
2.　the individual versioning of subbundles was so complex that it was decided (before I joined the project) to use the same version for all bundles. This means we now update version of all bundles for every release also if just a bunch of them are actually changed. This makes the whole concept of osgi a bit meanless IMHO. Please note that I'm not saying we continue to touch just a minority of bundles, we work on all of them but every release usually contains 1 or 2 features, that affects just some bundles.
3.　to do the package and the deploy of the final artifact we need still another submodule that imports all the bundles needed for the deploy (all but a few for tests and mocks).
[edited]
Note that this aggregation is different from the one in the main pom as it doesn't compile bundles but just pick them from the maven repository.
4.　the maven dependency system and the osgi plugin imports are sometimes hard to keep aligned. It's just too easy to forget an import or putting a wrong dependency.
[edited]
In every bundle pom there is a section like this:
`
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>
</Export-Package>
<Import-Package>
com.google.gson,
org.apache.log4j,
org.apache.log4j.spi,
org.dom4j,
com.myinterfaces
</Import-Package>
</instructions>
</configuration>
</plugin>`
For all those reasons, we are ok but not perfectly happy with maven. Recently someone proposed Gradle not as a panacea but as a definite improvements over the current situation.
Would you recommend moving to gradle? and in case which would be the best way?
Has someone else experienced the same situation? I think it should be common for all big projects with Osgi.
Disclaimer: I looked for similar questions like:
Buildr, Gradle or wait for Maven 3?
Looking for a good dev environment for OSGi bundles
Maven : OSGI, bundles and multi-modules projects
but either where where not about osgi submodules or not about gradle.

You can separate the parent and the aggregate maven modules, because currently your parent pom have two roles as you correctly observed. More information can be found in the Maven Introduction to POM.
I'm afraid that bundles version management cannot be become easier unless you use API Tools. Perhaps it would be great if API tools can be integrated as Maven plugin, but I'm not aware of any work in this area. So, you either touch all versions at once or update them each time it is needed. API Tools will greatly help here, but it works only for bundles, which can be imported as Plug-in Projects inside Eclipse.
So, will another aggregator module help here? You can setup several aggregators, which aggregate another aggregators, so you don't end up with one huge aggregator module which lists everything? Because, you may not want to deploy everything, you can setup what to exclude from deploying. Quick google search showed how to do it.
#Neil Bartlett already noted that bnd will take care of your manifest if you've setup your dependencies right. If you need extra tweaking of the defaults, you can always set BND instructions file.
You can put Tycho in the list of possible tools. It will help you with the dependency management, because you need to specify your dependencies in the Manifest only and it will permit you to use API Tools (but no integration yet). It will however require that you use p2 repositories if you want to skip some headaches (until Tycho has improved their support for depending on Maven artifacts).

Setting up Maven for a team

I have used Maven extensively for my personal projects, but now I have to set it up for a small team of 5-7 developers.
My main question is, what's the recommended approach for managing dependencies to commercial libraries that are not available in the Maven repos? How can I manage the dependency of these commercial libraries on the open source libraries that they use and are available in Maven repos?
Also, are there any other recommendations and advices that I should know or implement to make the setup as efficient, effective, and smooth as possible?
Thanks in advance.

You probably want to start by setting up your own internal Maven repository using Nexus or Artifactory. Configure it as a repository for your own artifacts, and as a caching proxy for Central and any other external repositories that you need to fetch stuff from.
Then create binary only POM files for each of the commercial libraries, including dependencies on the published libraries that they depend on. Upload the POM files and corresponding JAR files to your internal repository in the required structure. Just make sure that these POMs and JARs are not visible outside your group / organization ... depending on what the license for the respective commercial products permit / require.
Of course, this means that you won't be able to make your applications (that depend on these libraries) publicly available via Maven. But you've probably already factored this into your planning.

i strongly advise to use a super parent pom with some common settings like
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<inherited>true</inherited>
<configuration>
<source>1.6</source><!-- java version -->
<target>1.6</target>
<encoding>UTF-8</encoding><!-- your source encodings -->
<debug>true</debug><!-- false for production -->
<optimize>false</optimize><!-- true for production -->
<showDeprecation>true</showDeprecation>
</configuration>
</plugin>
actually there a lot of those "common" settings (report plugins), a parent pom guarantees that all use the same and a change reaches all
well what else - beside an own maven repo (try nexus) - ?
check used IDEs, Eclipse, Netbeans and IntelliJ have different levels of maven support and sad but true different behaviour, if you can, get your team to use one IDE
think about a build server like hudson