You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by GitBox <gi...@apache.org> on 2020/08/17 22:53:51 UTC

[GitHub] [httpcomponents-core] nhojpatrick commented on pull request #218: Takari maven wrapper

nhojpatrick commented on pull request #218:
URL: https://github.com/apache/httpcomponents-core/pull/218#issuecomment-675154265


   @ok2c i'm going to be closing my attempt in my view of improving commons builds and setting up Maven-As-Code, based upon an email thread on the commons dev ML.
   
   httpcomponents-core might use enforcer to enforce a specific version of maven is used, or a specific range of versions, or newer than or older than. But if your working on multiple projects, from different sources, older brownfield projects, newer greenfield projects, how many maven versions should a developer need to install. Each time I switch between a project, i'll do `mvn clean install` (or `mvn clean verify` if your one of those people, but verify never works for me as -rf never works with verify). So it then reports a enforce, i forgot to change my maven version, okay, reset path and try again. It works. Move to another project, oh that java 11 or 14, will this version of maven work, okay fine it works. Get a bug report of some legacy code, need to now build a Java 1.6 project, set Java home, re-execute, wait maven fails need to use an older version. Using ./mvnw I don't have to go about setting up which maven version to use, the project controls what version of maven to us
 e and when to upgrade. Develop might need maven 3.6.3, and master might need 3.6.0, so switching branches I need to change my path again, using ./mvnw I don't have to worry. My path might end up /opt/mvn-v3.6.1/bin:/opt/mvn-v3.6.0/bin:/opt/mvn-v3.6.3/bin:/opt/mvn-v3.6.1/bin:/opt/java-1.8/bin:/opt/bin/bin, with the easy option of me adding the maven bin path to the front of PATH each time i change.
   
   CI and CI/CD get easier, maintainers don't need to preinstall maven on the Jenkins node, or the OpenShift Jenkins Image, your Jenkinsfile or Circle CI configuration just needs ./mvnw and CI & CI/CD will download maven as or when needed. Want to test out a a new version of Maven on your CI or CI/CD, simply change the config and push that branch, no faffing about with CI machines, installing a newer maven and getting your test branch to use that setup.
   
   New developer joins your team, or your given a new work vm or laptop or workstation, saves setup or having to teach someone, less support overhead or new joiners. Say you have a new windows work vm, install Java, install Git Bash, clone repo, execute ./mvnw and it's building.
   
   Hopefully a java versions will be available in a few years. I know toolchain is available, but we have no option to automatically do that cross OS and cross version.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org