Not a Maven yet….

Notwithstanding my post about using Gradle as a build tool, when i needed to start a new project i decided to use maven due to its amazing integration with an IDE (in my case Intellij), as well as its unbiquitousness.

So, as i have written previously, it is really nice to use Maven as you get started, since with no writing of any config files you have the build process working for you. You have a clean, compile, jar, etc with no work and no opening of an XML file. But that is all theoretical. As i attempted to get going with my project i encountered two really serious issues that took a while to figure out, as well as one issue that needs better resolution.

I will start with the more minor issue. When we use standard libraries that we need to add to our project, then things are pretty straightforward, in fact even better than not using maven. All you need to do is go to http://mvnrepository.com and find the item you want and then it gives you the lines to add to your pom, and voila, you have added your dependency to your project. Of course, in one case, this was not so simple. I wanted to use log4j, so i said, ok, I will just use the latest version. That turned out to be a mistake since all of sudden the compile was failing with libraries i had never heard of unable to be downloaded and installed. As it turns out, after a bit of googling, i learned that i needed to stay away from this latest version. But that is not even the issue i was referring to above. The issue i ran into was when i needed to use non standard libraries that are not in the mvnrepository site. This became difficult as i did not have an easy time figuring out what repository to use and what to add to my POM. In my case, i wanted to use Spring 3 and as far as i can tell, there is no browser for the Spring 3 release repository and thus no instructions for what my artifact ids would look like. (Hint to SpringSource – mention in the javadocs which jar is needed for a package). I wound up guessing based on one item i found somewhere and since i had downloaded the spring 3 distribution i was able to guess how the others would look and solved that issue. The second set of non standard artifacts were the google calendar ones. Here, i had to manually install them in my repository to get it going. Since it was a lot of jars, it was tedious, thought here is a nice link to make it easier, just be sure to use version 2 and not 1 for those things are now in version 2.

Now on the two major issues that i encountered. The first one was that my project would not compile successfully even though there was very little code in it other than use of the Google Calendar API. Finally after not getting anywhere for a while, i realized the issue must be Maven since it did compile in my IDE. As it turned, it was a documented Jira issue, but as the guys in the comments wrote there, who would have thought that default of maven today would not be java 5 at least?

The second one related to testing. Even though my most recent work has been using TestNG, i thought maybe i would give JUnit a try. When my JUnit tests were not being recognized, i figured out that this is because, once again, the default is junit 1.3. After a bit of searching i found what i need to do to add Junit4 to be the test runner. But, since i found the documentation of JUnit 4 lacking, i had decided to switch back but figured i would leave both dependencies in the POM. Well, that turned out to be a mistake too, as i eventually found here

But with these problems behind us, we trudge forward assuming that all should now be smooth sailing, until we need some other complex library….