Mario Jauvin's blog

 Filtering java sources using maven properties As you probably know, the maven resource plugin gives you the ability to create resources directory where the resource files will be filtered so that any maven properties defined in the build can be interpolated or substituted.  This allows you for example to create a properties file like: artifactid=${project.artifactId} when packaging this properties file the property artifactid will be set to the value of the maven project's artifactId. When using annotations, the strings used in the parameters must be know at compile time and if you want to use a maven property such as project.version, you cannot use the previous property file since the string will only be created at runtime.  This is where java filtered source files comes into play. What you need to do is in the parent POM shared by your application, add the following plugin exec...

I have seen a lot of confusion and misunderstanding on what is and why use a java enterprise concept called skinny war . In simple terms , a skinny war is a WAR where some of its dependencies are moved from the WAR module WEB-INF/lib to the EAR lib folder .   This post is specifically written to deal with skinny wars and does not explain or go into details which jars must be in the WAR class loader and which one do not have to . It is assumed that the reader is familiar with this concept and the concept of the WAR class loader versus the application class loader . Suffice it to say that typically, JAR that must be scanned by CDI usually belongs in the WAR class loader . Web fragments and jars with tag libraries are other candidates . Also, all test and provided scope artifacts must be specified in the WAR module as having maven remove them from the WAR does not make sense as they were never to be put there and having them in a deps POM file does not work . They will not ...