Most of the issues encountered by JBoss developers with their new build infrastructure are discussed openly here. This is an important source of information about the problems encountered with a Hudson, Maven and Sonatype-Nexus integration.
- Mod dav or http(s) deployment URL
- Managing the distributionManagement XML tag in pom.xml
- Using password for Maven deployment
- Timeout and performance issues
- Maven metadata XML issue
- Maven deploy failures
- Creating and verifying checksums
- There are 3 main kind of Wagon used with Maven: Lightweight http (the default today), Heavyweight http (the default for older Maven versions), Dav.
- Dav uses transactions when deploying, it has a better management of memory on the client side, and has a bug calculating checksums. Dav is a must when deploying big files. Now, the issue with dav is you can get timeout due to transactions, so the recommendation is correct!
- Lightweight http(s) included in Maven, cache the whole byte array in memory so cannot work for big deployment.
- Dav and Heavyweight protocols suffer from a default configuration that transfer each deployed file twice over the net. This is due to standard HTTP protocol always trying to send a request without authentication, then with it. Check this to find the way to configure preeemptive http authentication in Maven simple http client.
- Maven is caching credentials information based on URL. It means that if you are authenticating the read queries, the same read credentials are used for deploy! See “Configuring Authentication” here.
Basically, looking at the above options nothing is satisfactory with standard Maven.
- Artifactory generates an asymmetric key pair for each user,
- Entering your clear text password in the UI gives you a block of the settings.xml with your personal encrypted password,
- The above encrypted password can be used anywhere (not only maven), and allows only REST API access (maven deploy and so on) not UI access,
- With the encrypted password, https to do maven deploy is not a must anymore => a lot less load on the servers,
- Stealing the encrypted password or the private key (kept in Artifactory DB) has minimal security impact compare to full clear text decryption of all the passwords used on the JBoss Hudson server,
- You can enforce to always use encrypted password for REST and maven deploy.
This issue is related to the dav mode, the JVM memory parameters, OS open file handles tuning, but also to the next issue about maven-metadata.xml files.
From our experience, one issue with latest 1.6 Sun JVM is the miscalculation of young memory size. So, when updating/upgrading your server you should verify that -XX:NewSize and -XX:MaxNewSize are at least set to 2/3 of the total heap size. Artifactory (like Nexus) needs a lot of memory space per request (managing files), and so the young eden space of the JVM is the most important parameter. Just be careful to set a good multiple of mega bytes has the JVM has a bug moving memory blocks from young to old gen space.
This issue is a little tricky to explain, I hope I’ll be clear
- org/richfaces/ui/modal-panel/3.3.4-SNAPSHOT/maven-metadata.xml to update the timestamp and or the latest unique version number of this version,
- org/richfaces/ui/modal-panel/maven-metadata.xml to update the list of available SNAPSHOT versions and the latest one created.
The issue is that the maven client is doing this complicated work, combined with the fact that maven-metadata.xml files are very repeatedly requested by maven to build its version resolution scheme.
Like everyone, most of JBoss projects have upstream and downstream dependencies in Hudson. For example: richfaces-jsf2 depends on richfaces. So, it is common that multiple separate SNAPSHOT hudson job (let say richfaces-3.3.4-SNAPSHOT and richfaces-3.3.5-SNAPSHOT) will get executed in parallel. As you can see from the above maven design, the calculation of maven-metadata.xml files will almost certainly fail.
To solve this issue, our deployment system (in the hudson plugin) knows that Artifactory is a smart repository manager and so sends only the pom, jars and verified checksum to the repository manager. Artifactory is then queuing maven metadata recalculation tasks asynchronously, and so avoiding parallelism conflicts and timeout. Implementing this mechanism was far from evident, but we have today integration tests deploying 5 different snapshot versions concurrently (and repeatedly) without a hitch
7) Creating and verifying checksums
- Playing with dav may have generated a lot of bad checksums that you don’t know of;
- There is no bad checksum verification on deploy, and so the build will be successful but users will get a wrong checksum error;
- Since the correspondance between hudson and maven checksums could not be trusted you‘ll lost traceability between Hudson and Nexus.
For info: Artifactory is capable of failing the deployment if checksums does not match, and has many checksums policy configuration.
I hope Red Hat will solve their build infrastructure issues for the good of JBoss developers and users