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.
Related
When attempting to create a package for my ui.apps folder with maven I receive this error
data-sly-set: None of the registered plugins can handle the
data-sly-set block element.
I am indeed using the data-sly-set property like so
<sly data-sly-set.index="${mylist.count}"></sly>
And it does work on my local instance it just fails validation when packaging it.
I noticed that htl-maven-plugin was on version 1.0.6 if that is related.
The issue was that the version of htl-maven-plugin was too old. I resolved this issue by going into pom.xml and added
<version>1.3.4-1.4.0</version>
underneath
<artifactId>htl-maven-plugin</artifactId>
It ended up looking like this
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>htl-maven-plugin</artifactId>
<version>1.3.4-1.4.0</version>
</plugin>
After that it I ran
mvn -PautoInstallPackage clean install
and it built successfully. I also ran
mvn versions:display-plugin-updates
earlier to force it to update but I'm not entirely sure if that was necessary.
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!
I'm trying to run wro4j maven plugin according to the documentation
I add the plugin to my pom.xml:
<plugin>
<groupId>ro.isdc.wro4j</groupId>
<artifactId>wro4j-maven-plugin</artifactId>
<version>1.5.0</version>
</plugin>
and run the goal:
mvn wro4j:run -Dminimize=true -DtargetGroups=all
However the build fails with error:
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the pl
ugin manager executing goal 'ro.isdc.wro4j:wro4j-maven-plugin:1.5.0:run': Unable
to load the mojo 'ro.isdc.wro4j:wro4j-maven-plugin:1.5.0:run' in the plugin 'ro
.isdc.wro4j:wro4j-maven-plugin'. A required class is missing: org/codehaus/plexu
s/util/Scanner
Do you know how to avoid this error?
Since wro4j-1.5.0, the maven 3.0 is required to run the plugin. The reason is a feature called incremental build support which depends on a library which is not available on older version of maven by default.
The issue is on your local environment.
Go to this folder on my windows machine:${user.home}/.m2/repository, then delete everything in this folder. (Well you can keep a copy.)
After deleting, run the Maven command:mvn clean install -U.
See: https://groups.google.com/forum/#!topic/wro4j/ZPSFBQ_5lI8
My SCM connection information:
<scm>
<connection>scm:svn:https://repo/project/trunk</connection>
<developerConnection>scm:svn:https://repo/project/trunk</developerConnection>
</scm>
My release plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<tag>RC</tag>
<autoVersionSubmodules>true</autoVersionSubmodules>
</configuration>
</plugin>
Now when I run mvn release:prepare, instead of committing my tagged release under tags/RC, it does tags/RC/trunk. How do I stop it from adding trunk under RC?
Brian, you may be the victim of Maven's incomplete release:rollback feature. See my question on StackOverflow and the answer to it. If your tag already exists, Subversion (not Maven) will think you want to copy trunk inside the existing tag. Delete the tag and it will work - once. Try again and you'll get RC/trunk. Try yet again and you'll get an error from Subversion.
The solution is to svn delete the tag before you try to copy to it - we do this successfully from Maven during release:perform, by binding a couple of plugins to the deploy phase.
Basically:
Let release:prepare do its thing, create a tag with a unique name.
Bind org.codehaus.mojo:exec-maven-plugin:exec to the deploy phase to make it run during release:perform. Configure it to call svn delete <path to RC tag>.
Bind maven-scm-plugin:branch to deploy in order to create the tag fresh using Maven's SCM plugin.
This works for us and it has the added benefit that it gives us the unique tags too for reference. Worst case, you can ignore these tags.
Anyone not getting mvn site output? I was getting site output on my Macbook pro and I have deployed the site too. But tonight nothing works:
[INFO] --- maven-site-plugin:2.0.1:site (default-cli) # svs-utility ---
No reports or HTML generated
I think that with Raghuram advice you've already figured out, however, I saw this question today and I had the same problem. I'm learning Maven and I thought to document my steps here since it may be useful to someone else. I'm running Maven 3.0.1 and it was using version 2.0.1 of the plugin which doesn't work.
I found another question on stackoverflow explaining how to upgrade a Maven plugin.
As #andri said:
The default plugin versions are
inherited from the Super POM, and you
can check them with mvn
help:effective-pom.
I checked and it was indeed using 2.0.1 - I searched on http://search.maven.org/ for the latest version of site plugin and at the time of writing is 3.0-beta-3 (UPDATE 3.0 is out, I've updated the code below).
However #andri answer doesn't report the correct structure as in the super POM, while #Brian Fox answer does. Combining the two answers and the info found in the Maven repo, I added the following to my pom.xml
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-site-plugin</artifactId>
<version>3.0</version>
</plugin>
</plugins>
</pluginManagement>
</build>
With this change "mvn site" now works.
Now someone might ask, why Maven 3 ships with a plugin that doesn't work. It turns out that Brian Fox, a Maven developer has decided to lock down plugins to version 2. In general this seems a good idea for stability, however since backward compatibility is not honored, it becomes a very bad idea in this specific case. A plugin in super pom should work out of the box for the version it's packaged for. Either backward compatibility should be provided or it should be updated to the new version.
Maybe it will be fixed later, in the meantime the above workaround works. It's also a good idea to lock down the version of the plugin to the specific project.
Are you using maven 3? If so, you need to use the 3.x version of the site plugin