Add support for configuring maven

[tmatilai]

Documentation:

• http://maven.apache.org/guides/mini/guide-proxies.html
• http://maven.apache.org/settings.html#Proxies

Challenges

• Configuration is either user specific (~/.m2/settings.xml) or maven installation specific ($M2_HOME/conf/settings.xml).
• Modifying xml in a portable and idempotent way is hard. Maybe download to host, modify in ruby, and upload again.
• Maven is most probably not installed when the proxyconf kicks in. So if we want system wide config, we need to depend on Support hooking around provisioners runs hashicorp/vagrant#2405. Still we don't necessarily know where maven is installed.
• If we support user specific configuration, is the user created yet?
• Who wants to write tests for all this? ;)

Proposal

I think most use cases would be satisfied by just configuring the SSH user (normally "vagrant"). More functionality can be added later if needed.

[johnbellone]

I have a feeling I'm going to run into this sooner than later.

The specific user configuration seems to be a different direction than the rest of the plugin. Perhaps tackle this effort later?

[tmatilai]

But how do we know where M2_HOME and thus the global config is? We might need to find mvn, and resolve possible symlinks to find $M2_HOME/bin/. This requires that mvn is in PATH. I've seen many cases where maven is installed by just extracting from tarball and then M2_PATH is only configured to the software which needs it.

But anyway. How about something like this?

• config.mvn_proxy.m2_home can be explicitly set
• if not, check if M2_HOME is set on the VM
• if not, try to find find mvn and it's installation dir
• if not found, go get a beer
• repeat after each provisioner run, as if maven is only installed after us, it might very well override the settings.xml. Still won't help if the same provisioner run already tries to use it.

[johnbellone]

I'm all for the beer part.

Yeah, that sounds good. I'm guessing for most use cases this would be during a provisioning run so that's either going to be the vagrant user or some equivalent depending on the provider. So putting it in the local user directory doesn't seem like a good route.

I think you brought up an excellent suggestion regarding the configuration and in general being idempotent. Downloading to the provisioning host may be the best option. To your last point if we find a configuration it would merely unmarshal using Nokogiri and add the appropriate child nodes, re-save, and then go get a beer.

[johnbellone]

Depending on how today/tomorrow goes I may try to tackle this. I'll have a separate branch and open PR like I did with #40.

[tmatilai]

In my use cases (dev or build VM) I actually normally use the vagrant user to run maven. For production server and their testing I prefer to avoid maven and just deploy the build artifact. But I agree that the system-wide (well, maven-wide) config is a better option if we think the approach is good enough.

Other thing is that I would desperately try to avoid using native gem extensions, like nokogiri. They have caused a ton of pain in e.g. vagrant-aws and vagrant-berkshelf.

Really great if you have time to dive into this. My hacking time is normally limited to nights after the kids sleep, and more often than not I'm too tired to do anything. ;)

[tmatilai]

@johnbellone Btw, I just added you as a contributor. Welcome aboard! 🍻

[johnbellone]

I'll work on this when I get back from San Francisco later in the week. You were right about it not being straightforward as the rest. Leave it to Sun to make everything so damn difficult! :)