Re: Git migration: new branch/tag naming scheme
As Anders pointed out privately, I unintentionally sent this message to the wrong dev@ mailing list. Pardon for that. Michael Am 2019-02-16 um 15:59 schrieb Michael Osipov: Folks, given that we are currently in the process of migrating to Git I'd like to propose a more readible and with the branch names consistent tag naming scheme. The given approach, for whatsoever reason, performs an uppercase and replaces dots with underscores. This reduces readability, but also requires people (esp. package maintainers) to perform sed(1) magic to convert back and forth. There are bascially two approaches I'd like to discuss: Approch 1: It will reuse the branch name of the current major version, excluding master. Thus, we will have the following prefixes: tomcat90-, tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is released separately the prefix would be jdbc-pool-. The version itself would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc. Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit would be autocompletion in Git CLI. I could simply say: "git checkout tomcat85" or "git checkout tomcat85-" and grab the specific version I want. Approach 2: A simpler, less redundant approach would be naming the branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25, etc. The Git autocompletion will work here too. I personally opt for approach 2 because it is consistent, concise and removes redundancy on always used prefixes. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Git migration: new branch/tag naming scheme
Folks, given that we are currently in the process of migrating to Git I'd like to propose a more readible and with the branch names consistent tag naming scheme. The given approach, for whatsoever reason, performs an uppercase and replaces dots with underscores. This reduces readability, but also requires people (esp. package maintainers) to perform sed(1) magic to convert back and forth. There are bascially two approaches I'd like to discuss: Approch 1: It will reuse the branch name of the current major version, excluding master. Thus, we will have the following prefixes: tomcat90-, tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is released separately the prefix would be jdbc-pool-. The version itself would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc. Finally it would be tomcat85-8.5.40, tomcat90-9.0.25. Another benefit would be autocompletion in Git CLI. I could simply say: "git checkout tomcat85" or "git checkout tomcat85-" and grab the specific version I want. Approach 2: A simpler, less redundant approach would be naming the branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25, etc. The Git autocompletion will work here too. I personally opt for approach 2 because it is consistent, concise and removes redundancy on always used prefixes. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Fwd: FOSDEM 19 Debian Java talk
Le 15/02/2019 à 17:34, Hervé BOUTEMY a écrit : > IIUC you don't use the same versions of dependencies (because of uniqueness > of each lib in Debian [1]) as those used in a "normal unconstrained" build > from source [2] > I don't yet understand the details of Debian build system, if the symlinks > are used at build time or only at runtime, but even if you the resulting jars > of the Debian build from Maven source are the same binaries, the execution of > Maven does not run with the same dependencies, then there may be subtle > differences during the run (for example from jansi, or guice, or commons-cli > or ...) I try to stick as much as possible to the same versions of the dependencies, especially the sensitive ones like Guice or Aether, but there are still some divergences. I've reviewed the dependencies installed in the /usr/share/maven/lib directory by the maven/3.6.0 package in Debian unstable and we currently have the following differences: MavenDebian commons-lang3 3.8.13.8 commons-io 2.5 2.6 guava 25.1 19.0 jansi 1.17 1.17.1 jansi-native1.17 1.18 maven-shared-utils 3.2.13.3.0 plexus-utils3.1.03.1.1 wagon 3.2.03.3.1 The versions are slightly ahead to the ones in Maven 3.6.0, except for Guava. Guava is only used by Guice for Preconditions, immutable collections and other basic operations. I don't think the difference is significant. At least, I've verified that the Guice 4.2.1 tests pass with Guava 19.0. > IIUC, that uniqueness of every library is a Debian principle, then a Maven > distribution from Debian cannot be equivalent to a "normal" distribution > where library versions are purely selected by Maven source's pom.xml, without > adding any constraint > This is why having Debian's distribution display its name in "mvn -v" would > make that more clear. > > Let's discuss a little bit about plugins: when Debian launches the "mvn" > command to build some Debian package, does it use Maven Central like anybody? > = where do the Maven plugins used during build come from? There are two different cases: 1. What Maven does when launched by a user 2. What Maven does when it's used in a Debian package build 1. When the user launches "mvn" to build a project it behaves as usual by downloading the dependencies from Maven Central or the other repositories defined in the pom. The Maven plugins also available as Debian packages are never used. The only code compiled by Debian that is executed is the set of dependencies found in the Maven lib directory (/usr/share/maven/lib). The default plugin versions are also exactly identical. Before Maven 3.5.0 we patched default-bindings.xml to align them with the versions packaged in Debian. We stopped to preserve the same default behavior. This is new in Debian 10 "Buster" (and the latest Ubuntu 18.04 LTS), the current stable version Debian 9 "Stretch" has Maven 3.3.9 with different default plugins. 2. Debian builds are offline, completely disconnected from the network. It's impossible to download dependencies or plugins from Maven Central. That's why we recreate a Maven repository in /usr/share/maven-repo/ and instruct Maven to fetch the dependencies there instead of Maven Central when building a Debian package. This repository is populated by installing the packaged plugins and dependencies. If there are Maven developers interested I can do a live demo showing how Maven projects are built into Debian packages. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.6.1 release?
Hi Sylwester, On 15.02.19 22:26, Sylwester Lachiewicz wrote: Hi, the changes for MNG-6543 rebased on master and now ITs tests pass without issues. That's great...get it into master... Kind regards Karl Heinz Marbaise BR Sylwester czw., 14 lut 2019 o 23:29 Karl Heinz Marbaise napisał(a): Hi to all, currently there are 3 issue open in JIRA for 3.6.1: * MNG-6506 Mojos are unable to load package annotations on Java >= 9 * MNG-6538 Upgrade Maven Artifact Resolver to 1.3.2 to restore API * MNG-6543 Upgrade plexus classworld to support java 9+ On branch MNG-6543 currently the IT is failing (testit(org.apache.maven.it.MavenITmng6558ToolchainsBuildingEventTest) So I would take MNG-6538 (making a release of Resolver 1.3.2. first)... Do we have other things which should be part of the release ? I would like to start the final phase on 21. February if no one has objections... Kind regards Karl Heinz Marbaise On 14.02.19 09:08, Olivier Lamy wrote: Good idea to cut a release (been affected by https://issues.apache.org/jira/browse/MNG-6590) I don't mind if someone move the remaining open to next 3.6.x :) On Thu, 14 Feb 2019 at 04:48, Michael Osipov wrote: Am 2019-02-13 um 19:28 schrieb Dan Tran: love to see 3.6.1 out soon :) There are three open issues, someone needs to process them... On Mon, Feb 4, 2019 at 9:50 AM Karl Heinz Marbaise wrote: Hi Michael, On 04.02.19 17:36, Michael Osipov wrote: I need to push Wagon first. It contains a regression for connection TTL. Yes of course.I know.. Kind regards Karl Heinz Marbaise Gesendet: Montag, 04. Februar 2019 um 17:25 Uhr Von: "Karl Heinz Marbaise" An: "Maven Developers List" , "Mickael Istria" < mist...@redhat.com> Betreff: Re: 3.6.1 release? Hi, I will try to do the release planning today in the evening... Kind regards Karl Heinz Marbaise On 04.02.19 15:17, Mickael Istria wrote: Hi all, Maven 3.6.1 has some noticeable fixes and improvements that we're eager to leverage in Eclipse m2e. We're also ready for adoption: https://git.eclipse.org/r/#/c/133590/ . Do you have an estimate of when 3.6.1 should be release? What are the issues currently considered as blocker for the release? Thanks in advance. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
