I find this solution slightly obtrusive. After the project is checked out, Elwood alters the original pom and adds a small dependency snippet to pull down the custom run listener (elwood-maven-runlistener) during the build. This is evidently found in the pom.xml sitting under the META-INF directory marked with provided scope to prevent this from becoming an official dependency of the artefact.
I could potentially use a custom Maven that has the run listener JAR as one of it's libraries. But then, this has to be another day.
I could potentially use a custom Maven that has the run listener JAR as one of it's libraries. But then, this has to be another day.
I had to abandon the original idea of making the run listener POST the build statistics using a 3rd party REST library because I may inadvertently introduce a class loader issue when the official project dependency has this library defined. Same argument goes with Redis. I also wouldn't want roll up my sleeves and start writing network calls on my own as time is a scarce resource.
My other concern with using network calls is that the back-end REST service could be busily serving requests from the browser, which I suspect may slow down the build process. Note that the front-end code retrieves the build status every few seconds.
I don't want to stress the back-end service too much.
My other concern with using network calls is that the back-end REST service could be busily serving requests from the browser, which I suspect may slow down the build process. Note that the front-end code retrieves the build status every few seconds.
I don't want to stress the back-end service too much.
I've also tested the idea of keeping the statistics in memory as a JMX bean. However, as each test classes are started up and torn down, the numbers are lost. In the end, I had to come back to my old friend – the filesystem1.
Note: All changes2 related to capturing the Maven build statistics are found in “maven-integration” branch.
No comments:
Post a Comment