In this little multi-module project, I have the following plugins :

In addition, I have t he following extensions (describe in a .mvn folder) :

I run mvn commands with takari smart builder and 6 threads.

In this bigger multi-module project (10 000 classes, 63 modules, 150 000 unit tests), I have the following plugins :

I have no takari.

For now I haven’t see any blocker to this new version of Apache Maven!

⇒ Just see a little difference in a configuration with ${project.build.resources[0].directory}

The performance are almost the same as 3.5.0/3.5.3.

Good job Apache Maven Team

Like I said in my other blog post this is my current Maven configuration :

Note : I override tomcat-jasper in this configuration in order to use version 8.5.4 (by default it’s 8.5.8).

Our project includes many jsp (> 3000), so the compilation take time. We can increase number of parallel threads. Usually I use 4 threads, but for now I want to improve this. So I test with 16 threads. But surprise, the global time is not better than with 4 threads. Let’s see what happen with jvisualvm :

We can see that there are many synchronization phases for each threads. That is not good for global performance.

I want to avoid these synchronization phases, so I take a look at the source code. The main problem is the code which call java.util.jar.jarFile, and it’s called by sun.misc.URL.classPath.getResource(String) In the compiler the methods which called that most of the time are org.apache.jasper.compiler.JDTCompiler$1.findType(String) and org.apache.jasper.compiler.JDTCompiler$1.isPackage(String) I try to rewrite part of it to totally avoid calling such a code, this is the case of org.apache.jasper.compiler.JDTCompiler$1.isPackage(String). But some part of code can’t be rewriting easily, so I decided to add a synchronized hash map to add cache mechanism. This is the case of org.apache.jasper.compiler.JDTCompiler$1.findType(String). With this 2 fixes I improve synchronized parts, jvisualvm confirms that :

It’s better ! We see that at the beginning there are a lot of syncrhonizations, it’s a normal behavior. It’s time to put results in the cache, and after that the cache will always be used, so there will be no more synchronization phase. But if we inspect the diagram in the last part we see that theres are other synchronizations. They are in the core of the compiler. I can’t easily add a cache map to this part of code. I think it will take’s too much time to fix this …​ So I don’t fix that, it’s still better than at the beginning.

My principal use case is establish a JDBC connection in Jenkins Pipeline. To do this I need the JDBC driver in the system classloader. By default it’s not the case obviously.

In my first implementation, I wrote this groovy code to do the job :

In this solution there is half the code that is technical. It is not very readable and understandable, but it works.

Thanks to @aheritier I found that we can use Groovy Grab in Jenkins to add third pary libraries. At first glance this can be a very good way to achieve this use case. The new code could be this :

This is better than the first one : less code, no more technical code, more readable. But in fact it doesn’t work. At least in my case. Let see why.

In this little multi-module project, I have the following plugins :

In addition, I have the following extensions (describe in a .mvn folder) :

I run mvn commands with takari smart builder and 6 threads.

In this bigger multi-module project (10 000 classes), I have the following plugins :

I have no takari.

For now I haven’t see any blocker to this new version of Apache Maven!

The performance are almost the same as 3.3.9.

New color output console of Maven is nice.

Good job Apache Maven Team

If I must compile for tomcat, I usually take this Maven plugin : https://github.com/leonardehrenfried/jspc-maven-plugin I take this plugin because I think it’s pretty simple, and it give availabilty to add includes/excludes of jsp. This is the Maven config to do the job in my War project (we see that I have a tomcat 8 project) :

If we have many jsp (> 500) the plugin can take lot of time to compile all files. (see the benchmark after) The other problem is this plugin will stop and fail at the first jsp who contains error. And even at the first error in the jsp! If a jsp contains 5 errors, we must run 5 times the plugin to discover all. So if a big project contains multiples errors, we must run may times the plugin and so many times the full compilation of all jsp.

In order to compile a big project faster, I propose different things

To avoid this behavior, I add new parameter : stopAtFirstError (true by default for retro-compatibility). Indeed Jasper JSPC provide a parameter "failOnError" wich allow to continue even if error were raised. This feature works only if we gave all the jsp to jspc. (see first fix). But we need to fail maven build if we have jsp error, but when we call jspc with "failOnError=false", it raise no exception. So the only way I found right now is to add a Log handler who tell the Mojo if jspc raise a SEVERE error in his log (this is a little be tricky…​). If we take multiple threads, this parameter works only if it’s "false". If it’s true, each thread with stop at first error. See pull request https://github.com/leonardehrenfried/jspc-maven-plugin/pull/2 to add this feature.

During this case I search other Maven plugins who compile JSP with Tomcat. It’s not easy because JSP it’s very fashionable…​ I found this major ones :

And this is a little benchmark of this plugins with my project (2700 jsp).

If the wholes PR are accepted, the plugin will be much faster and will permit to not stop at the first error. I think this maybe start a "version 2.X" of this plugin because one PR need java 7. I think this plugin can give Tomcat 8 by default now (especially if it start 2.X version). If you want to use this plugin with this fix and features see this : https://github.com/leonardehrenfried/jspc-maven-plugin/pull/2

When maven-site-plugin is located in project with inheritence, it search the parent projet descriptor in order to manage optionnal inheritence in descriptor file (site.xml). So it search in the repository this kind of file : <parent.artifactId>-<parent.version>-site_<lang>.xml

Since Maven 3.X in project of type pom, the site descriptor is no longer attached to the project. So it will not be installed or deployed by Maven. So by default, you will never find parent descriptor in the repository. However you don’t get always the previous error.

Indeed, maven-site-plugin will try to search the parent descriptor in every repository you defined in maven configuration (settings.xml), and if it don’t find, it will exit without error.

So now, what’s the problem ?

When maven-site-plugin search in every repository, it happen that some repository is not accessible (credentials problem!), and it that case, it will fail with previous error. And the fact is, this error don’t happened on every customers of the same project. That’s because maybe are directly with Maven central for example, others are maybe with Artifactory/Nexus proxy, or something else.

The main problem is : If I don’t want or use inheritence in descriptor why I have got this error, and what are the solutions?

The first thing is that maven-site-plugin by default don’t know if descriptor need inheritence or not. So by default if the project have a parent pom, it will search parent descriptor. Theres is no options in maven-site-plugin for now to desactivate this.

After reading many article of this problem and read the maven-site and descriptor documentation, I found (at least) 3 options to deal with this "feature" :

There is 2 way to do this, regarding how the application is deployed :

This tests are being executed on a simple web application with one REST service based on CXF and Spring.

This is not a real benchmark, it’s just for illustrate each options.

To use this, it’s necessary to write webapp configuration in tomcat server.xml file.

This is an example for an application with some jars, java classes and web parts (jsp and web.xml).

The structure of application in the repository is :

Classic way will packaging a WAR file with this structure :

With tomcat resources, we package nothing, and just write into server.xml file :

The order of each Resources declaration is important for the tomcat classloader.

It’s surprising to mount jar in WEB-INF/classes instead of WEB-INF/lib, but this is the only way I found to make it work correctly with JarResourceSet. The next configuration is dangerous, because it’s not link the right jar, and cause wrong loading in application, I suggest to not using this :

Webby use cargo with Virtual Web App concept to run application in eclipse.

This is pretty faster than other way (like WTP), because it pick-up jars in Maven local repository, and will not paste each jar in temporay folder. Each jar is declared in tomcat server.xml configuration file.