This will replace one tool dependency (mvn) to another (mvnw) and also addition of library (.jar file) in codebase is not recommended.

IMO It's not just replacing one tool with another, it:

• requires less dependency to packages installed on ones machine, given that there's no universal way to install Maven even in one specific OS/distro and one specific version of maven itself.
• gives consistency, kind of the same way we have .java-version and .python-version. So everyone has and uses the exact same version of maven, everywhere, everytime.
• and gives us control of that version. If -for whatever reason- Maven needs to be upgraded we will only need to change one jar file and one properties in the codebase itself.

Can't we download that binary (jar file) in the script execution?
I agree with @rhtyd, it is not common to version binary files.

@rafaelweingartner that defeats the whole point of using mvnw. And I totally agree we should never check in jar files but this is the only generally accepted exception. Modern maven or gradle based projects usually have this, to name a few:

• Spring boot
• Netflix Eureka
• Hibernate

@khos2ow that is very interesting. They are indeed versioning this jar file.

I always had Spring projects as an example of quality; I find versioning binary files a bit unusual though. However, if we zoom out the issue we see that we already version binary files when versioning pictures (jpg, png, and others) for instance. There are even ".class" files in our repo (https://github.com/apache/cloudstack/blob/master/tools/appliance/convert/Convert.class).

I would be ok with this change.

@khos2ow can you rebase this PR to latest master commit, and then we can check Jenkins and Travis status again. Let's make sure both are green to proceed with reviews

@rafaelweingartner I already rebased today after I saw your comment, but the thing is this PR is really in WIP and I haven't completed it yet. I'll try to do it Soon™!

Ok, thanks!

@rafaelweingartner actually I noticed that going forward with this PR depends on #2433, because they both touch building and packaging scripts (mostly).

no problem, so we focus there first.

@khos2ow are you planning to pick this up again?

@rafaelweingartner yes, I still think this would make sense to go forward with, but since I created a couple of docker cloudstack-builder containers, both for RPM and DEB, and since there are more tooling required to have an actual build (besides maven itself) we might be able to let this one go.

Can I close this then?

Sure, closed it.