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!
Related
I'm running a multi-module maven project and have an unexpected behavior. First time I'm seeing this...
My parent module configures the install plugin, defining its classifier.
<plugin>
<artifactId>maven-install-plugin</artifactId>
<configuration>
<generatePom>true</generatePom>
<classifier>${env}</classifier>
</configuration>
</plugin>
<!-- ... -->
<modules>
<module>webapp-formation</module>
<module>db-formation</module>
</modules>
But when I'm running mvn install the .pom files are not generate for my modules. Only my parent is associated with a .pom file in my repositories. Thus trying to browse to my module's artifact on Archiva (after running mvn depoy of course!) it simply fails. I can browse to the parent but not its children.
So... I need to add the undocumented attribute generatePom to my plugin configuration to have the .pom files generated --copied would be a better word actually-- for all my modules. --I said undocumented attribute because this attribute is documented only for the install-file goal which is not the one ran by default. The install goal is not expecting that attribute...
Of course, if I do not configure my install plugin --so not configuring the classifier-- I have no problem and all .pom files are generated properly.
For you guys, is that a normal behavior? Something that you have already seen? Or should I just file a bug?
Thanks,
Olivier.
What you describe as an undocumented attribute is simply wrong, cause the attributes are specific on a goal base which means the given configuration will not change anything, cause the generatePom attribute is only valid for install-file goal. So you can remove it.
In general such configuration does not make sense, cause if you have different environments you should go a different way. Just removed hte configuration with <classifier>${env}</classifier> as well and try to deploy via:
mvn clean deploy
I need to store an artifact in Maven/Nexus but when it's pulled down it must not have a version number at the end.
Before you berate me, point your scowl at Oracle.
I have comm.jar (Oracle comm port driver). I've put this in my nexus server & it comes down as comm-1.0.jar. But the JAR contains the following code:
if(streamtokenizer.ttype == -3
&& (i = streamtokenizer.sval.indexOf("comm.jar")) != -1)
It's hard coded to use its own name to know where to find the configuration file that goes with it. The jar is signed so I can't make changes to it.
So... how to I store a jar in Nexus and not have an extension number on it ?
This isn't the exact answer to my question but it does solve my problem.
I called my jar "comm.jar-1.0.2.jar" The code looks for 'comm.jar' in the file name so now it finds it!
ok, so it a fudge and I'm lucky the internal code is just looking for indexOf. but it works!
Thanks to everyone for there advice on this!
Jeff
This isn't a complete answer, more a collection of thoughts on how you might approach this.
I think you will need to declare your dependency with the version number present, to ensure Maven is happy to resolve the artifact and build it. So, the trick will be ensuring the aritfact is renamed before it is bundled in your finished product.
The Maven dependency:copy-dependencies goal has a stripVersion parameter that might come in useful. I suspect you can use this to rename the JAR correctly, perhaps as part of an assembly (ensuring the depedency is moved to a directory that is part of the classpath).
Such a plan may well break your development environment, however. Perhaps you can get around that by fudging a JAR file with the right name?
If you want it to work with a war project then you can use the File Name Mapping to strip the version.
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<outputFileNameMapping>#{artifactId}#.#{extension}#</outputFileNameMapping>
</configuration>
</plugin>
</plugins>
</build>
The dependent jars will as normal end up in WEB-INF/lib but now without the version.
But from your question it is hard to tell what your end product is, war, jar, zip, ...
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.