Hi Abraham, 

Lots of people have already given you very good advice, it’s just that I cannot help but dive into a discussion about maven. I have dedicated so many lost hours of my life to it, it is the least that it owes me. 

The most important thing to bear in mind when using maven is that you are buying into more than a tool, you are buying into a project management philosophy, and frankly it is a philosophy that is now, pretty dated, which is not to say it is incorrect or invalid but I suspect that if maven were redesigned today, there would be quite some changes in the way that it operates. 

Nearly every large maven project that I have worked on has had a ‘build guy’, sometimes official sometimes not, but basically the one person on the team that knows how the web of maven stuff works, and what the procedures are for doing certain things. It has always struck me as an insanely wasteful use of resources (usually the ‘build guy’ is one of the more experienced developers on the team that could be doing much more interesting things). Your goal here should be A) avoid the need for a ‘build guy’, and much more importantly B) avoid *becoming* the ‘build guy’. 

There are two general approaches to achieving A and B, which are to KISS and avoid fighting against the maven philosophy, maven will win every time. If you try to do things differently, you will get it working initially, and then latter you will discover that some plugin or feature didn’t account for your innovative approach and simply refuses to co-operate. 

In case it is not clear by this point, I regard maven as an (almost) necessary evil. You cannot even completely escape it if you use a different tool, because most of them generate a maven pom when uploading to a repository for purposes of compatibility.  

I have a friend who still swears by ANT. You can do some things with ANT that look a lot like functions, so it is possible to build your own little library that works exactly the way you want it to work. No transitive dependencies, just tests to discover the dependencies that you *actually* need which are then checked into version control along with everything else. More and more I am starting to think that he is right. Binaries in VC present some issues, but it can be argued that these issues are less significant than the alternative approach of versioning dependencies separately in the build file. Running mvn dependency:tree often produces quite scary output. This is the stuff that is ‘hidden’ from you…. until it breaks. 

A brief word also on the maven release plugin. I have been asked (quite reasonably) not to use foul language on the list, so I would ask that each reader adds their own expletives in places they think they belong…

The maven release plugin has the lovely habit of deciding that something has gone wrong at some phase of the process, and then leaves your local system in a total mess. Rolling back is an option here but careful, because it may well have messed with your local VC stuff too. You may need to manually delete a tag at least. It all depends where it has failed. Don’t rely on the release plugins ‘clean’ goal, because it only does a partial job and sometimes fails itself. 

What maven is, is a tool that works very well in simple cases, but gets very complex very quickly, and breaks in horrifically inconvenient ways. The books you will find only describe the first of these characteristics. 

You may not have another options, few of us do, but I have written all of this to support the idea of KISS when it comes to maven stuff. Keep it as simple as possible. Maven has some intriguing and promising features. These things are mermaids, singing beautifully on a distant rock formation… tempting you closer…. closer…. closer….

On 4 Aug 2014, at 08:38, Abraham Marín Pérez <[address removed]> wrote:

Hi everyone,

I know all the cool kids are doing gradle these days, but for a number of reasons we have adopted maven in my team. At the beginning it was all cool, we could trust it to download dependencies instead of having to keep the third party jar files ourselves and all that, but we're getting to the difficult points now. Google has been somewhat helpful, but I'm finding too much information in a non-structured way (maybe I'm looking at the wrong places), so it's not really solving the core issue.

I am guessing some other people out here may have faced a few challenges with maven and I was wondering what resources you have used: books, presentations, anything. The level of "pain" I am getting to is:

• If your project consists of multiple jar files that produce a few war files, do you create a multi-module project or do you treat each project independently, publish the artefact to your corporate artifactory, and then consume the jar files from there?
• When do you change from -SNAPSHOT to normal version and how? Particularly if you produce multiple jar files that are independent "projects" (ie pom files without a common parent).
• And how do you change back from normal version to -SNAPSHOT and when?
• How and when do you run your component tests (ie testing a war file or similar as a black-box entity) and your full integration tests (testing all components together).

Note: I'm not necessarily after answers to these four points (although that would help too). I'm after good resources where I can find the answers myself.

Thanks,

Abraham

--

Blogs: http://www.gatogordo.es/ -- http://www.FromFragileToAgile.com/

Twitter: @AbrahamMarin

LinkedIn: http://lnkd.in/TTHC8W

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Abraham Marín Pérez ([address removed]) from LJC - London Java Community.
To learn more about Abraham Marín Pérez, visit his/her member profile
To report this message or block the sender, please click here
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Wesley Hall ([address removed]) from LJC - London Java Community.
To learn more about Wesley Hall, visit his/her member profile
To report this message or block the sender, please click here
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]