About automation, I'm definitely a geek. And I totally agree with the famous graph:
And I was working to a Java project with an unusual deployment. Part of the problem is that the actual application for which I was writing the plugin wasn't available as a maven repository. Moreover, running the whole thing needed some fiddling with long command line options, plus a non-trivial class-path.
I started appreciating maven with leiningen, and then by itself. Moreover, it solves one of the worse problems I have with IDEs. I hate to version IDE files (after all, people may use a different environment, something many eclipse users do not even consider). And I hate to recreate them every time (especially when they are not trivial). Eventually, I hate to depend from a GUI program to actually build a project (where a command line should suffice).
Then there is another problem related to libraries, i.e., I find it annoying all the solution regarding jars:
- place the jars in a system wide directory akin to /usr/local/lib
- download the jars every time and manually add them to the project
- create a script that downloads the jars (and curse the first time you develop on windows)
- do not use external dependencies
Maven solves all these problems together. I just name the jars in the pom and everything is taken care of. I loved the thing so much with Clojure and Leiningen that even with the despicable xml syntax things work smoothly.
But I had this very important jar that ain't versioned nowhere. So maven was out of question, I thought: moreover. The idea of manually downloading the jar and then adding it to maven's repository (and doing it on the 2-3-4 computer I use) really looked unacceptable.
So I dig into ant most advanced stuff and built an ant script that actually downloaded the jar for me and put it in a lib directory inside the project (packaging jars with the project is not acceptable). But I still wanted to use maven… so I learned the terribly documented ant plugin to get the dependencies from maven… and since that was not installed by default, I also wrote the code to go and get the jar.
So I basically had this ant script that did everything for me… and was some hundred lines long. Eventually, I also wrote some targets to generate scripts to execute the project (I told about complex command lines).
Of course, this also meant that maven was under-used. But then I realized… I have maven. I have a plugin that creates the scripts for me (not part of maven, but maven can easily get it). I only need ant to get the ant-maven bridge (which I wouldn't need anymore) and to get the missing jar. So I'm maintaining a very complex system for basically nothing: it is so much simpler to wget the jar, install it in the local maven repository and go on.
Fun that in order not to write to lines a couple of times I wrote a one hundred lines script.
2 comments:
Of course to "just wget" the file and add to your local Maven repo has drawbacks. What if the file at the remote URL changes (e.g. for a software update) and breaks something in your code? You would miss Maven build stability.
The "proper" approach, which is the one I usually take, is to have a local (intranet) Maven repository manager (like Sonatype Nexus) setup as caching proxy, plus having a "thirdparties" hosted repo configured in it, where I can just manually drop a versioned copy of the unmavened jar.
For a quicker solution, you could use a svn external / hg subrepo / git submodule to just hold such rogue jars. It won't be the cleanest solution and won't prevent the "mvn install" step, but at least you won't get mad at insane conflicts that may arise in time.
In this specific case, it is hardly likely that the file changes. It is more likely than a new version comes out (and has thus different path).
Right at the moment maintaining a maven repository could be an overkill. Plus it is rather complex to have new services installed without an excessive amount of paperwork here, I'm afraid.
Thanks for the advise.
Post a Comment