ipastusi/wiremock-maven-plugin

WireMock Maven Plugin

wiremock-maven-plugin's Issues

Xalan dependency broke maven-bundle-plugin

version 4.4.1+ with Xalan dependency included (#41) cause maven-bundle-plugin failure [1]

pom.xml.txt

1. Exception in thread "main" javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found
   at java.xml/javax.xml.transform.FactoryFinder.newInstance(FactoryFinder.java:177)
   at java.xml/javax.xml.transform.FactoryFinder.find(FactoryFinder.java:212)
   at java.xml/javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:126)
   at org.apache.felix.bundleplugin.BlueprintPlugin.getTransformer(BlueprintPlugin.java:384)
   at org.apache.felix.bundleplugin.BlueprintPlugin.(BlueprintPlugin.java:67)
   at aQute.bnd.osgi.Processor.loadPlugin(Processor.java:820)
   at aQute.bnd.osgi.Processor.loadPlugins(Processor.java:653)
   at aQute.bnd.osgi.Processor.getPlugins(Processor.java:575)
   at aQute.bnd.osgi.Processor.getPlugins(Processor.java:516)
   at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:874)
   at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:239)
   at aQute.bnd.osgi.Builder.analyze(Builder.java:408)
   at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:909)
   at aQute.bnd.osgi.Builder.build(Builder.java:118)
   at org.apache.felix.bundleplugin.BundlePlugin.buildOSGiBundle(BundlePlugin.java:940)
   at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:443)
   at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:364)
   at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
   at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
   at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
   at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
   at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
   at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
   at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
   at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
   at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
   at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
   Caused by: java.lang.ClassNotFoundException: org/apache/xalan/processor/TransformerFactoryImpl
   at java.base/java.lang.Class.forName0(Native Method)
   at java.base/java.lang.Class.forName(Class.java:398)
   at java.xml/javax.xml.transform.FactoryFinder.getProviderClass(FactoryFinder.java:122)
   at java.xml/javax.xml.transform.FactoryFinder.newInstance(FactoryFinder.java:165)
   ... 38 more

plugin failing to run

Mac 10.14.4 / Jdk 1.8.0_192 / Maven 3.6.0
POM parent is spring-boot 1.5.17.RELEASE
Plugin: 4.4.0

Added plugin as per README

Project uses Saxon: 9.1.0.8

Plugin execution failing ; see attached stacktrace

junits use XPaths and {cargo-maven2-plugin, soapui-maven-plugin} plugins run, so pom looks OK.

wiremock-plugin-stacktrace.txt

Plugin DependencyManagement overrides Wiremock dependencies

Version 5.0.0 of your excellent plugin (thanks for all your work) promises to be decoupled from the WireMock version itself. However, the plugin's POM still contains a dependencyManagement section that overrides some of WireMock's own dependencies (e.g. the asm 7.0 dependency from WireMock 2.25.1 is overwritten with version 5.2 in release 5.0.0 of the plugin).

Is there any particular reason why the plugin manages some of WireMock's transitive dependencies?

Allow to suppress lines about classpath artifacts

Plugin produces a lot of output to the console with names of artifacts that are included in the classpath:

$ mvn wiremock:run
[INFO] --- wiremock-maven-plugin:2.13.0:run (default-cli) @ mystamps ---
[INFO] Adding /Users/coder/git/mystamps.git/target/test-classes to wiremock-maven-plugin classpath
[INFO] Adding /Users/coder/git/mystamps.git/target/classes to wiremock-maven-plugin classpath
[INFO] Adding /Users/coder/.m2/repository/com/github/heneke/thymeleaf/thymeleaf-extras-togglz/2.0.1.RELEASE/thymeleaf-extras-togglz-2.0.1.RELEASE.jar to wiremock-maven-plugin classpath
[INFO] Adding /Users/coder/.m2/repository/org/thymeleaf/thymeleaf/3.0.9.RELEASE/thymeleaf-3.0.9.RELEASE.jar to wiremock-maven-plugin classpath
[INFO] Adding /Users/coder/.m2/repository/ognl/ognl/3.1.12/ognl-3.1.12.jar to wiremock-maven-plugin classpath
...
$ mvn wiremock:run | grep -c 'Adding .* to wiremock-maven-plugin classpath'
72

Does it really useful information? Could it be suppressed at all? Otherwise, could you introduce an option for that?

Thanks!

Pipeline as a code improvements

Improve both Jenkinsfiles:

• reuse code where possible
• consider using mvn:dependency:purge-local-repository to ensure fresh environment on every run (we don not want old versions of our artifacts to be in local maven repository)
• introduce DRY_RUN param for release Jenkinsfile: if set to true, don't do mvn deploy or git push (skip 2 stages)
• research alternatives for mvn:dependency:purge-local-repository not always working as expected
• try to merge both Jenkinsfiles into one, with release part parameterised with Jenkins job parameter

Declarative pipeline and git push

Verify if migration to Jenkins Declarative Pipeline didn't break git push. The likes are it did.

Add support for skip configuration

Hi, I don't see a way of setting up the plugin to be skipped. If the plugin is part of the integration test phase, it would be nice if it also respected the failsafe skipITs property or perhaps allowed a way for it to be configured. Thanks.

Migrate to Groovy

Migrate plugin to Groovy

Plugin doesn't work for Maven < 3.5.4

Due to recent project migration to Scala, plugin no longer works for pre-3.5.4 Maven versions:
The plugin net.alchim31.maven:scala-maven-plugin:3.4.2 requires Maven version 3.5.4
This is causing obvious problems for those who need to use older Maven version, for any reason.

Can't handle root directory with space in path

A project with a path containing a space causes WireMock to load with an incorrect root directory.

This may happen for a project without spaces in the path but with

parameter with a space though (not verified).

Running plugin outside of integration test

When following the instructions and running mvn verify the wiremock instance if started properly with the params specified in the pom.xml. But when running just: mvn wiremock:run it seems to start a wiremock instance on port 8080, which I assume is the default one, so it seems it is ignoring the params in the pom.xml. How do I start a wiremock instance which is configured in my pom.xml:

<plugin>
	<groupId>uk.co.deliverymind</groupId>
	<artifactId>wiremock-maven-plugin</artifactId>
	<version>2.3.0</version>
	<executions>
		<execution>
			<goals>
				<goal>run</goal>
			</goals>
			<configuration>
				<dir>target/classes</dir>
				<params>--port=9923 --verbose --local-response-templating</params>
			</configuration>
		</execution>
	</executions>
</plugin>

Doesn't work in a multi-module build

Suppose I have two modules in my build structure. Both modules want to start up a wiremock instance. This doesn't presently work. It looks like the plugin assumes that the termination of maven will cause termination of the running instance. However when you have a multi module, you may want to have distinct wiremocks running (may or may not share port, in my case they're sharing port). It seems a little ugly to require the second server to run on a different port, and they both end up running for the test duration as a result.

Would be good if instead the plugin could shutdown the created server in a post step.