I am trying to start an embbeded soapui mock webservice using the maven-soapui-pro-plugin plugin.
This works perfectly on my local machine but will obviously crash on the continuous integration plateforme as the project file references a wsdl on the local filesystem.
Therefore I have four options:
1/ Find a way to pass the wsdl file location as a parameter.
2/ Change this reference to an HTTP (which means I have to install an Apache server)
3/ Manualy change the references to the wsdl in the project file.
4/ Replace that plugin by an other one
<plugin>
<groupId>eviware</groupId>
<artifactId>maven-soapui-pro-plugin</artifactId>
<version>4.5.0</version>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.6</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-test-resources</phase>
<goals>
<goal>mock</goal>
</goals>
<configuration>
<projectFile>D:\Documents and Settings\jhagai\Bureau\Toto-soapui-project.xml</projectFile>
<mockService>MockService</mockService>
<port>8888</port>
<path>/test</path>
<noBlock>true</noBlock>
</configuration>
</execution>
</executions>
</plugin>
I feel like I am the only person facing this issue is it possible?
First off you don't actually need the wsdl file on the CI server. There are several tests in on our CI server that do not point to a wsdl file. SoapUI uses the wsdl file to generate the project and sample requests, but if you run the test without it and your test is configured properly, it shouldn't fail. We have implemented number 2 that you have listed, but this is so testers don't need to generate the wsdls themselves.
The problem I see above is the hard coded project file. You should be able to handle this by saving your project in your maven project and pointing to it there (map to it based on the location of the POM).
Related
I'm using Documents4j to convert an rtf file to pdf file. I don't have MS word or anything on my computer, so it seems that I will need to use a remote converter. Information here: http://documents4j.com/#/.
My project is setup with spring-boot. I went through and set up shading for maven using maven-shade-plugin based on some issues on GitHub. However, I cannot run the command that Documents4j suggests to get the server running:
java -jar documents4j-server-standalone-shaded.jar http://localhost:9998
I get:
Error: Unable to access jarfile documents4j-server-standalone-shaded.jar.
My pom.xml file brings in the shade plugin.
Here is the plugin in my pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
</configuration>
</execution>
</executions>
</plugin>
Here are the dependencies I am using in regards to Documents4j: (perhaps something important is missing?)
<dependency>
<groupId>com.documents4j</groupId>
<artifactId>documents4j-api</artifactId>
<version>1.0.3</version>
</dependency>
<dependency>
<groupId>com.documents4j</groupId>
<artifactId>documents4j-client</artifactId>
<version>1.0.3</version>
</dependency>
<dependency>
<groupId>com.documents4j</groupId>
<artifactId>documents4j-server-standalone</artifactId>
<version>1.0.3</version>
</dependency>
Based on what I read on the Documents4j page, it seems that the command should just work, so I assume that the jar file isn't being created.
I can't seem to find that jarfile anywhere... so I have been unable to run the java -jar command with a path instead of just a name.
Also, I was unsure about what "configuration" I may need in the plugin. Perhaps there's a trick to getting the maven shading to work? Maybe I'm misunderstanding what the Documents4j page is saying? Maybe it works differently for Macs? Maybe Documents4j isn't a good choice?
I greatly appreciate all assistance.
Note that it is only possible to run on a Windows Server that supports .NET and has Office installed.
https://github.com/documents4j/documents4j/issues/53
Integrating JMeter as part of Maven project
Extending the above question, is the possible to do the below steps through maven dependency itself, ideally we don't want to rely on the local installation of JMeter for running the test and don't want to use JMeter Maven Plug-in since we cannot specify which JMeter version we want to use to run the JMeter Script.
The answer mentioned is to use AntRunner but not sure how to do that through maven any pointer will be helpful
My scenario is to,
Download and Unzip the JMeter official distribution as maven dependency
Copy to target folder
JMeterUtils.setJMeterHome("copied-target-folder/bin")
jmeter.run();
You can use AntRunner and the following Ant tasks:
get
unzip
Example:
<get src="url of jmeter"
dest="${build.dir}/${zip}"
usetimestamp="true" ignoreerrors="false"/>
<unzip dest="${build.dir}" src="${build.dir}/${zip}">
The maven-dependency-plugin has a goal called unpack which downloads a dependency (using maven coordinates) and unpacks it on a local directory. You can use that goal to download a given JMeter instance.
The syntax would go like this (not tested, you will have to adjust it):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>unpack</id>
<phase>process-test-classes</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.apache.jmeter</groupId>
<artifactId>jmeter</artifactId>
<version>1.0</version>
<type>zip</type>
<overWrite>false</overWrite>
<outputDirectory>target/jmeter</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
That would fulfill your first step:
Download and Unzip the JMeter official distribution as maven dependency
But I'm not sure there is a full zip version of JMeter published as a Maven dependency. You can unpack the jar files, maybe that's enough. Or maybe you just need to execute those ant steps.
You can execute any ant script (build.xml) using the antrunner plugin. You can find documentation and examples on the Maven AntRun Plugin page.
I want to deploy two jar artifacts with different classifiers, but at the moment that fails because both supply their own version of pom.xml. How can I fix that, so that both pom.xmls can be uploaded along with their artifacts?
Example - I have com.test.company.somelib-1.0.0-cmp1.jar and com.test.company.somelib-1.0.0-cmp2.jar, where cmpX is a classifier. Both packages contain (logically) the same code and classes (of the same version), they only differ slightly in the way they were preprocessed. The classifier annotation is there due to backwards compatibility we need to maintain.
Long story short, first artifact uploads fine, second one fails with Forbidden, because our repository does not allow overwriting artifacts (and I want to keep it that way).
There is a slightly different pipeline that creates both the packages, so it is easier to have their builds separate. I just want to deploy them as two packages of the same name and different classifier.
Thanks for help
Edit: it has been suggested to use Maven profiles. I can see that they would work, but they would not be ideal.
Consider the setup I have depicted on the picture below - there is a CI server (TeamCity).
There is a "starter" build (Sources). This build checkouts all required source files.
From this starter build several other builds are triggered (processing using x.x.x/compile). Each of those builds adjusts a template-pom.xml (fills in particular classifier and other info), and then builds and deploys its artifact to our Artifactory.
With the setup I want to achieve if I decide to add another processing-build, all I need to do is add another "branch". If I was using profiles, I would need to also add a new profile to the pom.xml file.
Correct me if I am wrong please. Profiles seem to be able to achieve the goal, but not ideally, at least in my case.
I strongly discourage having 2 (or more) different pom files with the same GAV.
But I understand your need is raised by legacy reasons.
I have not tried this myself but it could be working:
Leave one build (= maven project) as you have it now. On the other build skip the normal deployment and manually invoke the deploy-file goal of the deploy plugin like so:
<build>
<plugins>
<!-- skip normal execution of deploy plugin -->
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<executions>
<execution>
<id>default-deploy</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
</executions>
</plugin>
<!-- invoke with goal: deploy-file -->
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<executions>
<execution>
<id>someId</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<inherited>false</inherited>
<configuration>
<file>path-to-your-artifact-jar</file>
<generatePom>false</generatePom>
<artifactId>xxx</artifactId>
<groupId>xxx</groupId>
<version>xxx</version>
<classifier>xxx</classifier>
<packaging>xxx</packaging>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Currently we have a JSF Based web project which we are deploying in Jboss EAP 6.1 server.Its a multi-module project with plenty of third party jars added inside web-porject/lib folder.
When we run mvn install it create war file and we deploying this war file in Jboss but issue that its size is too big around 300MB.So sometime its hard for us deploy in war in the server if any single line changes in code its taking time upload the project in server.
We want we should separate out jar file(Third Party) and source code .So war size should be less and all third party jar should be seperate out from the source code.
This project is maven based project so all the dependency added in pom.xml file so for developer prospective we should not remove the pom file entry .
Can Someone please suggest what should be best way to handle this situation?
You should do that in two steps.
First exclude dependencies from packaging and use them only for compilation phase:
<dependencies>
<!-- declare the dependency to be set as optional -->
<dependency>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional> <!-- value will be true or false only -->
</dependency>
</dependencies>
In the second step put all the jars needed for running the application in jboss JBOSS_HOME/lib folder.
You can do that by using Copying project dependencies maven plugin:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
I hope I'm explaining this as accurately as possible, and I want to know if I set up the maven dependencies correctly, or if there's a better way to do it.
Most of my development team's projects rely on a home-grown jar that is deployed at server class loader. The reason for this jar to reside at this level is to the ease of updating the jar at one place without repackaging each project that's using it, assuming changes made to it are backward-compatible.
I develop my web apps against Jetty in my local development. So, in order for the web apps to work locally, I set up the dependencies this way:-
<dependencies>
<!-- Configuring external jar dependency -->
<dependency>
<groupId>com.test.app</groupId>
<artifactId>app-jar</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${env.EXTERNAL_JAR}</systemPath>
</dependency>
...
</dependencies>
<build>
<plugins>
<!-- Configuring Jetty -->
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.26</version>
<configuration>
<contextPath>/${project.parent.artifactId}</contextPath>
<jettyEnvXml>${env.JETTY_ENV_XML}</jettyEnvXml>
<scanIntervalSeconds>1</scanIntervalSeconds>
<connectors>
<connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
<port>7777</port>
</connector>
</connectors>
<webAppConfig>
<extraClasspath>${env.EXTERNAL_JAR}</extraClasspath>
</webAppConfig>
</configuration>
</plugin>
...
</plugins>
</build>
In this approach, I set up an environment variable that points to the external jar path, and reference it in my pom.xml as ${env.EXTERNAL_JAR}.
After doing some reading, it seems like using "system" scope is considered a bad practice. So, I installed this external jar in Nexus and change the scope to "provided":-
<dependency>
<groupId>com.test.app</groupId>
<artifactId>app-jar</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
This allows me to compile my project properly, but I'm not sure if it is even possible for me to get rid of the "EXTERNAL_JAR" environment variable completely because it's still needed by Jetty for the runtime to work properly. My take is using "provided" scope is a little tedious and more work, because I now need to remember to update the jar in Nexus when it is modified AND I still need to update the jar located at the path pointed by the environment variable.
Is there a way for me to expose the external jar to Jetty through maven dependencies, yet not being packaged into the project when the war file is built?
What are you advice on this? Should I just stick with "system" scope so that I just need to update the jar at one place, or should I use "provided" scope? Or if there's even a better way to do this?
Thanks much.
You should be able to add dependencies to the jetty plugin. And then I have the provided scope for the project itself.
http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin
as in
<project>
...
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<systemProperties>
<systemProperty>
<name>logback.configurationFile</name>
<value>./src/etc/logback.xml</value>
</systemProperty>
</systemProperties>
</configuration>
<dependencies>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>0.9.15</version>
</dependency>
</dependencies>
</plugin>
...
<project>
The best thing to do is setup an external repository with your dependency, and add it to your pom.
<repositories>
<repository>
<id>my-repo</id>
<name>my-repo</name>
<url>http://your.repo.url</url>
</repository>
</repositories>
and then you can add your dependency as
<dependency>
<groupId>com.test.app</groupId>
<artifactId>app-jar</artifactId>
<version>1.0</version>
</dependency>
I approve of provided. Provided means - download the dependency for compile-time, but I expect to see it on classpath on the application server.
I did not realize you care only for your local development, so the following would be useful if you were running Jetty on an external server:
Maven will let you deploy a file to a server using the Wagon plugin. So a part of your build process could be pushing the proper .jar into your Jetty server. That way you would not have to do it manually. I would prefer this solution to running a local Maven repository on the Jetty server as suggested by #Paul.
If you wanted to be super-clever (usually a bad idea), you might try to set up a repository directly on the machine with Jetty, that would serve the jar directly from your Jetty install. That way you would not have to modify Nexus, the jars would be only at one place. You can even set up Nexus to mirror another repository, so it could pick things up automatically.
It is a bad practice to modify .jar contents and keep the same Maven coordinates. So this "clever" approach would not work that great anyway.