- 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
- General feedbacks
- 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.
BTW: The Artifactory-Hudson plugin provides a lot more features like full bidirectional traceability between Artifactory and Hudson for all the artifacts produced and used during each hudson job execution.
- 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 like described before, to 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 small bug moving memory blocks from young to old gen space.
This issue is a little tricky to explain, I hope I'll be clear
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 your 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
- 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.
I hope you'll solve your build infrastructure issues for the good of JBoss developers and users