Installing Intellij IDEA on Mac and Ubuntu

Development, , , , , ,

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.

Auberge de la Ferme: Wine Choices for Dinner

Experiences, , ,

I never had the opportunity to write about the experience at Auberge de la Ferme. I will do it in another opportunity because now I just want to share our wine choices for dinner. They have an extensive selection of wines in a big cave and every time we go there we spend a lot of time choosing the right one, hoping it is good enough for the occasion.

This time we made a very good choice at a good price. They are:

Montravel

We had a gastronomic dinner with 7 services and most of the dishes demanded a white wine. We choose Montravel, that was one of the waiter‘s suggestions. This is a very good 12% dry and fruity wine 2013.

White wine Montravel
White wine Montravel

Julienas

Some of the dishes demanded a red wine. So, we once again accepted one of the waiter‘s suggestions. The dry, 13% red wine Juliénas 2011.

Red Wine Julienas
Red Wine Julienas

We still are amateurs in the art of wine appreciation. So, I’m saving the choices here for the next time :-) .

Migration from org.cejug.yougi to org.yougi

Development,

We have been using the package org.cejug.yougi since the beginning of the project. That’s more than 3 years. Recently, we decided to rename it to org.yougi, removing the package cejug. Why? Because none of our current contributors owns the domain cejug.org anymore. Since we own the domain yougi.org, we felt comfortable to make the change. By the way, CEJUG’s website is now at cejug.net and they still are our main contributors. Thank you very much!

When you update your fork, everything will compile normally, but it won’t be possible to deploy the application due to a Liquibase limitation. That’s the framework we use for database migration. To fix this problem, simply execute the following script directly on your database:

# update databasechangelog set filename = concat('org', substr(filename, 10));

#commit;

Now, the deployment is expected to work normally. Everything gets back to normal. If you forked Yougi after the 4th of July 2014, you don’t have to do anything. Your database will be created already with the fix.

New Technical Philosophy

Community, Development, , , , , , , ,

We used to develop Yougi using NetBeans + Glassfish since the beginning of the project, in 2011. After the issue with Glassfish, we decided to evaluate other application servers. WildFly and TomEE appeared in the radar. After some time analysing both, we decided to migrate to WildFly, which was the only alternative supporting Java EE 7 at the time. Unfortunately, we didn’t reach the same level of productivity as before. We immediately noticed that NetBeans struggled to work seamless with WildFly the same way it works with Glassfish. It’s true that the integration nowadays is getting better, but at that time (beginning of 2014) we were pushed to analyse alternatives for NetBeans.

Screen Shot 2014-05-05 at 23.10.38

The time we have lost migrating from Glassfish to WildFly and from NetBeans to something else was so significant that we decided to change our philosophy. The basis of this change are summarised in two words: freedom and independency. In practical terms, the changes were the following:

  1. IDE independent: we used to promote Yougi almost exclusively through NetBeans. We even suggested people to install it in order to easily contribute to the project. Now, we will also promote Eclipse and IntelliJIDEA. This way, if Oracle decides to stop supporting NetBeans, we will be pretty comfortable with that.
  2. Java EE implementation independent: Yougi was exclusively running on top of Glassfish. Now, we will make sure it runs on top of at least two different application servers: WildFly and TomEE, which are two production-ready open source alternatives for Glassfish. In case one of these servers is considered non production-ready or it doesn’t evolve anymore, we will migrate the entire project to another technology. In summary, we will support the Java EE technology as long as it has two very competitive open source implementations. TomEE doesn’t implement Java EE 7 yet. So, we will start testing Yougi on it as soon as they release a beta version.
  3. We’re still committed to Java: Despite several ups and downs in the last years, Java is still a great technology. It is showing consistent evolution and deals very well with backward compatibility. Even if we are forced to move to another server technology we will think twice before moving from Java. In the meantime, we expect that Oracle keeps increasing community participation, transparency of processes and open source  availability through the JCP (Java Community Process). These are important criteria to keep up our motivation on using the Java language.
  4. … but not exclusively anymore: We recently decided to include Scala and Play Framework in the project in order to  evaluate a new approach for server-side technology. We intend to compare it with Java EE to understand what we are missing in terms of architecture and design. We are going to give more details about this in the post that follows this one.

Screen Shot 2014-05-05 at 23.14.37

This philosophical reorientation has been discussed in CEJUG‘s mailing list in the last 4 months. The debate has been intense and it even produced two relevant publications: an article published on WildFly’s website explaining how to migrate an application from Glassfish to WildFly, and a two pages contribution to a RebelLabs report about migrating from Glassfish to WildFly and TomEE. We are happy that Yougi and CEJUG have helped not only their communities but the entire world with the knowledge we have produced.

Finally Automating Tests

Community, Development, , ,

Yougi has been around since January 2011. That’s more than three years of continuous development. The project has accumulated a total of 13 direct contributors throughout these years, 53 forks, 580 commits, producing approximately 18k lines of Java code. Unfortunately, none of those lines are covered by unit and integration tests. That’s a shame.

It’s time to change that. Starting today, we’re going to continuously write unit and integration tests to guarantee the high quality of this project and teach the community how to do it in a proper and effective way.

exploratory-tests

We will start writing unit tests to cover classes that don’t depend on the container to run. All we will need for this is JUnit 4. We’ve identified more than 60 opportunities for this kind of test and we already created all test classes and test methods for each one of these opportunities. Check this out at https://github.com/htmfilho/yougi/tree/master/src/test. After a while, when we accumulate a good number of unit tests, we will start writing integration tests with Arquillian. We have two reasons to postpone it a little bit:

  1. we have to make available a continuous integration server (i.e. Jenkins) for the project in order to run integration tests every time a commit is pushed to the repository.
  2. we are still learning how to make the best use of Arquillian, which is not so obvious to configure and use. We will share our knowledge as we learn it, but if you already master it, then your contribution is very welcome.

We believe writing tests is probably the most important contribution to an open source project. So, we would like to ask you to help on this effort by implementing some of these tests. It will make a huge difference on your CV, since Yougi is already a mature project. All you have to do it:

  1. Fork the project on GitHub: https://github.com/htmfilho/yougi.
  2. Build and deploy it locally.
  3. Choose one or more tests to do and discuss them with the community in the issue #197. It will help us to organize who is doing what and share the knowledge we have about the business logic.
  4. According to the feedback you received from the community, start writing your tests and submit a pull request when you are done.
  5. We will analyse your pull request and suggest changes if necessary. If not, we will simply accept your pull request, closing the flow of contribution.

If you already want to contribute with integration tests, please read the discussion going on at issue #66. It’s not urgent, but every contribution is welcome.

If you have questions about the unit tests, you can comment below or directly on the issue #197.