In my Java Programming class at Penn State – Great Valley, we are learning all about Enterprise Java; session beans, JPA, JMS, and all kinds of other Java goodness.  In the process, I am teaching them how to build their projects with Eclipse and Maven using the M2Eclipse plugin.  The plugin has improved a lot in the last few months, but we  still had to work out the kinks for a couple of issues.

The Default Maven Install Run Configuration Fails

This issue can be seen when running a project that has multiple modules in it. In my case we have an ejb module and then an ear module that is dependent on the ejb module.  When we try to run the default maven install task for the project (see image to the right), we get an error:

The following mojo encountered an error while executing:

Group-Id: org.apache.maven.plugins

Artifact-Id: maven-ear-plugin

Version: 2.3.1

Mojo: ear

brought in via: packaging: ear

While building project:

Group-Id: edu.psu.gv

Artifact-Id: classtwo-ear

Version: 0.0.1-SNAPSHOT

From file: /Users/rdimarco/Documents/workspace/classtwo/ear/pom.xml

Reason: Cannot copy a directory: /Users/rdimarco/Documents/workspace/classtwo/ejb/target/classes; Did you package/install active project artifact:

artifact = edu.psu.gv:classtwo-ejb:ejb:0.0.1-SNAPSHOT:compile;

project: MavenProject: edu.psu.gv:classtwo-ejb:0.0.1-SNAPSHOT @ /Users/rdimarco/Documents/workspace/classtwo/ejb/pom.xml?

The problem is that there is a bug when the "Resolve Workspace Artifacts" button is checked.  To resolve the problem, we need to create a custom run configuration, set the goals to install, and make sure the "Resolve Workspace Artifacts" is unchecked.

The build will now proceed correctly

Unable to Locate the Javac Compiler

Many of my students saw the following error: 

Reactor Summary:

[INFO] ------------------------------------------------------------------------

[INFO] Class Two ............................................. SUCCESS [1.483s]

[INFO] ClassTwo EJBs ......................................... FAILED [2.388s]

[INFO] ClassTwo EAR .......................................... NOT BUILT

[INFO] ------------------------------------------------------------------------

[ERROR]

 
Mojo: org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile
 
FAILED for project: edu.psu.gv:classtwo-ejb:ejb:0.0.1-SNAPSHOT

Reason:Unable to locate the Javac Compiler in:  C:\Program Files\Java\jre6\..\lib\tools.jarPlease ensure you are using JDK 1.4 or above and not a JRE (the com.sun.tools.javac.Main class is required).In most cases you can change the location of your Javainstallation by setting the JAVA_HOME environment variable.

As the error message suggests, this issue occurs when you are trying to run Maven and your the runtime JRE used to run the Maven executable is from a JRE and not a JDK.  To fix this, you need to do the following things:

1. Install a valid JDK on to your computer.  You will need to download the JDK from Sun and then install it on your computer.
2. Tell Eclipse about the JDK.  To do this, you will
   1. Go to the Preferences. 
      • On Windows, choose the top menu "Window" and then select sub-menu "Preferences"
      • On a Mac, choose the top menu "Eclipse" and then select the sub-menu "Preferences"
   2. Click on >Java and then on > Installed JREs
   3. You will see a box listing one or more JREs.  Click on the button to the right of this box "Add"
   4. You will be given a list of types of JREs to use.  Choose Standard VM
   5. You will then get a screen asking for the JDK directory.  Click on the Directory button and navigate to the newly installed JDK directory
      • On Windows, this will be something like C:\Program Files\Java\jdk1.6_xx
      • On Mac, this will be something like /System/Library/Frameworks/JavaVM.framework/Versions/1.6.xx/Home
   6. After choosing your directory, Eclipse will think for a bit and then fill in some additional fields on the form.  You do not need to make any changes, just hit Finish.
3. Now we will need to tell Maven to use this JDK when it runs
   1. Right click on your project and choose Run As -> Run Configurations (as you normally would to build)
   2. In the Run Configuration dialog, click on the tab JRE.
   3. Click on the radio button for Alternate JRE
   4. From the drop down list, choose your JDK

You will now be able to run Maven without the error.

Bookmark to:

Hide Sites

Check out these business lessons from Flying Fish brewery.  The lessons learned for them are very pertinent for anyone starting out.  I have said before that an early-stage technology entrepeneur has more in common with an entrepeneur opening up a 7-11 around the corner than they have in common with the problems Larry and Sergei at Google deal with.  This article really brings home some of the key problems that any entrepeneur will have to deal with.

• Investment funding
• Finding customers
• Distribution channels
• Capital investment decisions

I’ve seen a lot of my startup clients make some of the same assumptions and mistakes that the Flying Fish people have.  It is always interesting to me how some problems domains.

Bookmark to:

Hide Sites

Earlier this month I had the opportunity to travel to Tel Aviv to work with my development team there.  This trip was fascinating for me, both personally and professionally, and I learned a bunch of lessons.

#1 Development Process Risk Mitigation

Spending $3-5k for travel will not kill a project, but bad communication can…  Going to Israel, our plan was to have a "mini-project", ship something in the week I was there.  Day 1 involved project planning with a goal of shipping Day 5.  Going through this process showed me what holes we had in communicating with each other.  By communicating, I don’t just mean language issues, I mean effectively explaining what needed to be done to plan, develop, and ship the project.  If we have problems when we are in the same room, we are definitely going to have problems when we are separated distance and time zones.  In my week there, we did not ship on time.  I learned that we had a problem being overly optimistic in some of our estimating techniques.  To me, it showed that some of our slippages in the past were not as much due to the outsourcing model, rather to poor project planning techniques.  At the end of the week, it was my conclusion that either I (or my other team lead) that we really needed to change certain parts of the process to be better at planning and execution of our development interactions.

#2 More People Should Visit

The country was beautiful.  I was turned off a little by the architecture in Tel Aviv at the beginning of my trip, but by the end, I found it to be quite beautiful, especially the older parts of Tel Aviv.  Also, it was awesome to be on the beach in shorts in January, reminded me a little of California.

#3 There Will Never Be Peace

One thing that is missing in most American news analysis, the conflicts around Israel are not as simple as Israel vs. Palestine.  There are so many conflicts, between the secular and the religious, between Israeli Jews and Israeli Arabs, between people of Eastern European/Russian lineage and other groups, between recent immigrants and those that have been there longer, between Fatah and Hamas, the list goes on.  There is no where near a unified front on how the ending should look and people are militant about it on all sides.  The conflict is so much deeper than just us vs. them; I don’t see how the people (especially in Jerusalem) will ever agree on zoning laws, let alone bigger issues.

#4 An International Midge of Mystery

Christina (my wife, aka Midge) came with me on the trip and got to be a tourist while I worked.  Being out of the Philadelphia area really agreed with us.  Philly is a great town, but so insular and stifling.  I think we need to move, just not sure where yet.  If I could find a 3-6 month stint overseas, we would leap at it.

Bookmark to:

Hide Sites

"Can you get me a plan for doing that".  How often have people said that.  More often than not they are looking for some sort of Gantt Chart that shows a list of tasks, completion dates, and dependencies.  Gantt charts are very pretty…I’ve made plenty of them.

But they suck.  And they suck because they convey a level of certainty that is completely unfounded.  It’s pretty rare that we put a plan together where it turns out we actually understood:

• What needed to be done
• How long each task would take
• What other distractions (vacation, crucial issues, etc.) would distract resources from full concentration on the project.

My hatred of Gantt charts stems from the way they make the schedule seem black and white.  So what I want is a way to create a project plan that shows the levels of gray in the timing.  So a task would not take 3 days, it would perhaps have the highest probability of being complete in 3 days, but there are non-zero probabilities that it would take 4, 5, 6 days to complete.  I’d also say that the more tasks in the project and the more resources involved the higher the likelihood of missing tasks, pushing out the schedule even more.

The closest I have found to this is FogBugz’s Evidence Based Scheduling that shows a probability of a release shipping.  I like that it is based on data from developers, but I want to find a generalized way to represent this schedule outside of entering every task into Fogbugz. 

Maybe there’s a product development idea in here somewhere…

Bookmark to:

Hide Sites

Recently, I’ve been working a bunch with Grinder to do some load testing.  I’ve had great success with it in the past, and wanted to punish an app.  My test needs to make HTTP and HTTPS requests which I never anticipated would be a problem.  Unfortunately, my server has a self-signed certificate which the Java processes refused to recognize.  I tried adding the certificates through the Java Console but that led to these weird no peer exceptions (shudder).

I figured that I would have to use keytool to load the certificates.  What I did not realize is that you cannot load a self-signed key where you already have a certificate using keytool directly!  So I had to follow the following steps

1. Convert my certs from PEM format into DER format

> openssl pkcs8 -topk8 -nocrypt -in server.key \

-inform PEM -out key.der -outform DER > openssl x509 -in server.csr -inform PEM \

-out cert.der -outform DER

2. Use the Java code from this AgentBob post to create a keystore

> java -Dkeystore=mycerts ImportKey key.der cert.der

3. Now when running the TCPProxy, I had to add the following:

java -Djavax.net.debug=all -classpath $GRINDER_JAR \

net.grinder.TCPProxy -console -http \

-keystore mycerts -keyStorePassword importkey

4. To use the certs from my Agent process

from java.lang import Systemgrinder.SSLControl.setKeyStoreFile(System.getProperty("keystore"),System.getProperty("keypass"))

4. Finally, I needed to add this to the properties file for my Grinder agent process

grinder.jvm.arguments=-Dkeystore=mycerts -Dkeypass=importkey

And tada it works! One other tidbit: using -Djavax.net.debug=ssl was invaluable in debugging. You can use -Djavax.net.debug=help to find out all of the debug options.

Bookmark to:

Hide Sites