Tag Archives: ide

Installing Intellij IDEA on Mac and Ubuntu

It has been a year since I moved my professional and community development projects from Netbeans to IntelliJ IDEA. Netbeans is still a great IDE and I recommend it over any other open source alternative, but the productivity brought by IntelliJ is so great that the time I’ve saved using this IDE already paid off.

I have IntelliJ installed at home and at the office. It’s the same license but the deal is: you can install it in several computers but use one installation at a time. I use Mac and Ubuntu at home and my experience installing IntelliJ in those platforms was the following:

Installing on Mac

I’m not really going into step by step here. IntelliJ is pretty easy to install on Mac, but I had a problem with the JDK and I’m going to focus on that now. IntelliJ uses the JDK distributed by Apple by default, which is a JDK 6 implementation. Well, this is not a big deal, since we can install the most recent JDK and configure our projects in the IDE to use it instead. But, for some unexplained reason, I couldn’t configure the IDE to start the application server in a JDK different from the one used by IntelliJ (JDK 6). In the image below, you can see I’ve configured JDK 8 to run WildFly, which requires JDK 7 or superior, but it didn’t work.

wildfly-configuration

So, I had to change the JDK used by the IDE. For that, I:

  1. closed IntelliJ;
  2. went to the folder where all applications are installed (/Applications) and selected the file “IntelliJ IDEA ##.app”;
  3. accessed the context menu (mouse click with two fingers) and selected “Show Package Contents”;
  4. opened the file “/Contents/Info.plist” and
  5. located the JVMVersion to change its correspondent value to 1.8*.

After this configuration, I could finally make IntelliJ run Wildfly.

Installing on Ubuntu

The installation on Linux is traditionally more complicated. I wonder why people complain about the low number of Linux desktop users. 🙂 The IntelliJ IDEA download page mentions only two steps:

  1. unpack the “ideaIU-XX.Y.Z.tar.gz” file using the command “tar xfz ideaIU-XX.Y.Z.tar.gz” and
  2. run “idea.sh” from the bin subdirectory.

However, this instructions don’t deliver IntelliJ as delivered in other platforms. People don’t go to the installation folder and execute the file idea.sh. They either create a desktop icon or add the bin directory to the path, but these steps are missing. So, in my understanding, the installation is not completed. To launch IntelliJ from anywhere in the command prompt:

Become the root user:

sudo -i

Move the unpacked folder to “/opt/idea”:

mv ideaIC-XX.Y.Z /opt/idea

Edit the file .bashrc:

gedit ~/.bashrc

Add the following line to the end of the file:

export PATH=/opt/idea/bin:$PATH

Log out and log in to the change take effect.

To add the launcher icon on the desktop, there is a soft and a hard way.

The Soft Way

Fortunately, IntelliJ can help you once you run it for the first time. In the welcome window, select “Configure”:

intellij-configure

And then select “Create Desktop Entry”.

intellij-configure-desktop-entry

That’s it!

The Hard Way

As a good Linux user, you may prefer doing it the hard way, as follows:

Create a desktop file:

cd /opt/idea
gedit idea.desktop    

Copy the content bellow to the file:

      [Desktop Entry]
      Name=IntelliJ IDEA 
      Type=Application
      Exec=idea.sh
      Terminal=false
      Icon=idea
      Comment=Integrated Development Environment
      NoDisplay=false
      Categories=Development;IDE;
      Name[en]=IntelliJ IDEA

Install the desktop file:

desktop-file-install idea.desktop

Create a symlink:

cd /usr/local/bin
ln -s /opt/idea/bin/idea.sh /usr/local/bin/idea.sh

Finally, display the idea icon in dash:

cp /opt/idea/bin/idea.png /usr/share/pixmaps/idea.png

At this point, you will finally feel IntelliJ as an application, integrated with the desktop and always ready to be executed.

Case Study: Migrating a Large Project from Ant to Maven

The truth is we had been under difficult times. We spent almost three months to migrate our build mechanism from Ant to Maven. That’s the minimum time you have to put in your schedule if you are planning to do the same in a large project. There are still some collateral effects of this migration that we are struggling to solve, but fortunately they are not so critical.

The Context

Just to contextualize a little, we have a full Java EE 6 system composed of 25 integrated applications and each application has an average of 3 modules (EJB, WEB, etc), reaching ~80 modules. We manage something close to 500K lines of Java code (JSs, CSSs, JSPs and JSFs files not included), according to our Sonar analysis. It takes between 15 to 20 minutes to build everything. It depends on the mood of the server.

The decision to go for Maven came as a precondition to start a large scale refactoring of the application, which, despite using the latest technology available (Java EE 6), has suffered from a mix of frameworks, design flaws and multiple architectures over the years. We are going towards a single architecture grounded on the Java EE specification in order to optimize dependencies, reduce the evolution cost in a middle/long-term perspective and run seamless in our Glassfish Application Server.

The Duty

The project structure is almost the same as it was with Ant, thanks to the flexibility provided by Maven. We have a super pom.xml file in the root folder, which basically declares all modules, plugins, additional repositories, and dependencies. The dependencies are declared in a dependency management (using the tag <dependencyManagement>). This way, all version numbers are declared in a single place. Besides the super pom.xml, we have a folder for each integrated application and inside each folder we have a application pom.xml and three other folders, one for each Java EE module (EAR, EJB, WEB). The application’s pom.xml inherits from the super pom and it basically declares the modules composing the application. Inside the module folders we have one more level of pom files. These pom files inherit from their respective application’s pom files and describe the particularities of their modules. In summary, we have three levels of pom files, from the system as a whole to the level of Java EE modules.

Example of structure similar to the one we are using.

For development purposes, we avoid deploying the entire application locally. That’s why we have an EAR module in each application. This way, we save time deploying only the application we are working on. Those application EAR modules are not taken into consideration when packaging to deploy on the servers. To build the full EAR for the servers we have a special application that contains a EAR module, whose pom file declares all EJB and WEB modules as dependencies. Performing the goal package on this pom.xml will actually create the super EAR file.

EAR module to package the entire system in a single deployment file.

The Good

Evaluating the project after Maven implementation, we could notice the following benefits:

Maven contributed to simplify the logic behind the build: Now, everybody is aware of what is going on because pom.xml files are much easier to understand than build.xml files. Our Ant files were generated by Netbeans, thus very big and unreadable. We were actually lucky to have them working for so long, since it was difficult to maintain them. No question that we would find a point of irremediable chaos very soon.

Maven also contributed to put some order in all project dependencies: We went from a ~100 MB EAR package to a ~50MB one, a very significant reduction of 50%. It contributed to make the deployment time shorter.

We had the opportunity to clean up the project: While gathering the dependencies to write the pom.xml files, we discovered that some modules were not needed any more; libraries spread through the modules were also removed in favour of Maven’s dependency management. In summary, we have said “Maven is a nightmare” until the day we finally had everything in order and we became happier and relaxed. That’s what most people say as well, since it’s not easy to find solutions for a particular scenario, and everybody has a particular scenario to deal with.

Short learning curve: Once Maven was put in place, we visited all developers, reconfigured Netbeans to recognize the Maven projects and explained to them how to proceed from that point on. All of them could immediately continue with their development activities and just a few call for support were triggered. None of these calls were blocking issues. I have to say that Netbeans contributed a lot to reduce the learning curve because all necessary goals are performed directly from the IDE and there is no need to go to the command line, as it usually happens with Eclipse.

The Bad

Unfortunately, we had some setbacks:

The build now takes longer with Maven: We have noticed a decline on developers’ productivity due to that, making us a bit frustrated at the end 🙁 Since we are not going to rollback to Ant, we are considering JRebel for dynamic reloading of changed code to compensate the additional time we are spending.

We are using some libraries that can’t be found in Maven’s central repositories or elsewhere: Some are commercial libraries and others are too old. We also found libraries available with inconsistencies, throwing many exceptions at runtime (i.e. Apache FOP). For each one of these situations we had to find workaround solutions that were not so elegant, but we cannot stay like that for so long. We have to install a local Nexus repository to address special cases. This is in our check-list.

Occurrence of unexpected behaviours: the best of the efforts is not enough to avoid unexpected behaviours in the application. We have built a spreadsheet listing all applications and their respective modules; documented all dependencies from libraries and between modules; depicted the project structure; went deeper into details. In order to elaborate this spreadsheet we spent several days investigating the guts of the system, absorbing low level mechanisms and design decisions. All the collected information was used on the migration. Nevertheless, the rearrangement of dependencies and the removal of duplicates and unused libraries caused broken navigation flows, alert messages coming from nowhere, changes on URL paths and many other surprises. Unfortunately, we couldn’t predict those problems and we spent much more time on fixes than what was initially foreseen.

The Conclusion

I would like to conclude giving some advices for those planning to adopt Maven in a middle/large scale project:

Communicate the migration to end-users: it’s very important to communicate to end-users what is going to happen in the coming days. Users should be aware that, as they have the duty to improve their business, we also have the duty to improve ours. It means the delivery of new features will temporarily slow down to pave the way to a better product with faster releases. If they are not aware of what is going on, they will have very low tolerance to problems, undermining the reputation of the project.

Don’t be afraid to change even what is working well: We have questioned ourselves why to migrate to Maven if Ant is working so well. Actually, our strategy is to reduce complexity to streamline the resolution of problems. So, we were not afraid to migrate because preventive measures are very important too.

Keep the entire migration under version control to help the investigation of problems: Once all pom files were created and versioned, every little changes in those files should be committed separately in order to revert changes in case of unexpected problems. It helps to isolate the causes. It is also good to know that there is no conflict between Ant and Maven files. So, both can stay in the same branch during the migration without any impact on developers.

Don’t start a big refactoring without a build system like Maven: a successful refactoring depends on a detailed understanding of the application and adopting Maven will push you to perform an extensive investigation. In addition to that, the project will be cleaner and better organized.

There are other alternatives to Maven, such as Apache Ivy and Gradle, but, despite all deserved criticism, we still recommend Maven when replacing Ant because of its maturity; vast plug-in portfolio; abundant documentation on the web; and rich IDE support. However, it’s a good idea to evaluate other alternatives once Maven is put in place. After the initial tsunami, other waves will come quietly.

Integrating Jira with Netbeans

One of the advantages of hosting your open source project at Java.net is the availability of Jira to track your issues. Jira is one of the most popular issue tracking system available on the market, which drives tool developers to support it. This is the case of Netbeans, my working IDE, and also the case of Eclipse.

I recently configured my Netbeans to access Jug Manangement‘s issues. If you want to do the same, or with another project hosted on Java.net or even connect to the Jira available on your company’s Intranet, then the following instructions may help you.

The first step is to install Jira plugin on Netbeans. In the menu, select Tools and then Plugins. Go to the tab Available Plugins and select JIRA. Follow the installation procedure and restart the IDE at the end. The figure below shows the plugin already installed. You may check as well if JIRA is in your list of Installed plugins to make sure everything went well.

In the view Services, where we connect to databases, webservers and others, we also find a new kind of service called Issue Trackers. By clicking with the right button on this service, you are about to create a connection to a issue tracker. A dialog like the following figure appears. Give any name to your connection, since this is not a predefined value. In case of Java.net, use the URL https://java.net/jira and the credentials you use to authenticate in the portal. Click on Validate to make sure that you input the values correctly and the connection with the server is working. Click on Ok to finish.

Now, you are connected but not ready to work yet. The next step is to find the issues. For that, click with the right button on the issue tracker that you just created and select the option Find Issues. It opens a new tab in the editor area where you are able to build your query as you usually do using Jira on a web browser. When you build the best query for your needs you can save it to constantly work with that. In the following figure I built a query that shows me all open issues of the project jug-management.

You can do something similar to your project and control your issues directly from the IDE. One of the main benefits of this approach is that, by restricting the use of the browser, we reduce the probability of losing the focus on the work due to other entertainment activities on the web such as news, social networks, chatting and so on.

Development Environment to Work with WebLogic

I have to confess that, despite not evolving as fast as the Java EE specification, Oracle WebLogic is a f*** good application server. Its stability is impressive and works smoothly with popular IDEs, such as Eclipse and Netbeans. Of course its qualities come with a cost, which is expensive for poor developers like us, but it’s worthwhile for companies.

The official name of WebLogic is “Oracle WebLogic Server 11g Standard Edition”. It is part of a broader range of products called “Oracle Fusion Middleware”, which offers a complete support for enterprise service-oriented applications (SOA). I’m currently working with WebLogic 10.3.4, which is the first version that supports JSF 2.0, my favority web framework. WebLogic is available for download on Oracle’s website. Go to the download page to get your copy. To install it:

  1. Unzip the file in your development folder. For example /home/you/java/weblogic.
  2. Create the environment variable JAVA_HOME, pointing to your JDK installation.
  3. Create the environment variable MW_HOME pointing to /home/you/java/weblogic.
  4. Go to the command line and run the installation configuration script $MW_HOME/configure.[sh/cmd].
  5. Create the domain to start working with WebLogic, running the command MW_HOME/wlserver/common/bin/config.[sh/cmd] and following the instructions on the screen.
  6. Start a web browser and open the url http://localhost:7001/console to access the administration console.

Now, we have to configure the IDE to start, debug, and stop WebLogic, as well as deploy Java EE applications. Because most developers actually use Eclipse as a working IDE, let’s configure it, installing the necessary plugin. I’m using Oracle Enterprise Pack for Eclipse (OEPE), a plugin that empowers Eclipse to develop Enterprise Java Application for Oracle Products. To install it:

  1. Open Eclipse and go to the menu Help – Install New Software…
  2. Add a new repository by clicking on Add…
  3. Inform the name Oracle Enterprise Pack for Eclipse and the URL http://download.oracle.com/otn_software/oepe/indigo if you are using Eclipse Indigo, or http://download.oracle.com/otn_software/oepe/helios if you are still using Eclipse Helios.
  4. Follow the instructions and restart Eclipse to finalize.

 Finally, configure the plugin to integrate the IDE with Eclipse:

  1. Go to the menu Windows – Show View and select Servers.
  2. Click with the right button of the mouse on the working area of the view and select New – Server.
  3. In the list of server types, go to the category Oracle and select Oracle WebLogic Server 11gR1 (10.3.4), or the version of WebLogic that you have installed. It’s important to select the right version, otherwise an error will continously occur.
  4. Make sure that the field Server’s host name contains the value localhost and press Next.
  5. In the field WebLogic home inform the path /home/you/java/weblogic/wlserver.
  6. In the field Java home inform the path to your JDK installation.
  7. You can optionally install some server extensions. I recommend to install all available extensions, clicking on Install, besides each item. Press Next to continue.
  8. Leave the option Local selected in the Server type field and inform the location of the domain. The domain was created in the first part of this tutorial, when we executed the configuration assistent. 
  9. Press Finish to conclude.

That’s it! Make sure to select this server when creating a new Java EE application. Don’t hesitate to share your experience while following this tutorial.

Jersey and JSF Conflict caused by Netbeans

Have you noticed that JSF 2.0 has a new pre-defined directory called “resources” that is located in the web content? According to JavaServer Faces 2.0, The Complete Reference, “files in this directory are treated specially by the JSF Runtime. (…) files and directories within the /resources directory are intended to be included in other pages in the application. Content here can be images, stylesheets, and composite components.“. Therefore, if your Java web application has a /resources directory with a different meaning, then you have to consider renaming it to avoid conflicts when migrating to JSF 2.0.

But there are more conflicts to deal with. I was having some relaxing time programing my JSF 2.0 application (Yasmim) on Saturday night when I decided to implement some RESTful web services. Knowing that Netbeans is like a Swiss army knife when developing JEE applications, I went into its special features to support the JAX-RS specification (JSR 311) and I could get most of the necessary configuration done automatically. However, this automation causes a conflict with the JSF application if you don’t pay attention to a simple detail shown in the figure below.

The field “REST Resources Path” has the default value “/resources”. This path is used in the application URL to denote the invocation of RESTful web services. For instance, in the URL “http://localhost:8080/yasmim/resources” anything after “/resources” is considered as a RESTful web service. If something after “/resources” is not correctly mapped, then a HTTP error occurs. This is actually a good practice because the key abstraction of information and data in REST is a resource. Representing it in the URL makes it clear.

However, when the application also uses the JSF 2.0 framework, this REST resource path conflicts with the JSF resources directory. As a consequence, files in the resources directory obviously are not mapped as services and won’t be available for JSF pages. In practice, CSS and script files become unavailable, destroying the design and layout of the website.

To solve this conflict, we have to change the proposed resource path to another value. In my case, I’m using “/service”, which is still coherent because REST is a style of web service implementation. After changing this value you have to clean and rebuild the project and redeploy the application because hot deployment in Glassfish doesn’t work in this case.