I have a Maven project that includes some test cases. Today I tried adding the jarsigner plugin and now the tests fail with:
java.lang.SecurityException: class "types.AccountType"'s signer information does not match signer information of other classes in the same package
The test classes are in the same package to have access to package-private methods etc. I believe that this error is happening because the junit test classes are not being signed while the classes being tested are.
Does anyone have a suggestion on how to avoid this problem? I had some ideas but don't know how to implement them:
Cause the testing phase to use the classes instead of the jar file.
Put the test classes into their own jar file and sign it.
I ran into this issue today and the problem is as you guessed it many years ago (signing order issue). This was the fix for me (change the phase to install):
<plugin>
<artifactId>maven-jarsigner-plugin</artifactId>
<version>${maven-jarsigner-plugin.version}</version>
<executions>
<execution>
<id>sign</id>
<!-- note: this needs to be bound after integration tests or they will fail re: not signed -->
<phase>install</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
<configuration>
<tsa>http://sha256timestamp.ws.symantec.com/sha256/timestamp</tsa>
<keystore>${project.basedir}/.conf/Keystore</keystore>
<alias>Alias</alias>
<storepass>{1234}</storepass>
</configuration>
</plugin>
Jars are still signed and integration tests once again work.
Related
I have this issue that I have been trying to solve for the better part of a day, but can't really seem to do.
I have set up my maven so that it fails if findbugs finds any bugs. However, because of reasons, I would like to ignore all the bugs that currently exist in the project, and only fail if new bugs are found. A baseline.
I am able to generate an XML file containing a <BugCollection>
with all my current bugs, using FindBugs plugin for IntelliJ. However, supplying this to the maven plugin does nothing.
It seems the maven plugin requires a filter file in this format:
<Match>
<Class name="com.foobar.MyClass" />
</Match>
My question is then: How do I generate this filter file?
It seems that the findbugs:gui is not a great option, as it only allows me to filter on bug type and class. Meaning new bugs of the same type in the same class but a different method would be ignored.
Alternatively: How do I make findbugs for maven ignore existing bugs and only fail on new ones?
Thank you :)
You should use the excludeBugsFile configuration, something like below. The findbugs-baseline.xml is the file exported with the FindBugs-IDEA plugin in Intellij
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<configuration>
<excludeBugsFile>${project.basedir}/findbugs-baseline.xml</excludeBugsFile>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
I've just started working on a large project that has many JSPs, many of which were created long ago, and some of which were generated. I would like to use the jetty-jspc-maven-plugin from org.eclipse.jetty to compile our JSPs for use in Tomcat 8.5. Unfortunately, some of the JSPs do not compile cleanly, and when there is a compilation problem, the maven build fails and stops.
The JspcMojo class does most of the work. It has an embedded class, JspcMojo.JettyJspC that extends org.apache.jasper.JspC and has a failOnError property. The documentation for JettyJspC says, "JettyJspC Add some extra setters to standard JspC class to help configure it for running in maven." So, it seems like I ought to be able to set the failOnError property to false and be done. I have tried all of the following, without success. How can I pass the failOnError property from maven to the JSP compiler?
<jspc.failOnError>false</jspc.failOnError>
<org.apache.jasper.compiler.failOnError>false</org.apache.jasper.compiler.failOnError>
<org.apache.jasper.JspC.failOnError>false</org.apache.jasper.JspC.failOnError>
<maven.compiler.failOnError>false</maven.compiler.failOnError>
<JettyJspC.failOnError>false</JettyJspC.failOnError>
<JspcMojo.JettyJspC.failOnError>false</JspcMojo.JettyJspC.failOnError>
<org.eclipse.jetty.jspc.plugin.JspcMojo.JettyJspC.failOnError>false</org.eclipse.jetty.jspc.plugin.JspcMojo.JettyJspC.failOnError>
BTW, compiling JSPs using ant is fairly well documented. I want to do the equivalent using maven.
Under the configuration section, you can use a subelement of the jspc element, like so:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-jspc-maven-plugin</artifactId>
<version>9.4.7.v20170914</version>
<executions>
<execution>
<id>jspc</id>
<goals>
<goal>jspc</goal>
</goals>
<configuration>
<webAppSourceDirectory>${basedir}/target/overlaidjsps</webAppSourceDirectory>
<webXml>${basedir}/src/main/webapp/WEB-INF/web.xml</webXml>
<webXmlFragment>${basedir}/target/webfrag.xml</webXmlFragment>
<!-- The comma separated list of patterns for file extensions to be processed. -->
<includes>**/*.jsp</includes>
<jspc><failOnError>false</failOnError></jspc>
</configuration>
</execution>
</executions>
</plugin>
I have a multi module project, in which one of the module ( say MODULE-A) generates sources and classes using xmlbeans plugin. So everytime when I do a clean install of parent project, eclipse recognizes all of the generated sources as new classes, and I don't want to commit the same files again and again when there is no schema change. To overcome this problem, I wrapped xmlbeans build under a profile so that I can build it with profile whenever there is a schema change. But it didn't solve the problem completely.
Whenever I try to do clean build of parent, MODULE-A is not creating 'schemaorg_apache_xmlbeans' under build directory ( which is something only generated by xmlbean plugin when I run with profile ). I can tell maven to exclude 'schemaorg_apache_xmlbeans' from the clean task. But I want to know if this is the right way to handle.
Appreciate your responses.
Thanks in advance
One alternative to this approach is to add this plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
This will allow the generated-sources to be added as a source folder so every time it generates you will have them built and available. You wouldn't commit these but when the actual jar gets built/released they will be in there and work all the same. This allows you to always be using code most up to date with your schema. This may not be the best solution for you but I found it to be a good idea when I ran into a similar situation.
I'm trying to exclude a bunch of packages from a javadoc site.
Unfortunately this plugin seems to live its own life and when it was configured as a report plugin it failed with access denied when moving files, so it was changed to be a normal plugin and then configured to run with the site goal (aggregated). By doing that we have the javadoc generated and it's published under the site as it should be.
But it seems that the configuration parameters for the plugin doesn't take effect at all. I've tried to move the <excludePackageNames> element around - both being a general config and to be a specific config for the aggregate goal - and I even added an exclusion for our entire code base and all files was still generated.
What I'm trying to do is to simply remove a couple of packages that shouldn't be in the javadoc. Anyone who got this plugin and the config to play nicely, to exclude packages?
This is the config I use right now, the javadoc is created but all packages, including the excluded, is generated.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.8</version>
<configuration>
<excludePackageNames>my.company.packages.*</excludePackageNames>
</configuration>
<executions>
<!-- Hook up the Javadoc generation on the site phase -->
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate</goal>
</goals>
<phase>site</phase>
</execution>
</executions>
</plugin>
Any ideas, pretty please?
I solved identical problem by adding the sourcepath parameter to the configuration:
<configuration>
<sourcepath>${project.basedir}/src/main/java</sourcepath>
<excludePackageNames>my.company.packages.*</excludePackageNames>
</configuration>
The configuration above will exclude all packages below my.company.packages but not my.company.packages itself. To exclude also my.company.packages use <excludePackageNames>my.company.packages</excludePackageNames> instead.
I'd like Maven to stop trying to run my JUnit Spring tests when it encounters the first error. Is this possible?
My test classes look like the following, and I run them just as a standard Maven target.
#ContextConfiguration(locations = {"classpath:/spring-config/store-persistence.xml","classpath:/spring-config/store-security.xml","classpath:/spring-config/store-service.xml", "classpath:/spring-config/store-servlet.xml" })
#RunWith(SpringJUnit4ClassRunner.class)
#Transactional
public class SkuLicenceServiceIntegrationTest
{
...
If there's an error in the Spring config, then each test will try to restart the Spring context, which takes 20 seconds a go. This means we don't find out for ages that any tests have failed, as it'll try to run the whole lot before concluding that the build was a failure!
Answering ten years later, since I needed exactly the same.
The failsafe plugin can be configure to "skip tests after failure", using the skipAfterFailureCount parameter.
Official documentation:
https://maven.apache.org/surefire/maven-failsafe-plugin/examples/skip-after-failure.html
This is more a remark, than an answer, but still, maybe you'll find it useful.
I'd recommend separating your integration tests into a separate phase, and running them with Failsafe, rather than Surefire. This way you can decide whether you need to run only fast unit tests, or the complete set with long-running integration tests:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>integration-test</goal>
</goals>
</execution>
<!-- Uncomment/comment this in order to fail the build if any integration test fail -->
<execution>
<id>verify</id>
<goals><goal>verify</goal></goals>
</execution>
</executions>
</plugin>
</plugins>
A workaround for your problem might be singling out a test into a separate execution and run it first; this way the execution would fail and subsequent surefire/failsafe executions will not be launched. See how to configure the plugin to do it.