I have multiple maven modules: DBLayer (Contains all entities),UserManagement (User management services), WebApp
For setting up the testing i need to understand how to structure everything.
I want to test each module in an embedded container. As you all know, in each module I have my test folder where I put my test classes. Do I have to put the ShrinkWrap setup in each module test class (code that prepares embedded container for testing), or is that only needed in the webapp?
I also have the arquillian dependencies in each module pom file. Is there a better way to add these dependencies?
Thank you in advance.
I want to test each module in an embedded container (...)
If you are considering an embedded container, please take a look at this answer. Dan Allen explains it in details in his short article The Danger of Embedded Containers. Please take a look at it.
It looks to me that you are using Maven, then the following answer you may find useful in terms of separating integration tests from unit tests. To be short: stick to the Maven naming conventions (just name your integration tests with *IT suffix, e.g. MyClassIT.java) and let maven-failsafe-plugin do its job.
Do I have to put the ShrinkWrap setup in each module test class (code
that prepares embedded container for testing), or is that only needed
in the webapp?
Unfortunately yes. That is because you may want to prepare a different deployment for each test class. But drawbacks are clear:
Usually repeated deployment's setup.
Slowed down execution of tests (there is a new deploy operation for every test case)
Fortunately, there is Arquillian Suite Extension that lets you achive that. The Extension will force all classes in a TestSuite to run from the same DeploymentScenario. But as far as I know, it is more complex topic than it would appear on the surface - just keep in mind that this extension (although extremely useful) may not work with some other arquillian extensions.
I also have the arquillian dependencies in each module pom file. Is
there a better way to add these dependencies?
Your intuition is correct:) Yes, there are better ways. Personally I would recommend keep dependency to the arquillian only in a parent pom.xml file, then all sub-modules would inherit this dependency.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-bom</artifactId>
<version>1.1.5.Final</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
Generally, be sure to read Getting started with Arquillian Guide.
Related
I am following this article: http://www.softwarepassion.com/it-coverage-with-arquillian-jacoco-extension/ to get test coverage for arquillian integration tests. My project is a multi module though and I don't know where to put the plug in and dependencies. Is it in the top pom, the artifact-making module or in the integration test module?
Thank you
To some extent it depends on the details of your Maven setup, which aren't in your question. Here is some general advice.
1) Where should you put the arquillian-jacoco and jacoco dependencies?
These dependencies should probably go wherever the rest of your Arquillian dependencies are. My understanding is that it is simply having these dependencies that triggers Arquillian to use JaCoCo, not the plugin declaration; even if these dependencies are in a parent of the POM with the actual Arquillian tests, the Arquillian test classes should still be instrumented. You wouldn't put these dependencies in a sibling module to the module with the tests though as they need to be inherited by the integration test module (unless this sibling module has been declared as a dependency of the test module of course).
2) Where should you put the JaCoCo plugin declaration?
As noted above, you may not even need this declaration, depending on what you are trying to achieve. If you want to generate a report, rather than just the jacoco.exec files, then you will need to declare the plugin and an execution with the report goal. You may also want to declare the plugin with the prepare-agent goal if you have other tests that you wish to be instrumented with JaCoCo, such as unit tests.
If you are going to declare the plugin, it can be treated the same way as any other Maven plugin. If you want to run JaCoCo across multiple modules by default you could choose to put the plugin declaration in your parent POM within the regular 'plugins' tag and have it inherited by all child modules, or you may wish to put it in the parent POM within the 'pluginManagement' element so the configuration can be inherited (see http://maven.apache.org/pom.html#Plugin_Management). Alternatively, if you only want to run Arquillian tests in your integration test module, you could also simply declare the plugin in this module's POM (given that you want a report, and without the prepare-agent goal if you're only instrumenting Arquillian tests).
Hope that helps!
We have our project build using maven. We try to run our unit test cases in maven build itself and for doing that we need to add DB2 driver jar in the dependency of all the sub projects.
Instead of doing that, we need a solution to specify the absolute path of the jar file as a mvn command line argument to use it in the running of unit test cases.
This is because the driver jar is available in our app server lib folder and we don't want to specify it in the dependencies of our projects.
Couldn't find a suitable solution googling it, hence requesting for an expert solution here.
Any workaround would be of greater help.
Thanks in advance.
The usual way would be to add a dependency to the database driver and limit the dependency to testing (test scope). So the library is available for unit tests but will not deployed and jar'ed.
Practically spoken, I'd create a maven artifact for this driver (just a basic POM file) and place it on the build servers maven repository (or the nexus, if you use it for the projects).
I'm using a dependency with scope set to 'system' to reference a jar that is available in the container but not in any maven repository. In this case the jar is put in a folder named 'lib' in the project like this, :
<dependency>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<version>version</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/library.jar</systemPath>
</dependency>
The groupId, artifactId and version can be set to any value you want, the trick was that system dependencies have to be given with an absolute path, which is worked around by using the project.basedir property. It should also be possible to specify the complete path as a property.
We have our project build using maven. We try to run our unit test cases in maven build itself and for doing that we need to add DB2 driver jar in the dependency of all the sub projects.
Well, the maven way would be to declare the DB2 driver as dependency with a test scope in a parent project.
Instead of doing that, we need a solution to specify the absolute path of the jar file as a mvn command line argument to use it in the running of unit test cases.
You could use the additionalClasspathElement in the plugin configuration to pass the path to the driver:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<additionalClasspathElements>
<additionalClasspathElement>path/to/additional/resources</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</plugin>
If you variablelize it, you could pass the value on the command line.
But to be honest, I can't understand why you don't install the driver in a corporate repository and declare it as dependency. And if you don't have a corporate repository, use a file based repo as described in this previous answer (please, don't use the system scope bad practice). There is no good reason to go the hacky way.
I have a test project requiring some heavy jars which i put in ${M2_HOME}\test\src\main\resources\ and add them in the pom.xml using :
<dependency>
<groupId>server</groupId>
<artifactId>server</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${M2_HOME}\test\src\main\resources\server.jar</systemPath>
</dependency>
<dependency>
<groupId>client</groupId>
<artifactId>client</artifactId>
<version>6.0</version>
<scope>system</scope>
<systemPath>${M2_HOME}\test\src\main\resources\client.jar</systemPath>
</dependency>
I want to know if it possible to exclude them during sonar analysis, or generally just analyze java sources folder.
If the problem is that these JARs are included in sonar analysis because they are located in src/main/resources, then one obvious solution would be to put them somewhere else (see the post scriptum). If for whatever reason this is not possible, please clarify (I'd really like to know why you put these JARs under resources).
If the problem is that these JARs are declared as dependencies, you could use a specific profile not including them to run sonar.
PS: Note that using the system scope is a bad practice and has several drawbacks (as mentioned here or here). A cleaner approach would be to use a file based repository as suggested in this answer.
I need to download a file from a non-standard layout repository.
The standard repository layout is groupId>/<artifactId>/<version>/<artifactId>-<version>.<packaging> however, I need to download the following file:
http://hudson.myserver.com:10000/repo/ocp-services/schemas/trunk/201/archive/schemas/dist/schemas.jar
where ocp-services is effectively the groupId, schemas is the artifactId and 201 is the version.
How would I add a dependency to this file and get it downloaded into my project and local repository?
This is a Hudson file repository if this is of any help, but it is a third parties so difficult to get them to change any location.
One option would be to register a custom ArtifactRepositoryLayout implementation and to declare a repository using this custom layout. I've never done that but it should be possible, check this blog post.
A second option would be to configure Maven to go through some kind of custom proxy (e.g. a Servlet) and to rewrite the URL on the fly for this particular dependency.
In both cases, I'm afraid Maven will complain about missing metadata ("A dependency in Maven isn't just a JAR file", see 3.5.5. Maven's Dependency Management) because the hudson file repository is just not a Maven repository. Maybe this can be handled programmatically though. But as I said, I've never done this.
A third option would be to ask the project building the JAR you need to deploy it (in the maven sense). That would be of course the best solution.
A last one option would be to just download this JAR and to install it manually in your local repository. If this is an option, go for it.
Have you tried adding this to your pom.xml :
<dependencies>
<dependency>
<groupId>ocp-services</groupId>
<artifactId>schemas</artifactId>
<version>201</version>
<type>jar</type>
</dependency>
</dependencies>
or if that don't work as Pascal says install it manually
I have to deal with what is pretty ugly and large blob of ColdFusion code which up to this day is maintained by direct modifications on production server (don't ask). I managed to clean it up from dupes and backups and put it into Subversion, now I need tp pick a make system to be able to put this onto continuous build (TeamCity) and also scheduled releases.
To my surprise I only found pretty much a single blog article on how to retrofit CF project with Maven, so the question is - does anyone have experience successfully using Maven on CF and what in general people use to manage large CF projects?
Your suggestions, tips and links will be much appreciated
Since I don't want to start religions wars - Maven is pretty much company standard (vs Ant)
First, here's another blog you might find helpful.
build-tools-maven-and-coldfusion
I haven't tried to build ColdFusion with Maven, but I have experience with managing Maven builds for a large company. There are a few things for you to consider.
Project structure
Coldfusion cfm and cfc files should be put in src/main/resources so they are bundled in the jar (the blog referenced above overrides the Maven convention to put them in src. this is ok, but could be a problem if you later need to add anything else to the project).
I'd probably keep cfc and cfm files in separate projects with appropriate dependency declarations to link them, this keeps your cfc projects as libraries and helps reuse. It is also worth considering the granularity of the cfc projects. Generally Maven's dependency management helps you keep artifacts small, with little need to worry about finding all the jars.
Deployment
The simplest way to deliver the artifacts is to use the maven-war-plugin to create a war containing your artifacts and all their transitive dependencies. This makes each application self-contained, which can be useful. The downside of this is that you'll end up bundling the same artifacts repeatedly and they can be quite large. To mitigate this you can either use the assembly-plugin to create custom packages excluding the common components, or you can specify that certain components (e.g. ColdSpring) are scope provided, this means they won't be included in the war.
Version Management
Maven encourages a proliferation of dependencies, by default each dependency declaration has a version, this can cause maintenance issues, particularly when you want to bump the version of an external dependency. You can mitigate this by defining a parent POM or an "app" POM. Either would have a dependencyManagement section declaring the details (groupId, artifactId, and version) for common artifacts. Any POM inheriting from the parent need not declare the dependency version as it will be inherited (note this doesn't mean that all children will have all dependencies, only that any that declare a dependency don't need to declare the version). If you define an "app" project with packaging "pom" and a dependencyManagement section, you can reference it with scope import (from Maven 2.0.9 onwards), this will import the dependencyManagement section from the "app" project to the project POM. See the dependency documentation for more details.
If you declare a dependency with a scope in the dependencyManagement section, that scope will be inherited unless it is overridden in the child POM. Related to the deployment section above, this means that you can declare the common libraries scope provided in the parent to ensure they are not bundled in each applciation.
Naming Conventions
You'll need a naming convention for the packages to avoid collisions.
It's probably best to follow the Maven convention and use java package-like groupIds (org.apache.maven for maven.apache.org) and the jar name for the artifact. This convention would give the groupId "org.coldspringframework" and artifactId "coldspring" for ColdSpring.
Further distinctions might need to be made across the company. For example, if you have a web and core team, you could give the web team the groupIds com.mycompany.web.* and the core team com.mycompany.core.*
Dependency Management
You'll need to add your CFC packages to a Maven repository such as Nexus so they are accessible to other builds across the enterprise.
If you want to keep the CFC packages separate to the jars. You can specify a custom packaging type, so that they won't be mixed up with any Java artifacts. If you create a custom packaging type, the artifacts can have the ".jar" extension, but any dependency declaration must have the type set.
Here's an example following those conventions:
<dependency>
<groupId>org.coldspringframework</groupId>
<artifactId>coldspring</artifactId>
<version>1.2</version>
<!--custom packaging type helps keep separate from Java artifacts-->
<type>cfc</type>
</dependency>
There's a section in the Nexus book that describes custom lifecycles (follow the links for more details. Essentially you need to create a plugin with a META-INf/plexus/components.xml to describe the plexus mechanics (what archiver to use, what extension to output etc).
The components.xml would look something like this:
<component-set>
<components>
<component>
<role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
<role-hint>cfc</role-hint>
<implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation>
<configuration>
<phases>
<process-resources>org.apache.maven.plugins:maven-resources-plugin:resources</process-resources>
<package>com.hsbc.maven.plugins:maven-jar-plugin:jar</package>
<install>org.apache.maven.plugins:maven-install-plugin:install</install>
<deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy>
</phases>
</configuration>
</component>
<component>
<role>org.apache.maven.artifact.handler.ArtifactHandler</role>
<role-hint>cfc</role-hint>
<implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
<configuration>
<extension>jar</extension>
<type>cfc</type>
<packaging>cfc</packaging>
</configuration>
</component>
<component>
<role>org.codehaus.plexus.archiver.Archiver</role>
<role-hint>cfc</role-hint>
<implementation>org.codehaus.plexus.archiver.zip.ZipArchiver</implementation>
<instantiation-strategy>per-lookup</instantiation-strategy>
</component>
<component>
<role>org.codehaus.plexus.archiver.UnArchiver</role>
<role-hint>cfc</role-hint>
<implementation>org.codehaus.plexus.archiver.zip.ZipUnArchiver</implementation>
<instantiation-strategy>per-lookup</instantiation-strategy>
</component>
</components>
</component-set>
Maven looked interesting to me too, but I couldn't find enough resources, and didn't have enough time to figure it out, so I moved onto what seemed to be good as well.
I understand you prefer to use Maven, I have come across several articles regarding Ant and Coldfusion, as well as a recent one about Hudson with Coldfusion.
Coldfusion also has the cfant (undocumented) tag. You can run ANT scripts right from CF?