I am including few jars in DependencySet include section
<includes>
<include>dom4j:dom4j:jar</include>
<include>log4j:log4j:jar</include>
</includes>
However I am getting dom4j-1.5.jar and log4j-1.2.jar. Since there are many other versions in repo,
I would like to pull specific version for my application. [dom4j-1.6.1.jar and log4j-1.2.5.jar]
How do I force maven to pickup specific version in Assembly.xml?
Try the includes in the following format:
(groupId:artifactId:type:[classifier:]version)
Alternatively, fix you dependencies. You can do this by adding an explicit dependency to the version of the dependency you would like to use in the pom.xml you're using to invoke the assembly plugin from.
Related
I'm using jar-with-dependencies in Maven to create a compiled jar file for my project. However, one of the dependencies has got source code in its jar in a non-standard place (/jvm/), and this is being included in the combined output jar.
How do I exclude a specific directory in a specific jar from being included in the combined output jar? An <excludes> tag doesn't seem to be valid anywhere in the plugin definition (at least, IntelliJ doesn't think it's valid)
I have never used jar-with-dependencies but for the same problem you mentioned above we used maven-shade-plugin in our project to include and exclude classes from particular packages.
<excludes>
<exclude>com.techidiocy.dump.*</exclude>
</excludes>
In above it will ignore all the classes from the package com.techidiocy.dump
Thanks
We have a groupId for Maven plugins:
com.company.maven.plugins
Unfortunately, when I created the first plugin in this groupId, I initially used the wrong naming convention.
maven-myplugin-plugin
The 1.x versions of the plugin used that name. When I realized this was wrong I changed the name to meet the correct convention.
myplugin-maven-plugin
Then I updated the version to 2.x.
In my local settings.xml file I use the pluginGroups to access my plugins from the command line. This particular plugin does not have to be specified in the pom file.
Unfortunately, when I try to access my plugin from the command line without scoping the name I always get the latest version of the incorrect naming convention. So, I get a 1.x version.
Can I tell Maven to ignore the maven-myplugin-plugin artifacts when accessing from the command line (i.e. mvn myplugin:mygoal)?
Some projects still use the old 1.x plugins, so I don't want to delete them from our repository. Also, we are using at least Maven 3.0.3.
It somehow seems that Maven3 resolves the prefixes from plugins in the order of
1. maven-myplugin-plugin
2. myplugin-maven-plugin
3. ... hard-wired groups ...
Following the official naming convention it should be the other way round imho. Nevertheless, I think you do not have a chance to get this fixed. I tried a set of things, basically playing around with the goalPrefix in the maven-plugin-plugin config. Installing a new version of the deprecated-named plugin with goalPrefix did not work. I guess one thing you could do is defining another prefix for your correctly-named plugin, e.g.:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-plugin-plugin</artifactId>
<version>3.2</version>
<configuration>
<skipErrorNoDescriptorsFound>true</skipErrorNoDescriptorsFound>
<goalPrefix>myplugin2</goalPrefix>
</configuration>
</plugin>
Another approach could be to adjust the old plugin's pom.xml, renaming it to something different. But this would imply that your colleagues would need a different execute a different mvn command. Or you can rename your current plugin - similar results.
If there is a better solution, I would also be interested!
Please do you know if it's possible to automatically replace one Maven plugin with another in the POM files for a project?
The context is that I'm trying to intercept a Scala build using a Scala compiler plugin, for which I want to be able to specify the Scala compiler plugin as an argument to scalac from the command-line (i.e. not within the POM files). This is possible using the latest version of the Scala Maven plugin (known as scala-maven-plugin) by using its addScalacArgs flag - see here: http://davidb.github.com/scala-maven-plugin/apidocs/scala_maven/ScalaMojoSupport.html. However, it's not possible for the old version of the plugin (known as maven-scala-plugin), and I'd need to add the argument in all the various POM files (not an attractive proposition when dealing with a large, third-party project).
My thinking is that if I can automatically replace the old version of the plugin with the new version in the POM files, then I can use addScalacArgs and everything will work out well. I can probably cook up some code to do this (evidently doing it manually would be no better than going through and adding the argument), but it seems like the sort of thing that might be a supported Maven use-case.
Being specific, I'm trying to replace this plugin:
<plugin>
<groupId>org.scala-tools</groupId>
<artifactId>maven-scala-plugin</artifactId>
...
</plugin>
with this one:
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>scala-maven-plugin</artifactId>
...
</plugin>
You can do this with two profiles in your pom. One activate by default the other not. Then you can easily select which to use accordingly which profile you choose.
For exemple, here is a older post in the same spirit : How do I exclude a dependency in provided scope when running in Maven test scope?
When I run mvn site, the maven-project-info-reports-plugin is creating a folder in my project base folder called "${project.basedir}". My plugin is defined like so with no extra configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>${version.maven-project-info-reports-plugin}</version>
</plugin>
When this happens, the site generation gives me a warning:
[WARNING] The repository url 'file://${project.basedir}' is invalid -
Repository 'studio.repository' will be blacklisted.
Why is this oddly-named folder being created, and how can I prevent it from being created? What other configuration can I look at that might be related to this plugin?
UPDATE (the plugin is version 2.2, the latest as far as I know as of this writing)
There is a (dated) discussion in maven mailing list which looks related. The issue seems to be due to using repository mirrors.
You would want to try with the latest version of the plugin, as well as the workaround suggested, which is to set <dependencyLocationEnabled> to false.
I working with a project similar to the project described here.
So, it has a few modules in parent pom.xml:
<modules>
<module>../de.vogella.tycho.plugin</module>
<module>../de.vogella.tycho.feature</module>
<module>../de.vogella.tycho.p2updatesite</module>
</modules>
These modules have a general version number e.g. 1.0.0-SNAPSHOT or without -SNAPSHOT. The feature.xml file needs to contain the same version number:
<feature
id="com.my.feature"
label="My plugin feature"
version="1.0.0">
and:
<plugin
id="com.my.plugin"
download-size="0"
install-size="0"
version="1.0.0"
unpack="false"/>
The files category.xml (in p2 update-site projects) and MANIFEST.MF (in plugin projects) need to contain the same value.
The question is: How to automate the version number update process in all these files using Maven?
I tried to resolve this problem using maven-release-plugin and maven-versions-plugin. The first plugin makes a lot of unused actions (like making a lot of CVS commits, which I do not use in this project). The second plugin only makes changes in pom.xml files and do not modify feature.xml, category.xml and MANIFEST.MF, or I used it not so good.
There is a special tycho-versions-plugin for exactly this problem. It (intentionally) does the same as the maven-versions-plugin, but also updates the (redundant) versions in feature.xml and MANIFEST.MF.
Even more, the plugin also updates references which specify an exact version, like references to plug-ins in a feature.xml, or references to features in a category.xml. So in the end, all occurrences of the artifact versions are updated, like in a refactoring.
For references with exact versions, there is also an automatic update during the normal Tycho build. So if e.g. your feature references your plug-in in version 1.0.0.qualifier, this version string is updated with the actual value of the qualifier, e.g. 1.0.0.201207171147. You can make use of this functionality to minimize the number of places that need to be updated by the tycho-versions-plugin: Instead of specifying the current version literal in the reference, you can use the magic version 0.0.0. This version is also automatically updated to the latest version as part of the normal build.
I'd like to add some practical hints for less experienced maven users like me to Tobias Oberlies' answer:
The goal tycho-versions:set-version will change the version of all projects that are referenced from the master pom. The version strings of the maven configuration files (pom.xml) as well as the respective Eclipse/OSGi artifacts (MANIFEST.MF, feature.xml, category.xml) will be changed consistently.
To run the goal from the command line, use the following:
mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=1.2.0-SNAPSHOT
The newVersion user property, 1.2.0-SNAPSHOT in this example, is the new version to be set.
The above command line will use the latest version of the tycho-versions-plugin. If a certain version of the plugin should be used, the tycho-version-plugin needs to be added to the project/build/plugins element of the master pom.
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-versions-plugin</artifactId>
<version>${tycho-version}</version>
</plugin>
Replace ${tycho-version} with the current version of Tycho or define a property with that name and the appropriate value.