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>
Related
Thanks in advance! I am new to Jenkins and Maven. Please clarify my query for better understanding.
After the build war getting deployed from Jenkins system to Artifactory location (created under the tags <distributionManagement>/<snapshotRepository> in parent pom.xml). How this is happening without any scripts configured in Jenkins?
Can I do the same for my own archive file to place in Artifactory from Jenkins system after the build? I exposed some jars and getting archived in Jenkins system during the build and expecting same to be placed in Artifactory after the build same as how war is getting placed in Artifactory.
PLugin details for deploy:
I have many webapps and parent/super pom.xml.All wars are getting deployed in artifactory repository.Now looking for solution to deploy common folder also (ProvidedDependencies_${version} - Created during build time) .
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.6</version>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
<repositoryId>artifactory</repositoryId>
<generatePom>true</generatePom>
<url>${project.distributionManagement.snapshotRepository.url}</url>
<artifactId>${project.artifactId}</artifactId>
<groupId>${project.groupId}</groupId>
<version>${project.version}</version>
<file>/ProvidedDependencies_${version}</file>
</configuration>
</plugin>
Invoking mvn deploy deploys the artifact(s) that has (or have) been built during the current run to your local repository, Artifactory in your case. See Introduction to the Build Lifecycle.
A Jenkins Maven 2/3 project or a Free-style software project with an appropriate build step can be configured to invoke mvn deploy.
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
I'm trying to use the SoapUI Maven plugin as shown here: http://www.soapui.org/Test-Automation/maven-2x.html
I can't add the eviware repository, since I'm behind a corporate firewall (only the browser can connect to the outside world) and have to use the local artifactory repo (which mirrors maven central).
So I tried downloading the appropriate jars and poms from the eviware repo and adding them to the local artifactory. Now it seems I've gone down the rabbit hole, the SoapUI plugin has more and more dependencies that I need to add. At first I didn't mind, but we're looking at tens of jars now, and most of them seem to be things that should be in maven central. But then I saw that most of these have altered group-IDs - for example there is a jetty dependency that uses "jetty" as group-ID instead of the canonical "org.mortbay.jetty". And this seems to be the case for many of these dependencies.
So my question has two sides: What are the SoapUI folks doing here? This seems fishy to me, or am I overlooking something?
And second, can I somehow make the plugin use the canonical jars instead of having to chase all the stuff that's in eviware's repository?
Have a look on this soapui forum, I explain why soapui uses weird maven coordinates and what could be done to use regular ones.
I have already complained about the problem on this post and I am sure that SoapUI dev are aware of the problem. Sadly, there is no current work to fix it.
I have tried relentlessly to use the maven-soapui-plugin, but It didn't work for me. However the maven-soapui-extension-plugin mentioned by pppeater and developed by redfish above has worked fine when I tried it. I have used artifactory as my repo manager.
First configure the plugin on your pom
<plugin>
<groupId>com.github.redfish4ktc.soapui</groupId>
<artifactId>maven-soapui-extension-plugin</artifactId>
<version>4.6.3.0</version>
<executions>
<execution>
<id>soapui-tests</id>
<phase>verify</phase>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<projectFile>${basedir}/src/test/soapui/airline-sample-soapui- project.xml</projectFile>
<outputFolder>${basedir}/target/soapui</outputFolder>
<junitReport>true</junitReport>
<exportwAll>false</exportwAll>
<printReport>false</printReport>
</configuration>
</plugin>
You still need to add the soapui plugin to your repo manager remote repositories and virtual repositories list using the url http://www.soapui.org/repository/maven2/
Just came across this plugin: https://github.com/redfish4ktc/maven-soapui-extension-plugin which notes: "starting from soapui 3.6.1, almost all SmartBear plugin versions have missing dependencies. This is fixed in maven-soapui-extension-plugin"
It also appears to address some Groovy dependencies which others have noted as an issue with the plugin.
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.
I am new to JBOSS AS7, and am strictly using MAVEN 3 via command line. I would like to deploy the *.war of my project to JBOSS AS7 without ECLIPSE. I have spent couple of days Googling and trying out difference approaches. I am able to deploy the *.war to Tomcat. I would highly appreciate any help on this. So far this is what I have done:
I have entered the server info(Jboss) to C:\maven\conf\settings.xml
I have included the plugin to the POM
I think I may be declaring the path to JBoss AS7 within my JBOSS plugin wrong.
This is how I am including the plugin in the POM file:
<plugins>
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.0.2.Final</version>
<configuration>
<url>http://localhost:8080/
<server>jboss</server>
<path>/web-app</path>
<configuration>
</plugin>
</plugins>
Did you have a look at the README on the corresponding GitHub page:
https://github.com/jbossas/jboss-as-maven-plugin
When deploying to your localhost (which is the default value) you don't need to define the <url> in the <configuration>, as well as the <server> and <path> elements (besides: I haven't seen a folder named wep-app in AS7).
We run a project where this works even without touching the settings.xml.
So when you have checked this, post what exactly goes wrong, what is the concrete failure message and what is the maven command you use (mvn jboss-as:deploy).