maven « Piotr Nowicki's Homepage

JGroups is Bela Ban‘s piece of software for reliable message exchange that is highly configurable and can use either TCP or UDP as a transport protocol. Basically – you run the JGroups on number of clients, they form a cluster and they can send and receive messages within the cluster.

JGroups is used internally by JBoss Infinispan. Infinispan, however, unlike JGroups adds the distributed cache semantics (replicated / distributed modes, entries invalidation, transactional behavior, Map access API, etc.) It even allows you to use the cluster as a compute grid.

Infinispan in turn is used to provide JBoss AS 7 clustering functionalities. Therefore, it means that the underlying JGroups subsystem can and is configured using a standard JBoss AS 7 standalone*.xml file. You can access Infinispan cache from your Java EE component (e.g. EJB) without any problems as described here.

However, there are cases when you’d like to use just the underlying JGroups messaging instead of all the cache semantics Infinispan gives you. And here’s the place things are becoming more complicated. You can always use JGroups directly and store the configuration for it as an application-local resources. It might become arguable if this is or isn’t a violation of the Java EE spec which says that an application should not manage low-level connections, spawn threads, open sockets, etc. This is something that is better to be left to the application server – it also allows us to use one configuration file instead of spreading it across multiple places.

So, the question is – how to access the JGroups subsystem from our EJB application? The whole solution involves few steps which will be described below.

Continue reading →

Maven has some really great features. One of them is filtered resources.

Basically, if you use Maven for some time, I’m sure you know what by default everything you put in src/main/resources will be added to the classpath in the resulting artifact (e.g. in the WEB-INF/classes for a *.war archive.) Putting resources in this location is a common way of adding Java properties file to your project.

Now what is interesting: you can use Maven variables in those resource files and they can be swapped into final value during the process-resource phase. You just need to tell Maven that it is not a “regular” resource and that it should be filtered.

Continue reading →

You can easily create a fully functional, basic Maven repository on your web hosting provider’s account. It will give others the possibility to access your released artifacts using clean URLs (like yoursite.com/maven or maven.yoursite.com) or use it as a repository straight from the Maven.

To achieve it, you’ll need to:

create Maven FTP user,
create a subdomain (optional),
add Maven server configuration,
add distribution management to your pom.xml,
add Maven FTP wagon provider,
use your repository in client projects.

Continue reading →

The aim of this post is to show you how, using CDI, you can inject Java properties entries (those in *.properties files) directly into your Java class. This is somewhat similar to the Spring’s @Value annotation I needed in my plain Java EE project.

The whole code can be found on GitHub so feel free to clone it, use it or make any changes you like.

Continue reading →

I’m currently under the process of moving all my workplace repositories from SVN to Git (configured to work with Gerrit). As a side not, I already found it to be a great tool for code review, line-precise commenting of the artifacts and for reviewing new employees code before pushing the changes to the repository.

But, back to my point. Recently I’ve stumbled upon a problem with commiting an empty directory in Git. If the directory consists of some files and you stage those files, the directory will be commited automatically. However, if the directory is empty, you cannot commit it.

It’s very reasonable way of thinking, but it also creates a few problems e.g. with Eclipse which requires you to use some Maven defined directories (src/test, src/java, etc.). More precisely, if you don’t have e.g. src/test/resources directory, it will throw an ugly project-wide error at your face.

The solution, can be found on StackOverflow, so basically all you need to do is provide a .gitignore file which forbids content other than the .gitignore file itself. However, in my case I ended up with putting a README file which describes why it’s there and that it should be removed as first real resource will be uploaded.
I found it more informative for other team members than an empty .gitignore file.

By default, Maven’s test plugin Surefire doesn’t scan files for @Test annotations, but rather takes only the files which class names ends with “Test” or “TestCase”.

I use both: unit tests and integration tests. I execute the latter using Arquillian framework, so it looks just like pure JUnit test. However, I prefer to name them with the “IT” suffix which means that they’re no longer recognized by Surefire plugin as test files.
If you want Maven to execute such tests, you need to give him a hint (using appropriate configuration element) to scan also for the *IT classes:

<configuration>
    <includes>
        <include>%regex[.*[Test|IT].class]</include>
    </includes>
</configuration>

Just remember that the regex works only on *.class files. It also overrides the default rules (which means that you need to add the *Test and/or the *TestCase suffix to scan for default test classes.)

Tonight I’ve fought with making Maven and Hibernate to cooperate… After 1,5h struggle, I’ve decided to write down what I’ve “discovered”.

When adding dependencies to your persist module you should avoid adding the ‘hibernate’ package dependency itself as there should be only ‘hibernate-annotations’ one.
When adding log4j dependency remember that version 1.2.15 is messed up and forces you to download jars from SUN webpages if you want to get rid of those nasty dependency errors that maven throw in your face… Instead of 1.2.15 choose 1.2.14 as it’s dependencies are not optional and Maven will successfully download all of them.
When adding slf4j (Simple Logging Factory For Java) remember that when you add “slf4j-log4j12″ package it comes with depended package slf4j-api BUT the versions might (and are!) non-compatible… In my case slf4j-log4j12 v. 1.5.6 came with slf4j-api v. 1.4.2. You should exclude slf4j-api dependency from slf4j-log4j12 and add it separately in the same version as slf4j-log4j12 (in this case 1.5.6).