I have a large Java project with many sub modules, and they have simple top down dependencies like this:
ProjectX
+-ModuleLibA
+-ModuleLibB
+-ModuleCdiLibC
+-ModuleCdiLibC2
+-ModuleLibD
+-ModuleCdiLibE
+-ModuleCdiLibE2
+-ModuleCdiLibE3
+-ModuleLibF
+-ModuleLibG
+-ModuleWebAppX
Each of these modules has their own third party dependency jars. When I say top down, it simply means Module from bottom have all the one above sub module and its third party dependencies as well. The project is large, and with many files, but the structure is straight forward. It does have large amount of third party jars though. At the end, the webapp would have over 100 jars packaged in WEB-INF/lib folder!
When you create this project structure in IntelliJ IDE (no I do not have the luxury of using Maven in this case), all the third party dependencies are nicely exported and managed from one Module to another as I create my Project with existing source and third parties jars. I do not need to re-define any redudant jars libraries definitions between Modules. When it come to define ModuleWebAppX at the end, all I have to do is to add ModuleLibG as a project dependency, and it brings all the other "transitives" dependent jars in! This is all done by IntelliJ IDE, which is very nice!
IntelliJ IDE also let you setup Artifacts from your project to prepare for package and deployment that can run inside your IDE servers. By default, any web application will have an option to create a war:exploded artifact definition, and the IDE will automatically copy and update your project build artifacts into this output folder, and it can be deploy/redeploy into any EE server as exploded mode nicely.
All these work really smoothly, until there is one problem that hit hard! The way IntelliJ IDE package default war:exploded artifact is that it will copy all the .class files generated from each Modules into a single "out/artifact/ProjectX_war_exploded" output folder. This works most of the time when our Java package and classes are unique, but not so with resource files that's not unique! My project uses several dependent CDI based modules. As you might know, each CDI module suppose to define their own, one and single location at META-INF/beans.xml to enable it and to customize CDI behavior. But becuase IntelliJ IDE flatten everything into a single output directory, I've lost the unique beans.xml file per each Module!
This problem is hard to troubleshoot since it doesn't produce any error at first, nor it stops the web app from running. It just not able to load certain CDI beans that you have customized in the beans.xml!!!
To resolve this, I have to make the IntelliJIDE artifact dependent modules to generate it's JAR instead of all copy into a single output. But we still want it to auto copy generated build files into the JAR archive automatically when we make a change. Lukcly IntelliJ has this feature. This is how I do it:
1. Open your project settings then select Artifacts on left.
2. Choose your war:exploded artifacts and look to your right.
3. Under OutputLayout tab, expand WEB-INF/lib, then right clik and "Create Archive" > Enter your moduleX name.jar.
4. Right click this newly created archive moduleX.jar name, then "Add Copy of" > "Module Output" and select one of your dependent module.
5. Repeat for each of the CDI based Modules!
I wish there is a easier way to do across all Modules for this, but at least this manual solution works!
My personal journal on software development and practical programming.
Saturday, May 30, 2015
Saturday, May 23, 2015
How to package skinny war with plain maven-war-plugin
If you are not using maven EAR plugin, then you can also use plain maven-war-plugin to package a Skinny war package like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<!--
We want to package skinny war to avoid third party jars -->
<packagingExcludes>
WEB-INF/lib/*.jar
</packagingExcludes>
<archiveClasses>true</archiveClasses>
</configuration>
</plugin>
However, if you ran into the problem I described in last post, then you want a Skinny war, but still want to include the jar it produced from your own web project. In this case, you can try this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<!--
We want to package skinny war to avoid third party jars, but we do want the classes from
this project to be included -->
<packagingExcludes>
%regex[WEB-INF/lib/(?!my-project-artifact-name-.*\.jar).*\.jar]
</packagingExcludes>
<archiveClasses>true</archiveClasses>
</configuration>
</plugin>
The plugin would accept a REGEX expression for exclusion as well, but getting it to work might take you a few tries! If you need more than this, try this online Java REGEX testing tool: http://www.regexplanet.com/advanced/java/index.html
Thursday, May 21, 2015
Getting version string from a Maven based web application
When you package a maven project, it will automatically generate a pom.properties file inside that will contains the version, artifactId and groupId information. These are handy to have and to display for your web application at runtime. One can use a method like following to retrive it.
public class Application {
private String version;
public String getVersion() {
if (version == null) {
String res = "META-INF/maven/myapp/pom.properties";
URL url = Thread.currentThread().getContextClassLoader().getResource(res);
if (url == null) {
version = "SNAPSHOT." + Utils.timestamp();
} else {
Properties props = Utils.loadProperties(res);
version = props.getProperty("version");
}
}
return version;
}
}
Sounds good? Not too fast! Turns out you have to do little more trick to have this working properly for deployment. By default the maven war plugin will package your classes files into the WEB-INF/classes, but the pom.properties are in META-INF at the same level, and not in WEB-INF/classes/META-INF! This resulted the above code not finding your resource pom.properties from classpath!
To fix this, you need to add the following to your pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<archiveClasses>true</archiveClasses>
</configuration>
</plugin>
This will tell maven to jar up your classes along with the pom.properties in a separate file, then place it in WEB-INF/lib folder instead of using the unpacked WEB-INF/classes version. This forces the pom.properties to be properly added and read by our getVersion() method.
public class Application {
private String version;
public String getVersion() {
if (version == null) {
String res = "META-INF/maven/myapp/pom.properties";
URL url = Thread.currentThread().getContextClassLoader().getResource(res);
if (url == null) {
version = "SNAPSHOT." + Utils.timestamp();
} else {
Properties props = Utils.loadProperties(res);
version = props.getProperty("version");
}
}
return version;
}
}
Sounds good? Not too fast! Turns out you have to do little more trick to have this working properly for deployment. By default the maven war plugin will package your classes files into the WEB-INF/classes, but the pom.properties are in META-INF at the same level, and not in WEB-INF/classes/META-INF! This resulted the above code not finding your resource pom.properties from classpath!
To fix this, you need to add the following to your pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<archiveClasses>true</archiveClasses>
</configuration>
</plugin>
This will tell maven to jar up your classes along with the pom.properties in a separate file, then place it in WEB-INF/lib folder instead of using the unpacked WEB-INF/classes version. This forces the pom.properties to be properly added and read by our getVersion() method.
Thursday, May 14, 2015
NetBeans projects dependencies
With all the coolness of NetBeans, one of the feature I feel it's lacking is managing project denpendencies natively in IDE. Currently the only way to get this feature is if your Java projects are Maven based. If you have Ant based projects, then you would have to manually do this with hacks, and for each projects/sub-projects! Take a look at these two links:
http://stackoverflow.com/questions/13669237/netbeans-java-how-to-add-as-library-another-project-with-dependencies
https://netbeans.org/bugzilla/show_bug.cgi?id=47507
With today's EE projects, you likely going to have many sub projects, and manually handling their dependencies on each project within the IDE is not fun, and hard to maintain. Basically the time you used to setup third party libraries on a ProjectA is wasted and will not automatically exported to ProjectB if it depends on it within the IDE. NetBeans seems to only use project dependencies as way to link related projects together, and to export the main proejct jar/classes, not its third party libraries. A transitive dependencies management feature is needed. Some of user's responses on this topic seem to simply suggest one should go with Maven. Well, as much as I like to use Maven myself, I don't think it acceptable to tell users to convert their existing projects from Ant to Maven just to use an IDE. The IDE tool should be more transparent in this regard.
It's worth to note that both Eclipse and Intellij have this feature and it's productive. I wish NetBeans can improve on this and provide a solution in near future.
http://stackoverflow.com/questions/13669237/netbeans-java-how-to-add-as-library-another-project-with-dependencies
https://netbeans.org/bugzilla/show_bug.cgi?id=47507
With today's EE projects, you likely going to have many sub projects, and manually handling their dependencies on each project within the IDE is not fun, and hard to maintain. Basically the time you used to setup third party libraries on a ProjectA is wasted and will not automatically exported to ProjectB if it depends on it within the IDE. NetBeans seems to only use project dependencies as way to link related projects together, and to export the main proejct jar/classes, not its third party libraries. A transitive dependencies management feature is needed. Some of user's responses on this topic seem to simply suggest one should go with Maven. Well, as much as I like to use Maven myself, I don't think it acceptable to tell users to convert their existing projects from Ant to Maven just to use an IDE. The IDE tool should be more transparent in this regard.
It's worth to note that both Eclipse and Intellij have this feature and it's productive. I wish NetBeans can improve on this and provide a solution in near future.
Subscribe to:
Posts (Atom)