Thursday, February 18, 2016

Setup Apache Eagle Developement Environment On Mac

How to setup the Eagle development environment on Mac

Apache Eagle is an Open Source Monitoring solution, contributed by eBay Inc, to instantly identify access to sensitive data, recognize attacks, malicious activities in Hadoop and take actions in real time. Please visit for more information.

This tutorial is based Mac OS X. It can be used as a reference guide for other OS like Linux or Windows as well. To save your time of jumping back and forth between different web pages, all necessary references will be point out.


- HomeBrew

Make sure you have HomeBrew installed on your mac. If not, please run:
$ ruby -e “$(curl -fsSL” you can find more information about HomeBrew at .

- Scala & SBT

Some core eagle modules are written with scala. To install Scala and SBT, just run:
$ brew install scala
$ brew install sbt

- npm

Eagle-webservice module uses npm. To install it, run:
$ brew install npm

- Maven

Eagle is built with maven:
$ brew install maven

- HomeBrew Cask

Install HomeBrew Cask:
$ brew install caskroom/cask/brew-cask Next, install JDK via HomeBrew:
$ brew cask search java you will see all available JDK versions and you can install multiple JDK versions in this way. For eagle please choose java7 to install:
$ brew cask install java7

Note: During this writing SBT has issue with JDK 8. This issue has been tested confirmed by using: -Java 1.8.0_66 -Maven 3.3.9 -Scala 2.11.7 -Sbt 0.13.9 you can find more information about HomeBrew Cask at .

- Jenv

you can use Jenv to manage installed multiple Java versions. To install it:
$ brew install and make sure activate it automatically:
$ echo ‘eval “$(jenv init -)”’ >> ~/.bash_profile
Note: There is a known issue at this writing: Please make sure JENV_ROOT has been set before jenv init: $ export JENV_ROOT=/usr/local/opt/jenv
Now let Jenv manage JDK versions (remember In OSX all JVMs are located at /Library/Java/JavaVirtualMachines):
$ jenv add /Library/Java/JavaVirtualMachines/jdk1.8.0_66.jdk/Contents/Home/ $ jenv add /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/ and
$ jenv rehash You can see all managed JDK versions:
$ jenv versions set global java version:
$ jenv global oracle64- switch to your eagle home directory and set the local JDK version for eagle:
$ jenv local oracle64- you can find more information about Jenv at and

Build Eagle

Go to Eagle home directory and run:
mvn -DskipTests clean package
That’s all. Now you have runnable eagle on your Mac. Have fun. :-)

Friday, July 12, 2013

GWT for new project? No, thanks!

First of all, let me introduce myself briefly. I am a software engineer with more than 10 years java projects development experience. I am a software architect who pays attention to the common architecture NFQ stuff like dependency, code qualification, application maintenance, etc. And, last but not least, I am technology trend follower who sticks with the “moving” of modern software development.

Today I want to talk about GWT because I have done some researches while I am preparing a fresh new web application development. And I want to use this opportunity to give a new glass to some pure Java guy to let them know a little bit more about what is going on with JavaScript recently.

It is very interesting to read the discussion of using/ not using GWT:
  • Company behind the current GWT shows us a brilliant report and tells us “89% of respondents would use GWT on their next project”.

Today, almost one year later after Jochen Krause posted his blog, according to my personal research, I am afraid I have to agree with him and Guy Nirpaz.

Google has dumped GWT and GWT is dying.

I feel sorry to say that since the report from Vaadin has actually confirmed that GWT is a good choice for a new project. Well, the report is brilliant. But while I was reading it I could not stop asking myself why such a report should even exist. Ever see any similar report of JQuery, HTML5 or Hadoop recently? No? Why? Because it is not necessary! Such a report of GWT is trying to let the people calm down and remove the fear we have while considering using GWT on the next project. This is just my personal opinion, sorry about that.

GWT has left Google since 2012. Some people said it is good for GWT regarding the similar movement of Eclipse from IBM to open source community. But in my personal opinion they are not comparable. First, Eclipse is a platform while GWT is just a framework for web application. Second, after moving to the open source community, Eclipse is still heavily used in IBM. I don’t see the same thing happens in Google. Google has actually abandoned GWT and embraces pure JavaScript with HTML5 development and provided Angularjs and Polymer. The community is mad on Angularjs after they met it.

It was a great choice to choose GWT a few years ago while JavaScript was ugly and just toy language used for some fancy animation. Now JavaScript is mature enough for serious project development. It is in fact already used to build some amazing applications like Gmail, Blogger, Google+, etc. Let me show you why you should NOT use GWT for the new project anymore.

Google walks away and community is following

I haven’t seen any life signal of GWT for new project within the Google territory. People follow when Google walks away.

Enterprise application development environment

This is the most frequently talked reason for choosing GWT instead of an appropriate JavaScript framework like Angularjs. You will be benefit from mature development environment and java language itself. Well, that is correct. But recently JavaScript and its development environment become more and more mature:

            IDE – Webstorm
            Tools mamangement – NPM(Node Packaged Modules)
            Rapid development – Yeoman (Yo, Grunt, Bower)
            Build tool – grunt
            Dependency management – bower
            Unit test – Jasmin
            QA code analysis – jshint
            Test automationKarma
            Modular – RequireJS
            Framework - AngularJS
In some areas using JavaScript is even better than developing application in java. Consider what would be done if maven should be updated and what would be done if Yoeman should be updated? Much easier while using NPM right?

Object oriented programming

Many people have concern about JavaScript language itself. This is one reason why they consider using GWT. To be honest, just because JavaScript is a dynamic language does not mean it is not object oriented. You can find many JavaScript OOP tutorial, for example this one from MDN. There are many JavaScript designpatterns can be implemented in JavaScript, even beyond the GoF design patterns. Want to read some good books? Take a look at the post “Required JavaScript Reading”, Rey Bango did a really great work!

Short of JavaScript experience

GWT lets people work with java to build a web application running on the client side. Feel great right? But, look out! JavaScript code will be generated. We do not really get ride of JavaScript. We are end up with generated JavaScript code! It would be not true, if you think you don’t need to know JavaScript when GWT is used in your project. In fact, According to my personal experience, almost every GWT developer knows JavaScript. That makes me, as a software engineer, feel really bad. Why should you let GWT generate the JavaScript that you can write it on your own? In fact, the gap between Java and JavaScript is not as big as people image. It might take some time to understand some core dynamic language concepts like “closure” and “prototype inheritance”. The rest should be really easy for mature Java developer to understand. If you are confused at first glance, maybe you need to learn it three times.

The native language of web application is JavaScript. HTML is going to provide more and more API. People around the world are contributing great frameworks/libraries using JavaScript directly. It is difficult for GWT to follow these fast and flexible developments done by a more tremendous community. If you want to use them within GWT, you (or somebody else) have to make them available in the GWT way. Such a restriction makes me feel really bad. There is really no excuse anymore not to use JavaScript directly.


GWT is a mature framework which provides great features like MVP, data binding, etc. But now, thanks of AngularJS, you will have these features too while using JavaScript. And that is not enough, beyond these features, AngularJS provides some other excellent built-in features, e.g. dependency injection (like Guice does) and Directive which is the killer feature of AngularJS for customization and component integration.


Still think GWT is the only choice for building testable client side RIA? Now is the time to change your mind. You can test every thing by using AngluarJS, Jasmin, and Karma. For example: 

  1. it('should say hello', function() {
  2. var scopeMock = {};
  3. var cntl = new MyController(scopeMock);
  5. // Assert that username is pre-filled
  6. expect(scopeMock.username).toEqual('World');
  8. // Assert that we read new username and greet
  9. scopeMock.username = 'angular';
  10. scopeMock.sayHello();
  11. expect(scopeMock.greeting).toEqual('Hello angular!');
  12. });


The usage of scopeMock via DI and the expect() method looks really familiar for us Java guys, right? :-) 


Want to use some fancy widgets built by other guys? With GWT you have actually only one choice: GXT. Vaadin could be another one if the complete client-side API isavailable. With AngularJS the Directive feature make it possible and easy to integration any other JavaScript widget library. AngularJS co-creator Miško Hevery hasmentioned that AngularJS 2.0 will work with Polymer seamlessly. Is the trend now not clear enough to you?

Mobile app development

Hot topic. It looks like currently everybody wants a (web) mobile app. If you use GWT, you will have no other choice but mgwt teams up with gwt-phonegap. And the project gwt-phonegap shows us exactly the risk of using GWT for new project - You have no direct access to the generated JavaScript and it is painful for any extension and integration. Why I am saying that? Because PhoneGap provides its features only via JavaScript API and you are forced using gwt-phonegap to generate the appropriate JavaScript code, which can call phoneGap JavaScript API. This approach is painful. If you want to use a new xyz web technology built in JavaScript, you have to keep waiting until someone developed a gwt-xyz project or you must develop the gwt-xyz project on your own. Can you afford it? Some people might say you can use JSNI. Yes, you can! But please think about it, why use GWT if you want to call the JavaScript API directly? Using JSNI you will lose most benefits you have because your project is not a pure java application anymore.

If you have GWT project and consider build a mobile web app as a new client view, before you decide to use mgwt and gwt-phonegap, you should at least keep an eye on the development pulse of both projects:

Still don’t get it? Compare with the pulse of JQuery Mobile:

Have you seen the risk of using mgwt and gwt-phonegap in a serious project?

Please don’t get me wrong. Daniel Kurka did a great work. His work of the both projects makes a mobile app of GWT possible. He should get our full respect. But, business is business, you should think of your own benefit and risk.


If you currently want to develop a new client side RIA, still using GWT might not be the best choice, even if you have GWT project experience. For your long term benefit you should consider using JavaScript directly. If I were asked to build an enterprise RIA now, I would use the following architecture and technology stack:

  •  Architecture: SOFEA 
  • Server side: Java & Restful API (I am still a Java guy and Java is still the first choice for the backend of enterprise application.)
  • Client side: AngularJS, RequireJS, HTML5, JQuery Mobile for mobile web, Cordova for hybrid app, some other JS libraries depends on the concrete requirement.
  • Development Tools: maven or Gradle for backend Java project. NPM & Yoeman for frontend JavaScript project.
  • Test: Junit & mockito for Java project. Karma, Jasmine, and PhantomJS for JavaScript project.
  • CI: Jenkins

    Just my two cents, any feedback will be appreciated.