AW: Fwd: FOSDEM 19 Debian Java talk
Hello, according to the Apache Release Policy a release is the source and while it allows and defines convinience binaries there is not really a Notion of „official binaries“ from the ASF Point of view. So Maybe the new property should be something like „binary Vendor“ or „packager“ (similiar what many package Managers have?) I think the number of additional support Problems because of distribution specific packages and the number of solved Problems by distributions doing a good Integration Job can not be clearly tallied. And therefore I would stay away from language like „modified“, „official“ to avoid those Groups to feel unwelcome (especially in the ASF spirit of open SOURCE). Gruss Bernd -- http://bernd.eckenfels.net Von: Michael Osipov Gesendet: Mittwoch, 13. Februar 2019 19:36 An: Maven Developers List; Robert Scholte; Dalibor Topic; Markus Koschany Cc: debian-j...@lists.debian.org; Matthias Klose Betreff: Re: Fwd: FOSDEM 19 Debian Java talk Am 2019-02-12 um 20:09 schrieb Robert Scholte: > On Tue, 12 Feb 2019 12:34:56 +0100, Markus Koschany wrote: > >> Hello, >> >> Dalibor Topic (Oracle) and Robert Scholte (Apache Maven) contacted me >> and were so kind to agree to make this discussion public, so that others >> can chime in too. I would like to use the opportunity to answer the >> initial question "what we are interested in seeing better supported from >> build tools" and give some general feedback about integrating Java into >> Debian. >> >> >> First of all Ant and Maven are most likely the best supported build >> systems at the moment. We carry only two patches for Maven, one because >> we use a newer version of SLF4j [1] and the second one is to make Maven >> builds reproducible. [2] It looks like [1] has been already merged >> upstream but [2] has not been forwarded yet. It would be great of >> course, if Maven builds would be reproducible out-of-the-box. In general >> I would like to see reproducible builds everywhere. > > Hi Markus, > > first of all thanks for the insights, it is important for us to know how > Maven is used and in which way we can improve that way-of-work. Hervé is > already working hard on the reproducible builds specs with your team in > order to find out how we can improve our maven-plugins to get > reproducible artifacts. > > Maven itself is not 100% reproducible. We've learned that some Linux > vendors rebuild Maven and the presentation confirmed that Debian is one > of those vendors. What we've seen in the past is that sometimes people > are having issues with Maven and after a while we discovered that they > were not using the official Apache Maven distribution[1]. For us it is > quite easy to say: sorry, not our official distribution, please contact > your Linux distributor. > In such case we have 3 losers: the user, the Apache Maven project and > the Linux Distributor. If only the official Maven distribution was used, > then we would have had 3 winners. > > When you decide to rebuild Maven, you're also taking all related > responsibilities. I'm also wondering how you build Maven, since Maven is > being built with Maven. That should be a challenge to also rebuild all > plugins, etc. > And how do you test this and confirm that it works as the official > distribution? > Sure, *IF* Maven is 100% reproducible then you can rely on our > test-infra, but that's not the situation. > > So here are my main questions: > - Are you making clear that you're not using the official Maven > distribution, e.g. by adjust the info from 'mvn --version'? I expressed my proposal to Hervé that we need a new property: maven.vendor. Our official distribution will carry the value: ASF. Everyone else who modifies the content must change the value in the build.properties. Thus, we will quickly know that this distro has been modified by someone else. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.6.1 release?
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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.6.1 release?
love to see 3.6.1 out soon :) -D 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 > >
Re: Fwd: FOSDEM 19 Debian Java talk
Am 2019-02-12 um 20:09 schrieb Robert Scholte: On Tue, 12 Feb 2019 12:34:56 +0100, Markus Koschany wrote: Hello, Dalibor Topic (Oracle) and Robert Scholte (Apache Maven) contacted me and were so kind to agree to make this discussion public, so that others can chime in too. I would like to use the opportunity to answer the initial question "what we are interested in seeing better supported from build tools" and give some general feedback about integrating Java into Debian. First of all Ant and Maven are most likely the best supported build systems at the moment. We carry only two patches for Maven, one because we use a newer version of SLF4j [1] and the second one is to make Maven builds reproducible. [2] It looks like [1] has been already merged upstream but [2] has not been forwarded yet. It would be great of course, if Maven builds would be reproducible out-of-the-box. In general I would like to see reproducible builds everywhere. Hi Markus, first of all thanks for the insights, it is important for us to know how Maven is used and in which way we can improve that way-of-work. Hervé is already working hard on the reproducible builds specs with your team in order to find out how we can improve our maven-plugins to get reproducible artifacts. Maven itself is not 100% reproducible. We've learned that some Linux vendors rebuild Maven and the presentation confirmed that Debian is one of those vendors. What we've seen in the past is that sometimes people are having issues with Maven and after a while we discovered that they were not using the official Apache Maven distribution[1]. For us it is quite easy to say: sorry, not our official distribution, please contact your Linux distributor. In such case we have 3 losers: the user, the Apache Maven project and the Linux Distributor. If only the official Maven distribution was used, then we would have had 3 winners. When you decide to rebuild Maven, you're also taking all related responsibilities. I'm also wondering how you build Maven, since Maven is being built with Maven. That should be a challenge to also rebuild all plugins, etc. And how do you test this and confirm that it works as the official distribution? Sure, *IF* Maven is 100% reproducible then you can rely on our test-infra, but that's not the situation. So here are my main questions: - Are you making clear that you're not using the official Maven distribution, e.g. by adjust the info from 'mvn --version'? I expressed my proposal to Hervé that we need a new property: maven.vendor. Our official distribution will carry the value: ASF. Everyone else who modifies the content must change the value in the build.properties. Thus, we will quickly know that this distro has been modified by someone else. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Is it so a big problem to keep both versions? This is our internal Nexus server anyway. On Wed, Feb 13, 2019 at 1:27 PM Benedikt Ritter wrote: > Hello, > > Am Di., 12. Feb. 2019 um 08:39 Uhr schrieb Benedikt Ritter < > brit...@apache.org>: > > > Hello, > > > > Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli < > > eolive...@gmail.com>: > > > >> In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already > knew), > >> so they can coexist. > >> > > > > Yes, but the question is, what is latest available snapshot? The > > 3.0.0-SNAPSHOT has been deployed sometime last June. > > > > > >> > >> How are you referring to surefire in your project? > >> > > > > We have some end to end tests that determine the latest snapshots of some > > plugins so we can run tests against them. We do this by analyzing the > > maven-metadata.xml so we don't have to hard code all the versions. > > > > > >> > >> Btw I will check and try to deploy current master > >> > > > > I checked, it didn't help. Maybe the master branch should have > > 3.0.0-SNAPSHOT as version and only be updated to a milestone version for > a > > milestone release. > > > > the problem is still present. I suspect maven can not deal with milestone > snapshot version. My suggestion is to change the version on the master > branch to 3.0.0-SNAPSHOT and create milestone releases without having an > explicit milestone snapshot first. This would fix the metadata in that the > latest version would again be the latest deployment from the master branch. > > Regards, > Benedikt > > > > > > Thank you! > > Benedikt > > > > > >> > >> Enrico > >> > >> Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter > ha > >> scritto: > >> > >> > Hi, > >> > > >> > I just realized that the maven-metadata.xml for Surefire in the > snapshot > >> > repository [1] does not point to the latest Surefire snapshot. It says > >> that > >> > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is actually > >> the > >> > latest available snapshot. Is it possible to correct this? > >> > > >> > Thanks, > >> > Benedikt > >> > > >> > [1] > >> > > >> > > >> > https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml > >> > > >> > > >
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Il giorno mer 13 feb 2019, 13:27 Benedikt Ritter ha scritto: > Hello, > > Am Di., 12. Feb. 2019 um 08:39 Uhr schrieb Benedikt Ritter < > brit...@apache.org>: > > > Hello, > > > > Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli < > > eolive...@gmail.com>: > > > >> In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already > knew), > >> so they can coexist. > >> > > > > Yes, but the question is, what is latest available snapshot? The > > 3.0.0-SNAPSHOT has been deployed sometime last June. > > > > > >> > >> How are you referring to surefire in your project? > >> > > > > We have some end to end tests that determine the latest snapshots of some > > plugins so we can run tests against them. We do this by analyzing the > > maven-metadata.xml so we don't have to hard code all the versions. > > > > > >> > >> Btw I will check and try to deploy current master > >> > > > > I checked, it didn't help. Maybe the master branch should have > > 3.0.0-SNAPSHOT as version and only be updated to a milestone version for > a > > milestone release. > > > > the problem is still present. I suspect maven can not deal with milestone > snapshot version. My suggestion is to change the version on the master > branch to 3.0.0-SNAPSHOT and create milestone releases without having an > explicit milestone snapshot first. This would fix the metadata in that the > latest version would again be the latest deployment from the master branch. > +1 @Tibor what do you think? > Regards, > Benedikt > > > > > > Thank you! > > Benedikt > > > > > >> > >> Enrico > >> > >> Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter > ha > >> scritto: > >> > >> > Hi, > >> > > >> > I just realized that the maven-metadata.xml for Surefire in the > snapshot > >> > repository [1] does not point to the latest Surefire snapshot. It says > >> that > >> > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is actually > >> the > >> > latest available snapshot. Is it possible to correct this? > >> > > >> > Thanks, > >> > Benedikt > >> > > >> > [1] > >> > > >> > > >> > https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml > >> > > >> > > >
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Hello, Am Di., 12. Feb. 2019 um 08:39 Uhr schrieb Benedikt Ritter < brit...@apache.org>: > Hello, > > Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli < > eolive...@gmail.com>: > >> In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already knew), >> so they can coexist. >> > > Yes, but the question is, what is latest available snapshot? The > 3.0.0-SNAPSHOT has been deployed sometime last June. > > >> >> How are you referring to surefire in your project? >> > > We have some end to end tests that determine the latest snapshots of some > plugins so we can run tests against them. We do this by analyzing the > maven-metadata.xml so we don't have to hard code all the versions. > > >> >> Btw I will check and try to deploy current master >> > > I checked, it didn't help. Maybe the master branch should have > 3.0.0-SNAPSHOT as version and only be updated to a milestone version for a > milestone release. > the problem is still present. I suspect maven can not deal with milestone snapshot version. My suggestion is to change the version on the master branch to 3.0.0-SNAPSHOT and create milestone releases without having an explicit milestone snapshot first. This would fix the metadata in that the latest version would again be the latest deployment from the master branch. Regards, Benedikt > > Thank you! > Benedikt > > >> >> Enrico >> >> Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter ha >> scritto: >> >> > Hi, >> > >> > I just realized that the maven-metadata.xml for Surefire in the snapshot >> > repository [1] does not point to the latest Surefire snapshot. It says >> that >> > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is actually >> the >> > latest available snapshot. Is it possible to correct this? >> > >> > Thanks, >> > Benedikt >> > >> > [1] >> > >> > >> https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml >> > >> >
Build DAG traversal.
The depth first DAG traversal of Maven modules in a build is a great and under appreciated thing, but sometimes I wish for a different way of working. Particularly for CI, I'd want to compile everything first, *then* run tests. Two DAG traversals, if you like. This is possible, like so: mvn clean install -DskipTests -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY mvn surefire:test -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY I'm separating out the local maven repo bcause SNAPSHOT items can drop in on the "install" action, but still later fail tests. And I'd not want other builds on the same machine to utilize those jars of dubious quality (even if they are over written a lot). Question: Anyway, is there a critical (but subtle) goal/phase that's going to be skipped with this way of working? - Paul
