Sunday, February 23, 2014

Temporary workaround on determine_new_packagename in AOO build

Last week is a challenging week for me both in my day job and also open source work. When I'm making a full build on AOO, there was an error in function determine_new_packagename.
ERROR: ERROR: More than one new package in directory /home/kokhoe/workspace/aoo-trunk/main/instsetoo_native/ ( /home/kokhoe/workspace/aoo-trunk/main/instsetoo_native/ /home/kokhoe/workspace/aoo-trunk/main/instsetoo_native/
in function: determine_new_packagename (packagepool)
My initial though is by removing the whole directory will resolve the problem, but eventually it is not. There is also a defect has been raise but the work around is not working for me. Fortunately I met a peer who gave me a great help on this issue. This problem is due to the version of the EPM (stands for ESP Package Manager) installed in the system isn't compatible with AOO build. AOO require EPM version 3.7, other than this version the build will not pass. I am require to download the EPM version 3.7 source specifically, and build on my own.

A quick check on the version installed on my system, I see this:
epm --version
ESP Package Manager v4.2
Copyright 1999-2007 by Easy Software Products.

EPM is free software and comes with ABSOLUTELY NO WARRANTY; for details
see the GNU General Public License in the file COPYING or at
"".  Report all problems to "".

To verify whether AOO build is using the EPM install in the system:
grep -i epm config.log
  $ ./configure --with-epm-url=
configure:11566: checking whether to enable EPM for packing
configure:11577: checking for epm
configure:11595: found /usr/bin/epm
configure:11608: result: /usr/bin/epm
configure:11633: checking whether the found epm is the right epm
configure:11641: checking epm version
This shows that AOO build is using the EPM installed in /usr/bin directory. Since I don't want to uninstall this component from my system, I have to configure the AOO build to bypass that version and route to my specific build. To do this, issue this command:
./configure --with-epm=<EPM_binary_location_in_file_system>
Note, the EPM binary must be build before this command is execute, don't expect the ./configure command will make the build from the source. I have also try --with-epm-url, this option will do the downloading and extraction work automatically but it doesn't work.

Saturday, February 22, 2014

@Rule allows me to verify the message

Nice sharing from Stackoverflow peer suggesting a new solution on testing exception. This adds more flexibility to my test. Assuming I'm testing on a class that throw NullPointerException:
public class ClassCauseException {

 public void funcA() throws NullPointerException {
  throw new NullPointerException("Some NULL message");
Usually I'll do this:
 public void testFuncB() {
  ClassCauseException c = Mockito.spy(new ClassCauseException());
That will only tells me funcA will throw an NullPointerException. But I couldn't verify whether whether the right message is display. Anyhow there is a more elegant way for this issue. With @Rule, I'm allow to verify whether the display message when an Exception is being thrown. For example, when the following test is execute, I'm expecting an NullPointerException will be throw, and a message The NULL value should be display. Eventually the test will failed due to the actual message Some NULL message is display.
public class RuleExceptionTest {

 public ExpectedException exp = ExpectedException.none();
 public void testFuncA() {
  exp.expectMessage("The NULL value");
  ClassCauseException c = new ClassCauseException();

This could be useful if I care the type of Exception being thrown and what message is being display.

Saturday, February 8, 2014

Why Eclipse Kepler complaining invalid overload of endl?

This code cout << "blah blah blah" << endl; not suppose to be an error. Interestingly Eclipse Kepler state that this was an error:

Invalid overload of 'endl'

My mistake again? A stupid though passing by my brain, urging me to trying out this experiment:
    cout << "blah blah blah";
    cout << endl;
And this will compile OK. Miracle happen? Anyhow there is a cure for this problem:
  1. Windows menu > choose Preferences option > select Code Analysis on left panel.
  2. Under Syntax and Semantic Errors > change Invalid overload's severity from Error to Warning.
I wasn't really sure why Eclipse have such configuration, a message drop to Eclipse forum regarding this problem, and they reply that there was a fix on this error. Should be on the way on next release I guess.