Generating a link to your issue tracker with IntelliJ

Sometimes it’s a good practice to post a commit message to your VCS (version control system), including a pattern with the issue number.

For example, you could commit changes towards Git or Subversion, with this commit message : « I fixed this nasty bug : #123 ».

And it could be nice to automatically generate a link to your issue tracker directly inside your favorite Java IDE.

Here’s how to do with IntelliJ IDEA :

  • Go to File > Settings > Version Control > Issue Navigation
  • Then add an item : here you have to fill in the issue ID (regex), and the issue link that will be generated (regex with replacement of the capturing group)

The dialog box you’ll get looks like this :


If you want to capture just a part of the regex, you can use the capturing groups.
Let’s say the pattern you use is « #issue-number », but you want to exclude the « # » from the URL generated. So in this case you will use a regex with one non-capturing group, and a capturing group.
So the issue ID regex will be : (?:#)([0-9]+)
And the issue link will be : http://my-issue-tracker/$1

That way, you’ll be able so see a clickable link in the Version Control window (ALT+9).

See also :


Where is JBoss AS 7.2.0.Final ?

En théorie, JBoss EAP 6.1.x est basé sur JBoss AS 7.2.x. Sauf que cette dernière version est introuvable sur leur page de téléchargements. » Mais pourquoi donc ??? Un article en expliquant les raisons :

Un extrait de cette FAQ JBoss expliquant ce qui est arrivé à la version AS 7.2.0.Final :

Q: What happened to 7.2.0.Final?
A: 7.2.0.Final was always the basis for EAP 6.1.0.Alpha. Due to the new wide-availability of 6.1.0.Alpha, and for simplicity reasons, we’ve released just one release called EAP 6.1.0.Alpha.

Une petite définition de ce qu’est une version EAP (source FAQ JBoss) :

Q. What is JBoss EAP?
A. JBoss Enterprise Application Platform (EAP) is the productized version of JBoss Application Server (AS).  It’s the culmination of thousands of hours of QE, bug-fixes and co-ordination to make sure you can be as productive as possible building your apps.

Un extrait concernant les problèmes de licence (source article :

EAP.Alpha is licensed under LGPL version 2.1 or later, just the same as previous community releases. Also as before, EAP releases other than Alphas, are available only with a paid production subscription or no-cost developer subscription, which restricts the use of binaries to development purposes only, not to be deployed into production environments.

Un extrait sur l’équivalence entre la version EAP alpha et la version community (AS) (source article :

As mentioned above in the case of JBoss, the alpha version is « equivalent, or better, quality » to the community version.5 Let’s be clear, so long as any version of JBoss (or any software), and regardless of whatever it is called, is offered under LGPL, the copyright holder cannot require you to do anything beyond what the license already says (e.g., purchase or use a particular version for a particular purpose); this is freedom 0: the freedom to run the program, for any purpose.6  Otherwise, it would not be LGPL anymore.

Enfin un autre article intéressant de Mark Little sur :

En conclusion, JBoss considère que la version EAP 6.1.0.Alpha  est équivalente en terme de code à la version AS 7.2.0.Final, et pour des raisons pratiques, seule la première version est offerte au téléchargement. J’espère que maintenant c’est (plus) clair !

A propos du support de GIT dans le DSM 4.3 de Synology

A partir de la version 4.3 du Disk Station Manager (DSM) des NAS Synology, un module « GIT Server » a été ajouté.
La question est : comment l’utiliser ?

Utilisation du module :

Extrait issu du package : /var/packages/git/help

Git Server

Git is an open source distributed version control system, which allows you to maintain software source code, documents or any type of file on a computer with speed and efficiency. With Git, you can collaborate with different groups of people simultaneously with relative ease.

To allow users to use Git:

Log into DSM using an account with administrative privileges. Go to Control Panel > Terminal and enable SSH service.
Launch the Git package. Select users to provide them with the ability to check in and check out files from the repository.

Git users will be restricted to Git-related activities with a shell tool called git-shell. This login shell will be applied to Git users to ensure that the accounts are only used for Git operations. As a result, Git users may only use the SSH connection to push and pull Git repositories, and will not have full access to DSM.

To create a Git repository:

1. Log into your Synology server via SSH as root or admin.
2. Change directory to /volumeX, where X is the volume number, to create a folder. For example, « git_repos ». The permission of the folder will be the same as Linux.
3. In the folder, run git init to create an empty repository.
4. After the repository is created, a Git client user can enter the following command to access this repository:
git clone ssh://[Git users]@[Your Synology server’s IP address or hostname]/[Git repository path]

Références (ajout du paquet synology) :

Références (utilisation) :

Bon voilà, je n’ai plus qu’à tester tout çà, dès que j’aurai un peu de temps !

Note :

Pour les versions de DSM antérieures à la 4.3 : Installer un serveur Git sur un NAS Synology

Exclure des dépendances avec Maven en fonction de la version de Java

Il peut parfois être utile d’exclure certaines dépendances dans un projet Maven, pour éviter d’avoir des classes en doublons dans le classpath, et d’être assuré d’utiliser la bonne version de la classe.

Par exemple, si notre projet utilise une dépendance qui doit utiliser elle-même la dépendance transitive jaxb-api 2.0, on peut souhaiter exclure cette dernière dépendance qui est en fait incluse dans Java 6.

Pour ce faire, il existe plusieurs solutions :

  1. Exclure une dépendance dans la gestion des dépendances
  2. Utiliser un scope provided ou system sur la dépendance que l’on souhaite exclure (suivant qu’elle est embarquée par le container, ou incluse dans le JRE)

Enfin, pour s’assurer que l’on traite l’exclusion uniquement dans une version donnée de Java, on utilise le mécanisme des profiles Maven.

Exemple, pour exclure une API qui serait incluse dans Java 6 :

Dans ce cas on utilise un profile – extrait du pom.xml

<project xmlns="" xmlns:xsi=""



					<!-- -->

			<!-- -->



		<!-- LIB PERSO pour TESTS -->


				<!-- JE VEUX EXCLURE JSR 173: STAX -->
				<!-- -->
				<!-- JE VEUX EXCLURE JSR 222: JAXB 2.0 -->


Références utiles :