## How to improve the terminal window in IDEA

Published on:

I present here a small tip for improving the IntellJ IDEA Terminal window.
Under Linux, it doesn't execute the ~/.bashrc file at startup. so it doesn't have the correct PATH and other important settings like environment variables.

My first attempt was to create a ~/.profile script that called my ~/.bashrc. It worked, but whenever I rebooted my computer, I couldn't log in. My KDE desktop complains. I have to open a console session in order to fix it.

Luckily, I've found a simple solution that works, and doesn't have this nasty secondary effect.

Open the IDEA settings, as shown in the following screenshot:

The important setting is to add the -i parameter to bash. In this way, the shell becomes interactive, and executes .bash_rc, like a regular console Window.

Published on:

## The problem

I need to select in a Jenkins job a branch of a GIT repository to work on.

## Possible solutions

### The git-parameter plugin of Jenkins

This standard Jenkins plugin called git-parameter does the job, but it has these limitations (at least in May 2015):

Let's see if we can see other solutions.

### Solution based on Groovy scripting

This solution needs a slight modification to the server, supposing you are using gitolite for authorizing the access to your repository.

Following this guide, I have added a new command called branch.

For it to work, I log in to the computer that hosts the gitolite server and edit the .gitolite.rc file:

then I create the 'branch' command:

and place this content:

Let's make it executable:

Now let's test it:

and remotely:

It is left as an improvement, to control if the user has access to the repository.

#### Create the parameter

Now let's configure our Jenkins job to include a parameter.

I use the Extensible choice plugin in order to have a dynamically filled combo box.

I configure to have a source of System Groovy Choice parameter, and enter this small Groovy script:

git highlights the current repo with a star, and places some space at the left for aesthetical purposes.

If the parameter has a name of branch, then in the Branches to build field you can simply type origin/\$branch.

This solution is simple, and doesn't have all the limitations of the previous solution.

Published on:

## The problem

In an app that uses JVM (Java Virtual Machine), it is normal to use 3rd party code, called dependencies.
Sometimes, some bad-behaved jars include 3rd party dependencies embedded, or the same jar can be found under different organizations. In this case, build tools like SBT, Gradle or Maven are not able to evict, and choose only the latest one.

If there are 2 different implementations of the same class in the same JVM, it is random which one will be used, and this can produce nasty bugs like it works in my computer but not in yours. It can be hard to diagnose this kind of problem.

## Possible solutions

In Maven, I've used successfully the duplicate-finder-maven-plugin plugin. But after searching for SBT plugins, I've found none.

At first, I wanted to create a new plugin, but a significant part of the code is shared with the sbt-pack plugin. So, I've decided to fork it, and send a pull request to the original author.

## sbt-pack plugin

For that purpose, I've modified the sbt-pack plugin, and added a new task called checkDuplicatedDependencies for detecting it.

The checkDuplicatedDependencies will fail and provide a list of all incompatibilites, in case it finds the same class in 2 different jars.

If the same class is duplicated, but it's the same implementation, it won't complain.

This is detected by computing a MD5 hash of the contents of the file.

If you consider the found conflicts are inofensive, in order to ignore them in a future run, use the checkDuplicateExclude setting. The value of this setting is automatically given.

Here is an example of report:

As you can see, clashes are common for big projects like mine that has about 300 dependencies.

Published on:

## The problem

If you're working in Linux, with IntelliJ IDEA embedded Terminal, .bashrc isn't called.

## The solution

Create in your home directory this simple script, and it must be named .profile:

Published on:

## The problem

We have a Java or Scala app that has some dependencies and one entry point.
We would like to:

• have all needed jars in a directory call i.e. lib.
• be able to start our app by simply executing "java -jar myapp.jar".

Suppose that:

• we have the a multiproject build.sbt and
• the project myapp holds the entry point mycompany.myapp.MainClass

then this would the our build.sbt would be something like this:

We are filtering scala-library.jar as this app is Java-based. SBT always adds scala-library.jar.

In this way, all the needed classpath is already coded in the MANIFEST.MF and it's easier to launch our app.

This has been tested with SBT 0.13.7.

## How to set arguments through the command line in SBT

Published on:

Suppose you want to provide externally some setting in SBT.

You could create an input task or you can set setting from the command line.

Now, let's explain how to do the 2nd choice.

Suppose you have this in your build.sbt file:

Then from e.g. Jenkins, you could set the build number in this way:

In this example we have shown its current value, but we could you something more practical like package.

## Choosing the blogging platform

Published on:

My requirements are:
- Low cost or free, as my purpose is earning no money with it.
- Easy to learn and use
- Easy to insert snippets of code

Some candidates:

• Free Wordpress doesn't allow any plugins. You need some hosting if you want enough power.
• I've tried a little Weebly, but it isn't suitable for sharing code.
• Jekyll is powerful enough, it's integrated with github, and has a great community, but you cannot use any computer. You need to have installed git, Ruby. It uses familiar MarkDown syntax.
• Finally I've chosen Logdown, as:
• it provides more visual feedback,
• it also uses MarkDown syntax.
• the free edition covers my needs.
• I have always the choice of exporting my blog elsewhere.

## Migrating to SBT

Published on:

I'm in the process of migrating a complex build process involving C++, Python, Java, Javascript and Scala code from Ant, Maven and shell scripts to SBT.

What I like of SBT is:

• its simplicity combined with power. I don't have to resort to write code in external fashion.
• much more compact than Maven.
• Maven doesn't know much about dependencies. If I run project A that depends on library B, and I've changed some source file in B, Maven doesn't recompile B.
I've used successfully before SBT in the Android world, even though Gradle is more used.