I have small maven project. I'm trying to add generating site by maven-site-plugin, but it doesn't work. When I'm building this project i get following error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project server-wms-product: SiteToolException: The site descriptor cannot be resolved from the repository: ArtifactResolutionException: Unable to locate site descriptor: Could not transfer artifact [PARENT-PROJECT]:xml:site_en:1.0.141.1 from/to eclipse (http://maven.eclipse.org/nexus/content/repositories/testing/): Connection to http://maven.eclipse.org refused
My project is extension for other project, so in my pom.xml is set parent project which isn't mine and I can't add site configuration there.
So is there any chance to skip checking parent project's site in site generation?
My pom.xml looks like this:
<project>
<parent>
<artifactId>base-server-product</artifactId>
<groupId>XXXXXXXXXXXx</groupId>
<version>1.0</version>
</parent>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.3</version>
<configuration>
<reportPlugins>
</reportPlugins>
</configuration>
</plugin>
</plugins>
</build>
</project>
And of course i have site.xml file in src/site.
Configure attaching the site descriptor to the artifacts in the parent pom.
<project>
<artifactId>base-server-product</artifactId>
<groupId>XXXXXXXXXXXx</groupId>
<version>1.0</version>
...
<build>
<plugins>
<plugin>
<artifactId>maven-site-plugin</artifactId>
<executions>
<execution>
<id>attach-descriptor</id>
<goals>
<goal>attach-descriptor</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
Core functionality has been separated from site generation in maven 3. You can find the reasons here. If you want to refer to the parent module's site from the submodule, you have to attach the site.xml to the deployed artifacts.
I have the exact same problem, and after much googling, came across this article which solved my problem:
http://amanica.blogspot.com/2010/08/archiva-gives-maven-site-plugin-invalid.html?m=1
Basically you want to add a basic site_en.xml to /src/site/ folder in your parent pom.xml.
For a reason I can't fathom, with me, it was enough to run maven in offline mode once.
I came across this question when working on an open source project I don't own where I wanted to submit an update to a site being generated in this manner. I wanted to test and view the change locally, but kept hitting this error.
User #Frischling alluded to this above (credit to them). It turns out what I wanted was not to edit any existing information or update any pom.xml files, but just build entirely in offline mode.
I was trying to run this command and it was failing with the error the original poster mentioned:
mvn site
To do this build offline instead, execute the following commands:
# Download the dependencies for the target
mvn dependency:go-offline site
# Build the target offline
mvn --offline site
Then the output got correctly generated to the target/site directory like I expected.
It's not ideal if you own the project or part of the project, but for a case like mine where I owned none of it, it was the perfect option.
The previous answers didn't work for me.
But Mark's one, here, solved the issue I had: https://stackoverflow.com/a/57429991/5056068
Etienne
Related
I have a pomless tycho build which I want to release with the maven release plugin. The issue I have is that I get errors from the git plugins for the generated .polyglot.build.properties even though it is not included in the configuration of the git-add goal.
Parent pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<autoVersionSubmodules>true</autoVersionSubmodules>
<localCheckout>true</localCheckout>
<preparationGoals>
org.eclipse.tycho:tycho-versions-plugin:${tycho.version}:update-eclipse-metadata
build-helper:parse-version
org.apache.maven.plugins:maven-scm-plugin:1.9.5:add
org.apache.maven.plugins:maven-scm-plugin:1.9.5:checkin
</preparationGoals>
<completionGoals>
org.eclipse.tycho:tycho-versions-plugin:${tycho.version}:update-eclipse-metadata
build-helper:parse-version
org.apache.maven.plugins:maven-scm-plugin:1.9.5:add
org.apache.maven.plugins:maven-scm-plugin:1.9.5:checkin
</completionGoals>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-scm-plugin</artifactId>
<version>1.9.5</version>
<executions>
<execution>
<id>default-cli</id>
<goals>
<goal>add</goal>
<goal>checkin</goal>
</goals>
<configuration>
<includes>**/META-INF/MANIFEST.MF,**/feature.xml,**/*.product,**/category.xml,release.properties</includes>
<excludes>**/target/**</excludes>
<message>Changing the version to reflect the pom versions for the release</message>
<pushChanges>false</pushChanges>
</configuration>
</execution>
</executions>
</plugin>
The error I get:
fatal: pathspec 'my.plugin/.polyglot.build.properties'
did not match any files
After looking at the source code of tycho-pomless, polyglot, and maven-release, I conclude pomless build can't work with maven release. I need to add pom.xml
The reason is:
tycho-pomless uses polyglot, which creates an temporary pom from the build.properties, which is deleted when the JVM exits
maven release:prepare spawns a child maven process to execute the preparation goals. When the child process finishes, this deletes the temporary files. The available mavenExecutorId values are "invoker" which invokes a new process, and "forked", which forks the process. Which means both spawn a new JVM.
So in conclusion, it looks like tycho-pomless (or any polyglot build, really) and maven-release are incompatible in the presence of preparation goals, and there seems to be no workaround. The possible workaround of executin the preparation goals in the same JVM seems to be unavailable. So the solution is adding a pom.xml
Check first is this is similar to this question, where the plugin does finds the files it should add, but, when creating the command line, it does not respect the correct root directory.
See if the path mentioned in pathspec 'my.plugin/.polyglot.build.properties' the correct one.
Double-check if your POM and folder hierarchy is at the right place, meaning in the project root folder.
The OP kutschkem refers in the comments to:
the .polyglot.build.properties is a temporary file, deleted by the release:prepare child process exit.
But release plugin picks it up as the pom of the project to checkin.
That might be why I see in Tycho/Reproducible Version Qualifiers
<jgit.ignore>
pom.xml
.polyglot.build.properties
</jgit.ignore>
I have a java application that is in git repo RepoA and has a scm configuration set up for this repo for maven-release plugin etc.
I want to fetch one file from another RepoB (it is fine to checkout the whole repo also because there is only 1 file there) and use it as a part of build step.
How to do it with maven-scm plugin if scm section is already set up for RepoA?
Thanks.
You can use a separate maven profile for this task.
Here's profile part from pom.xml, assuming that you want to fetch file foo/bar.txt from github repo github-user/some-repo:
<profile>
<id>checkout-foo-bar</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-scm-plugin</artifactId>
<version>1.11.2</version>
<configuration>
<connectionUrl>scm:git:git#github.com:github-user/some-repo</connectionUrl>
<includes>foo/bar.txt</includes>
</configuration>
</plugin>
</plugins>
</build>
</profile>
Then run mvn scm:checkout -P checkout-foo-bar
Plugin first fetches all the files from repo and then removes ones that you don't need. This takes extra time, especially if the repo is huge.
I didn't find a way to setup output directory other than default target/checkout. But hopefully this working example can be a good starting point to solve a problem.
I am trying to deploy an Eclipse product to Nexus repository. I am somewhat successful, but still get some errors that I am not sure how to handle.
I am using maven-deploy-plugin in the feature (F) that builds product:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
<repositoryId>snapshots</repositoryId>
<packaging>zip</packaging>
<generatePom>true</generatePom>
<url>http://repo:8081/nexus/content/repositories/snapshots</url>
<groupId>my.group</groupId>
<artifactId>my.artifact</artifactId>
<version>1.0.0-SNAPSHOT</version>
<file>
target/products/product.zip
</file>
</configuration>
</execution>
</executions>
</plugin>
I execute 'mvn clean install' to build the product and then 'mvn deploy' on F. If I do that then I get error
Exception while publishing product /home/akravets/dev/workspaces/trunk/my.repository.feature/myProduct.product: publishing result: [Included element my.product.feature.feature.group 8.0.1.R20180301-1431 is missing. Cannot determine filter for requirement to this element.] -> [Help 1]
I've read discussions about this issue, but nothing seems relevant to my issue because I don't have any defined deploy phases besides the one in maven-deploy-plugin.
If I change phase of maven-deploy-plugin to 'install' I get almost satisfactory results. The zip file and generated pom get deployed to repository, but the build fails with error
product.qualifier-p2artifacts.xml. Return code is: 400, ReasonPhrase: Bad Request.
Why does this file even gets considered to be deployed to repository when it's not in file element of maven-deploy-plugin and it's not in the directory structure where zip file is: target/ vs target/product/product.zip? Is this because maven-deploy-plugin is executed during the install phase and it picks up all generated resources as candidates for deployment?
I simply recommend you to use Maven-Tycho to deploy Eclipse RCP product.Tycho determines the dependencies of a plug-in via the MANIFEST.MF file of the plug-in and fetches the required plugins-bundles through the online repositories.
You can check this git repository as an example; rcp - tycho
I am a newbie trying to deploy artifacts to maven central for the first time. I followed the directions to configure maven to deploy to a staging repository. The maven build reports success. When I go to look for my staging repository, I don't see it. When I search for my artifact by searching for "markgrand" the artifact is found.
The group ID is com.markgrand, so I am expecting to see a staging repository with a names that begins with "commarkgrand-", but there is none. What am I doing wrong?
It's been awhile, so I do not remember the exact detail. The problem was that I had told the maven plugin to do too much. I think i had a step in there to close the thing, which made it no longer a candidate for deployment. Here is the staging plugin XML that is working for me:
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.8</version>
<extensions>true</extensions>
<configuration>
<serverId>ossrh</serverId>
<nexusUrl>https://oss.sonatype.org/</nexusUrl>
</configuration>
</plugin>
I can not make the maven-release plugin work with Perforce. The release:prepare seems to work correctly: a Perforce label is created and it contains the correct files. Yet when I run release:perform it fails because the target/checkout directory is empty.
I've done some experiments. If I only sync to my pom.xml and then run
mvn scm:checkout
then my other files are checked out into the P4 root directory just as if I had done a
p4 sync ...
Yet Maven outputs
[INFO] Checkout working directory: /home/chris/perforce/pips/target/checkout
[INFO] sync -f //depot/pips/...
Maven thinks it's checking out the target/checkout but it is not. I dug into the P4Maven code a little bit and noticed this in P4Executor.java
public String getRepoPath(P4ScmProviderRepository repo, File basedir) {
// Handles a case where executing release:prepare on a module with an
// invalid SCM location. The release.properties contains the invalid URL
// for checkout during release:perform and the basedir is not the module
// root. So, the trailing target/checkout directory must be removed.
if (basedir.toString().replace('\\', '/').endsWith("/target/checkout")) {
String dir = basedir.toString();
basedir = new File(dir.substring(0, dir.length()
- "/target/checkout".length()));
if (getLogger().isDebugEnabled()) {
logger.debug("Fixing checkout URL: " + basedir);
}
}
This code is pretty clear. P4Maven won't check things out to target/checkout. If you tell it to checkout to target/checkout it will simply remove the "target/checkout" and checkout to the root directory. This is consistent with what I see being done. I also see the "Fixing checkout URL" message when I run release:perform
How then do people work around this?
Below is my pom.xml. I am using
Perforce Server version: P4D/LINUX26X86_64/2014.2/935585 (2014/09/16). p4d is running locally. Authentication is disabled and I don't need a password.
Nexus 2.10.0-02 running locally.
Ubuntu Linux.
Maven 3.2.3
java 1.7.0_55
Thanks.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.ap
ache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.icap</groupId>
<artifactId>pips</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>pips</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<scm>
<connection>scm:p4:192.168.1.8:1666://depot/pips</connection>
<developerConnection>scm:p4:192.168.1.8:1666://depot/pips</developerConnection>
</scm>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-scm-plugin</artifactId>
<version>1.4</version>
<dependencies>
<dependency>
<groupId>com.perforce</groupId>
<artifactId>p4maven</artifactId>
<version>[2011,2012)</version>
</dependency>
</dependencies>
<configuration>
<connectionType>connection</connectionType>
<username>chelck</username>
<includes>**</includes>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.1</version>
<dependencies>
<!-- P4Maven -->
<dependency>
<groupId>com.perforce</groupId>
<artifactId>p4maven</artifactId>
<version>[2011,2012)</version>
</dependency>
</dependencies>
<configuration>
<connectionType>connection</connectionType>
<username>chelck</username>
<includes>**</includes>
</configuration>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<fork>true</fork>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<distributionManagement>
<repository>
<id>deployment</id>
<name>Internal Releases</name>
<url>http://localhost:8081/nexus/content/repositories/releases/</url>
</repository>
<snapshotRepository>
<id>deployment</id>
<name>Internal Releases</name>
<url>http://localhost:8081/nexus/content/repositories/snapshots/</url>
</snapshotRepository>
</distributionManagement>
</project>
I have struggled for several days on perforce / maven / release integration and finally got it working. Here are my findings, they might help you and others with similar issues.
Do not use the perforce plugin as described on perforce.com (http://www.perforce.com/perforce/r11.1/manuals/p4maven/index.html). Although it is the first link to come out of a search on google, my understanding is that this plugin is outdated.
In your configuration, if you refer to scm:p4:... you are using the com.perforce plugin. Instead, use org.apache.maven.scm/maven-scm-provider-perforce which uses scm:perforce:... syntax. Your <scm> should look like this:
<properties>
<p4path>//perforce-path/toyour/project</p4path>
</properties>
<scm>
<connection>scm:perforce:yourp4server:1666:${p4path}</connection>
<developerConnection>scm:perforce:yourp4server:1666:${p4path}</developerConnection>
<url>perforce:yourp4server:1666:${p4path}</url>
</scm>
The newer plugin does not require username/password, it will use your active P4 credentials.
I am using maven 3.2.5 and did not have to specify any plugin dependency. The built-in scm recognized the :perforce: scm and downloaded maven-scm-provider-perforce 1.9.2 which is the latest as of this writing. You can make sure you are using an up to date plugin by deleting the maven-scm-provider-perforce folder in .m2\repository\org\apache\maven\scm and then doing a mvn scm:status - it will download the missing plugin and you can see which one it picked.
Here is my maven-release-plugin definition:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.1</version>
</plugin>
I do not have a maven-scm-plugin definition in my pom (I used the default settiings from the superpom).
Test on a non-module project.
You should be able to do the following without error:
- mvn scm:status to check that your scm setup is working correctly
- mvn release:prepare
- mvn release:perform
If you get errors, rollback (mvn release:rollback), make sure everything is back to normal, and rerun with mvn -X to get more details.
In my case, a non-modular project worked without much trouble.
Test on the parent of a reactor project.
There are a few things that were not obvious to me at first and that I found out:
When the is defined in the parent pom, the child module name gets appended to the path for the child module. If your child is not physically under the parent (in my case, it was beside), you need to redefine a configuration in the child pom. In my case, I was using a property (p4path above), simply changing its value was not enough. This was counter-intuitive since the parent pom is normally just a "include", and I expected the parent definitions to be "copy-pasted" in the child module, but in this particular case, it is modified to include the module name at the end of the scm path when it is copy-pasted. [More on modules that do not sit under the parent directory below]
A temporary client spec is created by the perforce scm plugin. This was also counter intuitive, I expected the scm plugin to use my current client-spec. Instead, it will create a new one on the fly, and populate it with the path you provided only and name it username-hostname-MavenSCM-localpath. I was initially surprised by that and tried to change it so it would use by client-spec by customizing the maven.scm.perforce.clientspec.name property, this behaviour was actually correct. With this temporary client-spec, the plugin can limit the lookup for changes, the submit and tagging to this directory. It also makes it easy to track what was done by this plugin in the perforce history.
Creation of the temporary client spec will fail if the modules are not under the parent directory. As I described above, my modules were sitting beside the parent. My <module> tag in the parent pom referred to them using <module>../mymodule</module> which worked fine in eclipse for everything else. The scm perforce plugin includes modules in the client spec by appending the path to the module to the path of the parent. Since Maven resolves the ../ to an absolute path, the client spec ends up containing something like this: //perforce-path/toyour/project/C:\Path\To\Your\Project/mymodule/ and the client spec fails. I could not find a work around for this issue other than moving my modules under their parent. Since the client spec was invalid, I had no file being checked-out under target/checkout. You will get the content of your generated client spec on the console by using mvn -X when invoking release:perform.
Moral of the story: You want to make sure that all your modules sit under their parent directory. When you do this, everything becomes simple and magical: you can leave the declaration in your parent pom and the module path gets magically appended for the module scm paths. You can refer to your modules using <module>mymodule</module> which gets correctly appended in the client-spec. Tagging of the parent in perforce ends up also tagging the modules since they are contained within.