Sonatype Nexus2 Repository Manager OSS

To allow for repeatable, faster builds in a continuous build environment, it’s often a good idea to use a central repository to cache common assets and prevent the need to download assets from the internet for each build. Using Nexus allows for those transfers to occur over your local network for previously downloaded assets.

You can download the WAR from:
http://www.sonatype.org/downloads/nexus-latest.war

And install on your Java application server, such as Apache Tomcat, via normal means.

If you are using Maven, you’ll need to make appropriate changes in (/.m2/settings.xml) to direct your builds to use Nexus.

Jenkins and other build automation tools will require similar changes.

REFERENCES:

Selenium HtmlUnit driver separated in 2.53.0

I’ve been a user of Selenium testing for several years, though I noticed that some classes related to the HtmlUnit WebDriver were missing after upgrading from 2.52.0 to 2.53.0. After some research, I discovered that it is now a separate dependency allowing for a separate release cycle. Additionally, if you don’t use this (relatively generic) webdriver, you will no longer need to have it in your binaries.

Here’s all you need to do to add it to your Maven projects for testing.

In your pom.xml file:

<properties>
<selenium.version>2.53.0</selenium.version>
<htmlunitdriver.version>2.20</htmlunitdriver.version>
</properties>
<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>htmlunit-driver</artifactId>
<version>${htmlunitdriver.version}</version>
<scope>test</scope>
</dependency>
</dependencies>

REFERENCES:

SonarLint for Eclipse IDE

I’ve always been fan of tools for automation of development and testing. I’ve used SonarQube for a long time, and even connect it to my IDE (usually Eclipse), so that I can act on any warnings for code as I’m working on it.

SonarLint takes that to a new level, as it gives notifications before the code is even commited for SonarQube to analyze.

While the instructions here are for Eclipse, SonarLint is also available for IntelliJ IDEA, VisualStudio, and as a command line tool for download from the website.

Eclipse Update Site:
https://www.sonarlint.org/eclipse/

REFERENCES:

Java Dependency Vulnerability scanning with Maven victims-enforcer

One of the OWASP guidelines for secure applications is to not use components with known vulnerabilities. Unfortunately it can be a very difficult and time consuming task to keep up with these manually, automation can save you countless hours!

See https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities.

NOTE: victims-enforcer can be used in conjunction with the OWASP dependency scanner. I have only found it to be problematic in ‘tycho’ builds.


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<dependencies>
<dependency>
<groupId>com.redhat.victims</groupId>
<artifactId>enforce-victims-rule</artifactId>
<version>1.3.4</version>
<type>jar</type>
</dependency>
</dependencies>
<executions>
<execution>
<id>enforce-victims-rule</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<rule implementation="com.redhat.victims.VictimsRule">
<!--
Check the project's dependencies against the database using
name and version. The default mode for this is 'warning'.

Valid options are:

disabled: Rule is still run but only INFO level messages and no errors.
warning : Rule will spit out a warning message but doesn't result in a failure.
fatal : Rule will spit out an error message and fail the build.
-->
<metadata>warning</metadata>

<!--
Check the project's dependencies against the database using
the SHA-512 checksum of the artifact. The default is fatal.

Valid options are:

disabled: Rule is still run but only INFO level messages and no errors.
warning : Rule will spit out a warning message but doesn't result in a failure.
fatal : Rule will spit out an error message and fail the build.
-->
<fingerprint>fatal</fingerprint>

<!--
Disables the synchronization mechanism. By default the rule will
attempt to update the database for each build.

Valid options are:

auto : Automatically update the database entries on each build.
daily : Update the database entries once per day.
weekly: Update the database entries once per week.
offline : Disable the synchronization mechanism.
-->
<updates>daily</updates><!-- was: auto -->

</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>

Vulnerability database is sourced from: https://victi.ms with backing from RedHat.

REFERENCES:

OWASP Dependency Vulnerability Scanning of Java JARs with Maven

One of the OWASP guidelines for secure applications is to not use components with known vulnerabilities. Unfortunately it can be a very difficult and time consuming task to keep up with these manually, automation can save you countless hours!

See https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities.

NOTE: OWASP dependency scanner can be used in conjunction with the victims-enforcer.

Add to your projects pom.xml:

<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>1.3.4</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>

Each time you build, the plug-in will verify the assets against the list of known vulnerable libraries and report them in your output.

Vulnerability database is populated from: https://nvd.nist.gov.

NOTES:

  1. The example above is a very simple implementation, see the documentation for additional functions.
  2. The first use of the plug-in can take a long time as the vulnerability library must be installed locally before initial use.
  3. Similar functionality is available for Ant builds, if desired.

REFERENCES:

Adding TestNG support to Eclipse

Most Java developers are familiar with the Eclipse IDE, even if they use alternatives.

One thing that’s bothered me for some time is that while JUnit is natively supported in Eclipse, TestNG is not. Thankfully, you can easily add this functionality.

  1. Help; Eclipse MarketPlace;
  2. Find – enter: testng
  3. Click on "TestNG for Eclipse" and install by stepping through the prompts.
  4. Restart of Eclipse is required to enable the new functionality.

Code signing of java applets – using Ant

To sign your java assets during the Ant build process, you can add the following to the build.xml to make use of the values we established in the keystore creation step.

Something as simple as the following could be used:

<signjar jar="example.jar" alias="selfsigned" keystore="selfsignkeys.store" keypass="123456" storepass="123456"/>

I generally prefer to add the following:

In build.properties – I externalize the variables…

signing.alias=selfsigned
signing.keystore=selfsignkeys.store
signing.keypass=123456
signing.storepass=123456

Then, in build.xml – a ‘task’ for signing…


<property file="build.properties"></property>
... snip ...
<target name="signwar" depends="war">
<echo message="--- signing ---" />
<signjar jar="${build.dir}/${ant.project.name}.war" alias="${signing.alias}" keystore="${signing.keystore}" keypass="${signing.keypass}" storepass="${signing.storepass}" />
</target>

REFERENCES:

Code signing of java applets – using Maven

To sign your java assets during the maven build process, you can add the following to the pom.xml to make use of the values we established in the keystore creation step.

WARNING: for security and maintainability purposes, you should define the ‘configuration’ items in your local ‘settings.xml’ file instead of in the pom.xml as is done here for example only!


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jarsigner-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>sign</id>
<goals>
<goal>sign</goal>
</goals>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<alias>selfsigned</alias><!-- ${project.name} -->
<keystore>selfsignkeys.store</keystore><!-- NOTE: you can also specify an absolute path here -->
<storepass>123456</storepass>
<keypass>123456</keypass>
</configuration>
</plugin>

REFERENCES:

Code signing of java assets – creating a keystore

This is generally done via the command line, though I’ve seen it done with Ant in some cases. Here are the specifics… you’ll want to change the passwords and likely take a look at the algorithm (RSA for this example and validity (365 days in this example) for your actual use.

Background, in order to sign your java assets, you will first need to generate a key. You can later get this verified by a CA (Certifying Authority) as needed, this example is selfsigned.

NOTE: I’ll use these example values in the Maven and Ant signing code examples to follow.


keytool -genkey -keyalg RSA -alias selfsigned -keystore selfsignkeys.store -storepass 123456 -keypass 123456 -validity 365

REFERENCES:

Apache Commons-Email java implementation steps

Many java developers are familiar with the venerable javax.mail.* packages and make use of them in their applications.

While it works well, it can often be cumbersome to work with and difficult to implement new features. Apache Commons-Email, now at version 1.4 (May 2015), provides a simpler interface to send emails with HTML format and attachments.

NOTE: The below examples assume that you are using an SMTP server that verifies the sender. You may need to modify the examples for your specific configuration. Additionally, I’ve left out the try/catch blocks for “Exceptions” that you will have to add.

Using javax.mail.* to send an text formatted message:

final String body = "Example email body";
final String emailFrom = "From User ";
final String emailTo = "To User
";
/* NOTE: 'session' and 'conn' are outside of the scope of this example but generally contain host and authentication information */
javax.mail.Session session = getSession(conn);
final javax.mail.Message message = new javax.mail.internet.MimeMessage(session);
message.setFrom(new javax.mail.internet.InternetAddress(emailFrom));
message.setRecipients(javax.mail.Message.RecipientType.TO, javax.mail.internet.InternetAddress.parse(emailTo));
message.setSubject(subj);
message.setText(body);
javax.mail.Transport.send(message);

Using commons-email for HTML email.

final String body = "Example email body";
final String emailFromAddr = "[email protected]";
final String emailFromName = "User From";
final String emailToAddr = "[email protected]";
final String emailToName = "User To";
final String username = "myusername";
final String password = "mypassword";

final org.apache.commons.mail.HtmlEmail email = new org.apache.commons.mail.HtmlEmail();
email.setHostName("localhost");
email.setSmtpPort(25);
email.setAuthentication(username, password);
email.setAuthenticator(new org.apache.commons.mail.DefaultAuthenticator(username, password));
//email.setSSLOnConnect(true);
final String charset = "UTF-8";
email.setCharset(charset);
email.setFrom(emailFromAddr,emailFromName);
email.setSubject(subj);

email.addTo(emailToAddr, emailToName);
//email.setDebug(true);

// set the alternative message
email.setTextMsg("Your email client does not support HTML messages.");

// set the html message
final StringBuilder sb = new StringBuilder();
sb.append("");
sb.append(body);
sb.append("");
email.setHtmlMsg(sb.toString());
email.send();

Using commons-email with an inline attachment:

final org.apache.commons.mail.HtmlEmail email = new org.apache.commons.mail.HtmlEmail();
/* (insert code from example above above) */
String cid = null;
try{
final URL url = new URL("http://www.example.com/logo.gif");
final String img = email.embed(url, "Logo");
cid = "\"\"";
}
catch(final MalformedURLException ex){
// eat it!
}
// set the html message
final StringBuilder sb = new StringBuilder();
sb.append("");
if(cid!=null){ sb.append(cid); }
sb.append(body);
sb.append("");
email.setHtmlMsg(sb.toString());
email.send();

Code changes to use the library should not take very long as Commons-Email builds on top of javax.mail.*. In most cases, For Maven projects, you can remove the javax.mail references and simply add the new commons-email one to your pom.xml:


<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-email</artifactId>
<version>1.4</version>
</dependency>

REFERENCES: