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.
Related
I'm currently on Liferay 6.2 (with Tomcat), and I can configure the liferay-maven-plugin in my Liferay hook project's maven pom.xml as below, in order to pre-process my hook WAR for hot deployment (using the direct-deploy goal of the plugin).
<plugin>
<groupId>com.liferay.maven.plugins</groupId>
<artifactId>liferay-maven-plugin</artifactId>
<version>6.2.1</version>
<executions>
<execution>
<id>pre-process-war</id>
<phase>package</phase>
<goals>
<goal>direct-deploy</goal>
</goals>
</execution>
</executions>
<configuration>
<appServerDeployDir>${project.basedir}/target/liferay-pre-process</appServerDeployDir>
<liferayVersion>6.2.1</liferayVersion>
<pluginType>hook</pluginType>
<unpackWar>false</unpackWar>
</configuration>
</plugin>
I'm now trying to migrate this hook to Liferay 7.2.1 CE. There is no plan to redesign this as an OSGI module at the moment i.e. it would continue to be packaged as a WAR. So how would my new direct-deploy configuration look like, with Liferay 7.2.1? Specifically:
a) Can I continue using the same Maven plugin? I see from this doc that the liferay-maven-plugin has been "removed", yet my understanding from other help pages is that this plugin should not be used only with the newer, OSGI-module style plugins (the latter makes more sense to me).
b) If I can continue using the same Maven plugin, which version of the plugin works with 7.2.1? Also, which liferayVersion value should I use here? I tried a bunch of combinations and none of them worked.
For instance, I first tried liferayVersion 7.2.1 but the build failed while running the direct-deploy goal, since Maven didn't find a com.liferay.portal:portal-web artifact with that version. So I tried the latest version of that artifact from Maven Central, which is 7.0.2, as my liferayVersion. But the build failed again, this time because it couldn't locate the corresponding version of com.liferay.portal:portal-service. There's no 7.x version of portal-service though, which makes sense because it's been replaced with the portal-kernel artifact. Not specifying liferayVersion doesn't work either.
I received a response in a Liferay forum which suggests that the liferay-maven-plugin has indeed been removed in Liferay 7.x, and so the only option left is to copy the WAR to Liferay's deploy folder and let it do the pre-processing at deploy time (as opposed to doing this at build time, with the Maven plugin). Given the lack of alternatives at this point, that seems to be the only way forward (and it works).
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>
TL;DR: I stumbled upon a situation where my pom.xml works fine on Windows, but fails on Linux. Since I'm rather new to maven, I'm not sure whether it's a common situation, or if I messed up somewhere.
More details:
I use the maven-download-plugin like this:
<plugin>
<groupId>com.googlecode.maven-download-plugin</groupId>
<artifactId>maven-download-plugin</artifactId>
<version>1.1.0</version>
<executions>
<execution>
<id>get-stuff</id>
<phase>generate-sources</phase>
<goals>
<goal>wget</goal>
</goals>
<configuration>
<url>http://myUrl/my.tar.gz</url>
<unpack>true</unpack>
<outputDirectory>${project.build.directory}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
On Windows it works like a charm (ie: it downloads and unpack).
On Linux, it fails with the following error:
[ERROR] Failed to execute goal com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget (get-moab)
on project my-project: Execution get-stuff of goal com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget failed:
An API incompatibility was encountered while executing com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget: java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.Commandline.createArg()Lorg/codehaus/plexus/util/cli/Arg;
I found a workaround (<unpack>false</unpack>, and then "manually" unpack with antrun), but my pom.xml looked better without those additional 15 lines...
To put it in a nutshell:
Is it actually a portability issue, or have I messed up somewhere?
If it's an portability issue: is it common with maven, or am I unlucky on this one?
More technical details:
I used the same plugin both on Linux and Windows (same version, same maven repository)
It failed on a Centos, and a VM with Ubuntu 12.04
My first troubleshooting step when a build works on one machine and not another is to clean out the local Maven repository on the failing machine, and let Maven re-download all of the artifacts. That's often enough to fix the problem.
If the build fails with the same error, then I clean out the local repository on the working machine and build. Usually then I see that I've missed a dependency in the POM that just happened to exist in my local repository already. Fixing the POM often makes the build work on both systems.
Did you check the Maven versions (mvn -version)? org.codehaus.plexus.util is a dependency of Maven Core, so if maven-download-plugin is running under a different version of Maven it was compiled for, this would explain the error.
The instructions here seem very clear:
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
However, the first problem I run into is that the dependencies are wrong. I also needed to reference the maven-plugin-annotations dependency.
Then, when I attempt to run I get the "No plugin descriptor found at META-INF/maven/plugin.xml" error. I haven't figured out what to do about that.
I've found lots of pages referencing the maven-plugin-plugin, but I can't figure out how to add it to the pom so that it actually does anything which allows my own plugin to run.
Is there an updated version of the plugin development instructions which actually mentions the need to use maven-plugin-plugin?
If I can't get this to work I'm just going to go back to using exec-maven-plugin. It's uglier, but at least it works easily.
There are actually several terrific resources from Sonatype for learning how to write plugins:
Maven the Complete Reference: Writing Plugins
Maven Cookbook: Creating an Ant Maven Plugin
Maven Cookbook: Writing Plugins in Groovy
If I recall correctly, you need to configure the maven-plugin-plugin this way to avoid the "No plugin descriptor found..." issue.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-plugin-plugin</artifactId>
<version>3.2</version>
<configuration>
<!-- see http://jira.codehaus.org/browse/MNG-5346 -->
<skipErrorNoDescriptorsFound>true</skipErrorNoDescriptorsFound>
</configuration>
<executions>
<execution>
<id>mojo-descriptor</id>
<goals>
<goal>descriptor</goal>
</goals>
</execution>
</executions>
</plugin>
I forked a simple GitHub project called maven-wrapper (port of the Gradle wrapper) to make it a Maven plugin.
"It should be easy" for you to figure out pieces that you may eventually be missing:
Maven wrapper plugin(Mojo)
Maven Wrapper full POM
I have a question that's probably pretty similar to this. I need to solve what I have to imagine to be a pretty common problem -- how to configure Maven to produce multiple variations on the same artifact -- but I have yet to find a good solution.
I have a multi-module project, that eventually results in the assembly plugin generating an artifact. However, part of the assembly includes libraries that have changed substantially in the recent past, with the result that some consumers of the project need library version N, while others need version N+1. Ideally, we'd just automatically generate multiple artifacts, e.g. theproject-1.2.3.thelib-1.0.tar.gz, theproject-1.2.3.thelib-1.1.tar.gz, etc. (where that's release 1.2.3 of our project, running against either library version 1.0 or 1.1).
Right now, I have a bunch of default properties, which build against the latest version of the library in question, plus a profile to build against the older version. I can deploy one or the other this way, but cannot deploy both in one build. Here's the key wrinkle that differs from the above question: I can't automate build-one-clean-build-the-other inside of the release plugin.
Normally, we'd mvn release:prepare release:perform from the root of the multi-module project to take care of deploying everything to our internal Nexus. However, in that case, we have to pick one -- either run the old-library profile, or run without and get the new one. I need the release plugin to deploy both. Is this just impossible? I have to imagine we're not the first people who want to have our automated builds generate support for different platforms....
You may install additional artifacts with differrent types/classifiers. Use attach-artifact goal of the build-helper-maven-plugin to achieve this. Here is a small example - we are deploying a Windows and a Unix installers of the product as windows/exe and unix/sh files. These files will be installed to the local repo and deploy to the distribution management.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>install-installation</id>
<phase>install</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${basedir}/target/${project.artifactId}-${project.version}-windows.exe</file>
<classifier>windows</classifier>
<type>exe</type>
</artifact>
<artifact>
<file>${basedir}/target/${project.artifactId}-${project.version}-unix.sh</file>
<classifier>unix</classifier>
<type>sh</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
Hope this helps.