Installing JDK on Oracle Linux got this error error: Failed dependencies: bin/basename is needed by jdk-2000:1.6.0_38-fcs.x86_64

Problem

I was trying to setup my Oracle Enterprise Linux docker container with JDK and ran into this problem when I tried to execute the rpm.bin file, couldnt figure out the reason after tons of searches on internet and eventually solved it as mentioned in the Solution.

bash-4.1# cp /Software/linux/java/jdk-6u38-linux-x64-rpm.bin .
bash-4.1# chmod 755 jdk-6u38-linux-x64-rpm.bin
bash-4.1# ./jdk-6u38-linux-x64-rpm.bin
Unpacking...
Checksumming...
Extracting...
UnZipSFX 5.50 of 17 February 2002, by Info-ZIP (Zip-Bugs@lists.wku.edu).
  inflating: jdk-6u38-linux-amd64.rpm 
  inflating: sun-javadb-common-10.6.2-1.1.i386.rpm 
  inflating: sun-javadb-core-10.6.2-1.1.i386.rpm 
  inflating: sun-javadb-client-10.6.2-1.1.i386.rpm 
  inflating: sun-javadb-demo-10.6.2-1.1.i386.rpm 
  inflating: sun-javadb-docs-10.6.2-1.1.i386.rpm 
  inflating: sun-javadb-javadoc-10.6.2-1.1.i386.rpm 
error: Failed dependencies:
    /bin/basename is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/cat is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/cp is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/gawk is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/grep is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/ln is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/ls is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/mkdir is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/mv is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/pwd is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/rm is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/sed is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/sort is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/touch is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /usr/bin/cut is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /usr/bin/dirname is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /usr/bin/expr is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /usr/bin/find is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /usr/bin/tail is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /usr/bin/tr is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /usr/bin/wc is needed by jdk-2000:1.6.0_38-fcs.x86_64
    /bin/sh is needed by jdk-2000:1.6.0_38-fcs.x86_64
Installing JavaDB
error: Failed dependencies:
    /bin/sh is needed by sun-javadb-core-10.6.2-1.1.i386

Done.
bash-4.1# 


Solution

Download the .bin file which doesnt say .rpm.bin and follow the same installation process and it just works :)

http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase6-419409.html#jdk-6u38-oth-JPR

Linux x64	65.66 MB	jdk-6u38-linux-x64-rpm.bin
Linux x64	68.72 MB	jdk-6u38-linux-x64.bin

 

Java - Adding references to Framework API Documentation (docs) while generating Javadocs

In continuation to my earlier posts about using Maven to generate Javadocs for your project source code, I want to provide some inputs on how you can link your project's generated apiDocs to the apiDocs of the framework it is dependent on. In my case, I was working on an ATG project and used Maven javadoc plugin to generate javadocs for my project source code, the apiDocs got generated successfully but all the ATG Framework classes that my project source code referred to were linked to the Oracle java documentation. This was because the javadoc plugin assumes that any class thats not defined in the project source code is actually a java class. To avoid this from happening, you can add links/link tag combination (as given in the snippet below) and point the same to the folder/URL which contains the apiDocs/package-list (in my case this file was inside the folder mentioned in the link tag) file. This file helps the javadoc utility understand as to which packages are covered by the docs provided by the folder in the link tag. This way if your project is referring to multiple frameworks you can download the framework documentation to a folder and add the offline links to the javadoc plugin configuration section and rerun the maven command to regenerate the apiDocs with the updated links.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-javadoc-plugin</artifactId>
    <version>2.8</version>
    <configuration>
        <reportOutputDirectory>C:/Project/apiDocs</reportOutputDirectory>
        <doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
        <docletArtifact>
            <groupId>org.umlgraph</groupId>
            <artifactId>doclet</artifactId>
            <version>5.1</version>
        </docletArtifact>
        <additionalparam>-views</additionalparam>
        <useStandardDocletOptions>true</useStandardDocletOptions>
        <links>
            <link>file:///C:/Users/nseshadr/Downloads/E22630_01/Platform.1002/apidoc</link>
        </links>
    </configuration>
    <executions>
        <execution>
            <id>aggregate</id>
            <goals>
                <goal>aggregate</goal>
            </goals>
        </execution>
    </executions>
</plugin>

You can always refer to the Maven Javadoc Plugin page for more information and options.

Note: Also you can download the Oracle Sun Java API documentation and add information about the same to the links/link section and that will make all your java class references point to the local API folder as against the internet URL. 

Java - Generating code coverage reports using Cobertura with Maven

If you have a requirement or a plan to generate test code coverage reports for your project using Cobertura and you are using Maven as your build tool, copy the following onto your pom.xml in the build/plugins section.

<plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>cobertura-maven-plugin</artifactId>
      <version>2.5.1</version>
       <configuration>
      <instrumentation>
        <includes>
          <include>com/company/**/*Manage*.class</include>
          <include>com/company/**/*Tool*.class</include>
        </includes>
      </instrumentation>
      <aggregate>true</aggregate>
      <outputDirectory>C:/Project/TestCoverageReports</outputDirectory>
    </configuration>
    <executions>
      <execution>
          <phase>package</phase>
          <goals>
              <goal>cobertura</goal>
          </goals>
      </execution>
    </executions>
</plugin>

Make sure that your maven doesnt skip tests - i.e., -Dmaven.test.skip is set to false.

Note that the test coverage report will be generated in the configured outputDirectory. If you are working on a project that has a parent POM which invokes multiple child POMs, add this to the parent POM, the aggregate option will generate one code coverage report for all the set of modules invoked from inside the parent without any changes to the child POMs. You can always refer to the Maven Cobertura Plugin page for more information and options.

Java - Generating javadocs for your source code with Maven using Custom Doclet (GraphViz)

Its always good to have a visual representation rather than a text based representation for us to understand things better. This concept works well for the javadocs that we generate as well. As mentioned in one of my other blogs - Software Tools - I managed to use GraphViz and UmlGraph to generate javadocs with ClassDiagrams. You can also automate this by integrating all this into your Maven POM.

So if you are using Maven as the build tool on your project and you want to generate javadocs for all your source files with the UML classdiagram embedded on them, please add the following to your POM inside the build/plugins section.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-javadoc-plugin</artifactId>
    <version>2.8</version>
    <configuration>
        <reportOutputDirectory>C:/Project/apiDocs</reportOutputDirectory>
        <doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
        <docletArtifact>
            <groupId>org.umlgraph</groupId>
            <artifactId>doclet</artifactId>
            <version>5.1</version>
        </docletArtifact>
        <additionalparam>-views</additionalparam>
        <useStandardDocletOptions>true</useStandardDocletOptions>
    </configuration>
    <executions>
        <execution>
            <id>aggregate</id>
            <goals>
                <goal>aggregate</goal>
            </goals>
        </execution>
    </executions>
</plugin>

As mentioned in my other post on javadoc generation using Maven please make necessary changes to your mvn command. Also make sure you download GraphViz, install the same and add its bin folder to the PATH environment variable before running the mvn command or executing the script that runs the mvn command otherwise you would see issues about "dot" not being recognized as a commnd or some error of that kind.

Java - Generating javadocs for your source code with Maven

If you have a requirement or a plan to generate javadocs for your project source code and you are using Maven as your build tool, copy the following onto your pom.xml in the build/plugins section.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-javadoc-plugin</artifactId>
    <version>2.8</version>
    <configuration>
        <reportOutputDirectory>C:/Project/apiDocs</reportOutputDirectory>
    </configuration>
    <executions>
        <execution>
        <id>aggregate</id>
        <goals>
            <goal>aggregate</goal>
        </goals>
        </execution>
    </executions>
</plugin>

Also dont forget to add javadoc:aggregate to the mvn goal/tasks list for the javadocs to get generated. 

mvn -e -s application\settings.xml -Denvironment=development -Dmaven.test.skip=false clean install javadoc:aggregate

Note that the javadocs will be generated in the configured reportOutputDirectory. If you are working on a project that has a parent POM which invokes multiple child POMs, add this to the parent POM, the aggregate option will generate one javadoc for all the set of modules invoked from inside the parent without any changes to the child POMs. You can always refer to the Maven Javadoc Plugin page for more information and options.

Java - JUnit Partial Mocking using Mockito

I recently started writing a lot of JUnits as part of the development activities. Explored working with ATGDust, EasyMock and Mockito frameworks for various reasons. ATGDust for testing ATG Components, EasyMock and Mockito for writing JUnits using Mocking.

In this post, I am going to try and provide a sample to partially mock the objects (using Mockito) under test.

Need for partial Mocking - Most of the time when we write test classes to test the various methods in the class we use Mocks to make sure that the class/method is tested without much dependencies, assuming that the dependencies will be tested by their own test classes. Mocks are a great help for this situation and I think they are doing their job perfectly. But usually when you use mocks, you can only mock the dependent classes/interfaces and not really mock the class to be tested, because there is no point if you mock even class to be tested. Agreed. But there could be situations where there are too many dependencies for a particular method with other methods in the same class and you would run into a situation where you have to provide write a lot of test code before you could even invoke the method under test and see a Junit run. Partial mocking helps in situations like this, where it can mock some of the method invocations and return whatever responses you want to provide instead of executing the dependent method themselves but still allowing the real implementations to be called for the rest.

For example in the code below, MainClass has three methods - method1, method2 and method3. Assume method1 here is dependent on some external interface, you can mock that up and test method1, but if you have to test method2 and method3 you still have to do the same and also take care of other dependencies if method2 and method3 were dependent on some external interfaces. This is really time taking and tiring.

/**
 *
 */
package com.demo;

/**
 * @author Naga Seshadri
 *
 */
public class MainClass
{

  public String method1()
  {
    // some external invocations
    return "Main Class method1 called";
  }

  public String method2()
  {
    String method1Response = method1();
    return method1Response + ", Main Class method2 called";
  }

  public String method3()
  {
    String method2Response = method2();
    return method2Response + ", Main Class method3 called";
  }
}

To avoid the issue, Mockito provides a way in which you can invoke method2 for test without really calling method1's real implementation but fake it, also you can invoke method3 for test without really calling method1 and/or method2's real implementation, which is called partial mocking as illustrated by the code sample MainClassTest below

package com.demo;

import static org.mockito.Mockito.*;
import junit.framework.TestCase;

import org.junit.Test;

public class MainClassTest extends TestCase
{

  private MainClass mainClassObj;
  private MainClass mainClassSpy;

  @Override
  protected void setUp() throws Exception
  {
    super.setUp();
    mainClassObj = new MainClass();
    mainClassSpy = spy(mainClassObj);
  }

  @Test
  public void testMethod1()
  {
    System.out.println(mainClassSpy.method1());
  }

  @Test
  public void testMethod2()
  {
    doReturn("Main Class Spy method1 called").when(mainClassSpy).method1();
    System.out.println(mainClassSpy.method2());
  }

  @Test
  public void testMethod3()
  {
    doReturn("Main Class Spy method1 called").when(mainClassSpy).method1();
    System.out.println(mainClassSpy.method3());
  }
}

Here is the console output. In this case if you notice we spyed on the object on which we are calling the real methods and stubbed a couple of internal method calls which is very handy. Even though this is good we may not have a good way of doing this when you have private methods being invoked from within you public calls.

Main Class method1 called
Main Class Spy method1 called, Main Class method2 called
Main Class Spy method1 called, Main Class method2 called, Main Class method3 called