Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Am Do., 14. Feb. 2019 um 14:22 Uhr schrieb Tibor Digana < tibordig...@apache.org>: > Benedikt, it does not mean that something with public IP is for public use. > We made only a compromise for some users to verify some functionality. > Please read the information about Apache repositories: https://www.apache.org/dev/repository-faq.html > > On Thu, Feb 14, 2019 at 11:42 AM Benedikt Ritter > wrote: > > > Am Mi., 13. Feb. 2019 um 17:48 Uhr schrieb Tibor Digana < > > tibordig...@apache.org>: > > > > > Is it so a big problem to keep both versions? This is our internal > Nexus > > > server anyway. > > > > > > > From my PoV the metadata is incorrect. Latest should point to the latest > > available build. At the moment it does not. The Snapshot repository is > not > > an internal Nexus server. It is a public artifact repository for trying > out > > new things. I think the Maven project should get its own metadata > right... > > Why are you resisting? Do you see problems when updating master to > > 3.0.0-SNAPSHOT? > > > > Benedikt > > > > > > > > > > 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 < > > brit...@apache.org> > > > > 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: 3.6.1 release?
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 - 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: Fwd: FOSDEM 19 Debian Java talk
Hi Robert, Some comments with my Maven package maintainer hat. Le 12/02/2019 à 20:09, Robert Scholte a écrit : > 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. The maven package is rebuilt with the version of Maven previously packaged, that's not really a problem now. In the past we used a convoluted Ant build mimicking the Maven phases but that's history now. The source code is fetched from the release tags on the Git repositories (the tags are polled everyday and we're warned when a new release is available). One project (library, plugin, etc) is mapped to one package, and the upgrade process is done manually. It isn't terribly difficult but that's quite time consuming. If there are Debian/Ubuntu users in the Maven community interested in helping they are very welcome. > 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. Debian has a CI infra rebuilding 550+ packages using Maven as build tool, so regressions tend to be caught fairly quickly (and immediately [1] reported [2][3]). Also the version provided in the stable release is available after months of user testing. So I'm pretty confident the Debian package is true to the Apache binaries. > 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'? No we aren't, but that's worth considering. Note that as the Maven reproducibility improves this will become unnecessary because at some point we'll be able to build binaries strictly identical to the Apache ones. > - What is the optimum way of distributing Maven sources? For example: > also providing compile and package scripts (instead of calling > maven-plugins)? The current system is mostly fine to us. The only issue I got recently was the embedding of the SLF4J sources at build time, because we don't build binary packages installing the sources artifacts of the libraries and they aren't available at build time (we could though, that's a little more work). In this case I patched the build [4] to embed the compiled classes with the shade plugin instead (the patch was refused though [5], but that's a fairly minor divergence). > Interesting :) We've been discussing how we could get more contributors > and Kotlin was one idea, but that one didn't make it. > Even though we as Maven developers don't like the wrapper, the community > is asking for it, so we're seriously considering to add it as part of > Maven Core. The wrapper would have no significant impact on the Debian packaging, we just remove it before assembling the source package (no binaries are allowed). Emmanuel Bourg [1] https://issues.apache.org/jira/browse/MJAVADOC-504 [2] https://issues.apache.org/jira/browse/MPLUGIN-339 [3] https://issues.apache.org/jira/browse/SUREFIRE-1422 [4] https://salsa.debian.org/java-team/maven/blob/master/debian/patches/slf4j-compatibility.patch [5] https://github.com/apache/maven/pull/118 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: Fwd: FOSDEM 19 Debian Java talk
I have proposed a similar approach with maven.vendor in the build.properties. > Gesendet: Donnerstag, 14. Februar 2019 um 14:24 Uhr > Von: "Gary Gregory" > An: "Maven Developers List" > Cc: "Robert Scholte" , "Dalibor Topic" > , debian-j...@lists.debian.org, "Matthias Klose" > > Betreff: Re: Fwd: FOSDEM 19 Debian Java talk > > Jar manifest files carry data like "built-by" and implementation > information: > > https://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html > > Why not reuse "Implementation-Vendor" or invent a new entry and put > "Debian" in there. Maven can display this additional information on "mvn > -version". > > Gary > > On Thu, Feb 14, 2019 at 4:56 AM Markus Koschany wrote: > > > Hi Robert, > > > > Am 12.02.19 um 20:09 schrieb Robert Scholte: > > [...] > > > 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. > > > > We hear this a lot and it seems to be more common in the Java community. > > From Debian's point of view (other distributions like Fedora share the > > same view) it is essential being able to rebuild software from source. > > The prerequisite is the availability of source code of course. Most of > > us find it even strange when upstream developers recommend to use their > > prebuilt versions. Do they have something to hide? Why can't they just > > make building from source easy and trivial? > > > > We believe that every user should have the ability to modify software > > but this is only possible if she can build it from source. We go to > > great lengths to ensure that all software complies with Debian's free > > software guidelines. For the enduser the language and build tools of a > > certain piece of software almost become meaningless. They just type "apt > > source maven", change into the maven directory and rebuild the software > > with another one-liner. > > > > In case of Maven I don't see where our release differs fundamentally > > from your binary releases. As I said there is only one reproducibility > > patch left that doesn't change the functionality at all. So what we do > > is grab your sources from https://github.com/apache/maven/releases or > > maven.apache.org. In our opinion, without making any significant > > changes, it should just behave as your binary release when we build it > > from source. Otherwise there is source code missing or different. > > > > > 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. > > > > It is a challenge to build Maven from source. We solved the > > bootstrapping problem and now we can use Debian's Maven version to build > > newer versions but we have to follow a certain build order when we make > > an update. > > > > > 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'? > > > > This is how it looks on Debian 9 "Stretch" at the moment. > > > > Apache Maven 3.3.9 > > Maven home: /usr/share/maven > > Java version: 1.8.0_181, vendor: Oracle Corporation > > Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre > > Default locale: de_DE, platform encoding: UTF-8 > > OS name: "linux", version: "4.9.0-8-amd64", arch: "amd64", family: "unix" > > > > It is obvious from Maven home I guess but there is no special emphasis > > on Debian because when you install Maven from Debian you will never get > > a prebuilt binary release, this is implicit for all software in Debian's > > main distribution. > > > > > - What is the optimum way of distributing Maven sources? For example: > > > also providing compile and package scripts (instead
Re: Build DAG traversal.
Yeah, maybe that makes sense. On Thu, Feb 14, 2019 at 1:45 PM Mykola Nikishov wrote: > Paul Hammant writes: > > > mvn clean install -DskipTests > -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY > > This would compile and test-compile for the first time... > > > mvn surefire:test -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY > > Run compile and test-compile one more time, on the same sources, for > artifacts that had been just installed. Does it make sense to skip them > with '-Dmaven.main.skip=true -Dmaven.test.skip=true' [1]? > > [1] > https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#skipMain > > -- > Mykola > > Libre/Free Java Software Engineer > https://manandbytes.gitlab.io/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Build DAG traversal.
Paul Hammant writes: > mvn clean install -DskipTests > -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY This would compile and test-compile for the first time... > mvn surefire:test -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY Run compile and test-compile one more time, on the same sources, for artifacts that had been just installed. Does it make sense to skip them with '-Dmaven.main.skip=true -Dmaven.test.skip=true' [1]? [1] https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#skipMain -- Mykola Libre/Free Java Software Engineer https://manandbytes.gitlab.io/ - 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
Jar manifest files carry data like "built-by" and implementation information: https://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html Why not reuse "Implementation-Vendor" or invent a new entry and put "Debian" in there. Maven can display this additional information on "mvn -version". Gary On Thu, Feb 14, 2019 at 4:56 AM Markus Koschany wrote: > Hi Robert, > > Am 12.02.19 um 20:09 schrieb Robert Scholte: > [...] > > 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. > > We hear this a lot and it seems to be more common in the Java community. > From Debian's point of view (other distributions like Fedora share the > same view) it is essential being able to rebuild software from source. > The prerequisite is the availability of source code of course. Most of > us find it even strange when upstream developers recommend to use their > prebuilt versions. Do they have something to hide? Why can't they just > make building from source easy and trivial? > > We believe that every user should have the ability to modify software > but this is only possible if she can build it from source. We go to > great lengths to ensure that all software complies with Debian's free > software guidelines. For the enduser the language and build tools of a > certain piece of software almost become meaningless. They just type "apt > source maven", change into the maven directory and rebuild the software > with another one-liner. > > In case of Maven I don't see where our release differs fundamentally > from your binary releases. As I said there is only one reproducibility > patch left that doesn't change the functionality at all. So what we do > is grab your sources from https://github.com/apache/maven/releases or > maven.apache.org. In our opinion, without making any significant > changes, it should just behave as your binary release when we build it > from source. Otherwise there is source code missing or different. > > > 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. > > It is a challenge to build Maven from source. We solved the > bootstrapping problem and now we can use Debian's Maven version to build > newer versions but we have to follow a certain build order when we make > an update. > > > 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'? > > This is how it looks on Debian 9 "Stretch" at the moment. > > Apache Maven 3.3.9 > Maven home: /usr/share/maven > Java version: 1.8.0_181, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "4.9.0-8-amd64", arch: "amd64", family: "unix" > > It is obvious from Maven home I guess but there is no special emphasis > on Debian because when you install Maven from Debian you will never get > a prebuilt binary release, this is implicit for all software in Debian's > main distribution. > > > - What is the optimum way of distributing Maven sources? For example: > > also providing compile and package scripts (instead of calling > > maven-plugins)? > > The major headache for us is the initial bootstrapping of new compilers > or build tools. We often write our own Ant scripts to solve the chicken > and egg problem. For Maven this is currently solved but if I recall > correctly there are sometimes plugins that require a certain Maven > version which in turn requires a specific plugin version, a classic > dependency loop. So if there was a way to build Maven without Maven or > certain plugins that would obviously make our life easier. >
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Benedikt, it does not mean that something with public IP is for public use. We made only a compromise for some users to verify some functionality. On Thu, Feb 14, 2019 at 11:42 AM Benedikt Ritter wrote: > Am Mi., 13. Feb. 2019 um 17:48 Uhr schrieb Tibor Digana < > tibordig...@apache.org>: > > > Is it so a big problem to keep both versions? This is our internal Nexus > > server anyway. > > > > From my PoV the metadata is incorrect. Latest should point to the latest > available build. At the moment it does not. The Snapshot repository is not > an internal Nexus server. It is a public artifact repository for trying out > new things. I think the Maven project should get its own metadata right... > Why are you resisting? Do you see problems when updating master to > 3.0.0-SNAPSHOT? > > Benedikt > > > > > > 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 < > brit...@apache.org> > > > 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
Why you change POM if there is no problem? If the problem is in deploy-plugin then it should be fixed. On Thu, Feb 14, 2019 at 11:57 AM Olivier Lamy wrote: > makes sense for me. I will update master branch with correct version > > On Thu, 14 Feb 2019 at 20:42, Benedikt Ritter wrote: > > > Am Mi., 13. Feb. 2019 um 17:48 Uhr schrieb Tibor Digana < > > tibordig...@apache.org>: > > > > > Is it so a big problem to keep both versions? This is our internal > Nexus > > > server anyway. > > > > > > > From my PoV the metadata is incorrect. Latest should point to the latest > > available build. At the moment it does not. The Snapshot repository is > not > > an internal Nexus server. It is a public artifact repository for trying > out > > new things. I think the Maven project should get its own metadata > right... > > Why are you resisting? Do you see problems when updating master to > > 3.0.0-SNAPSHOT? > > > > Benedikt > > > > > > > > > > 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 < > > brit...@apache.org> > > > > 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 > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy >
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
makes sense for me. I will update master branch with correct version On Thu, 14 Feb 2019 at 20:42, Benedikt Ritter wrote: > Am Mi., 13. Feb. 2019 um 17:48 Uhr schrieb Tibor Digana < > tibordig...@apache.org>: > > > Is it so a big problem to keep both versions? This is our internal Nexus > > server anyway. > > > > From my PoV the metadata is incorrect. Latest should point to the latest > available build. At the moment it does not. The Snapshot repository is not > an internal Nexus server. It is a public artifact repository for trying out > new things. I think the Maven project should get its own metadata right... > Why are you resisting? Do you see problems when updating master to > 3.0.0-SNAPSHOT? > > Benedikt > > > > > > 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 < > brit...@apache.org> > > > 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 > > > >> > > > > >> > > > > > > > > > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
[SURVEY] How do you react to build failures?
Dear developers, I'm Carmine, a researcher at the University of Zurich interested in supporting developers working with CI/CD. Among the benefits provided by Continuous Integration (CI), increased team productivity and release frequency are perceived as the main advantages. However, changes that contain defects or that suffer from a poor-quality can lead to build failures that stop a team from delivering. The recent Report on the State of DevOps [1] states: "When failures occur, it can be difficult to understand what caused the problem" and previous work found that developers spend on average one hour to fix build breaks! In our group at the University of Zurich (Switzerland), we are developing new strategies to provide developers with the right assistance to solve build failures faster and more efficiently. To achieve this, we first need to understand the state of practice from real developers and we would like to learn about your personal experience with build failures in this survey. I would really appreciate if you could find the time to fill out the following survey to help me in my research: https://docs.google.com/forms/d/e/1FAIpQLSdw-RuDHv7Vlu2A7I4iGm1yC99xE65lk8UmIqxMJNMIxSpGzQ/viewform?usp=sf_link Filling out the survey will take you 5min (7min at maximum). Please note that participating in the questionnaire is completely anonymous, but we will publish the anonymized answers as part of a scientific publication. If you have any questions about the questionnaire or our research, please do not hesitate to contact me. Best regards, Carmine Vassallo Doctoral Student at the University of Zurich, Switzerland [1] Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: State of DevOps 2018: Strategies for a New Economy, 2018 https://cloudplatformonline.com/2018-state-of-devops.html
Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot
Am Mi., 13. Feb. 2019 um 17:48 Uhr schrieb Tibor Digana < tibordig...@apache.org>: > Is it so a big problem to keep both versions? This is our internal Nexus > server anyway. > >From my PoV the metadata is incorrect. Latest should point to the latest available build. At the moment it does not. The Snapshot repository is not an internal Nexus server. It is a public artifact repository for trying out new things. I think the Maven project should get its own metadata right... Why are you resisting? Do you see problems when updating master to 3.0.0-SNAPSHOT? Benedikt > > 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: Fwd: FOSDEM 19 Debian Java talk
Hi Robert, Am 12.02.19 um 20:09 schrieb Robert Scholte: [...] > 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. We hear this a lot and it seems to be more common in the Java community. From Debian's point of view (other distributions like Fedora share the same view) it is essential being able to rebuild software from source. The prerequisite is the availability of source code of course. Most of us find it even strange when upstream developers recommend to use their prebuilt versions. Do they have something to hide? Why can't they just make building from source easy and trivial? We believe that every user should have the ability to modify software but this is only possible if she can build it from source. We go to great lengths to ensure that all software complies with Debian's free software guidelines. For the enduser the language and build tools of a certain piece of software almost become meaningless. They just type "apt source maven", change into the maven directory and rebuild the software with another one-liner. In case of Maven I don't see where our release differs fundamentally from your binary releases. As I said there is only one reproducibility patch left that doesn't change the functionality at all. So what we do is grab your sources from https://github.com/apache/maven/releases or maven.apache.org. In our opinion, without making any significant changes, it should just behave as your binary release when we build it from source. Otherwise there is source code missing or different. > 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. It is a challenge to build Maven from source. We solved the bootstrapping problem and now we can use Debian's Maven version to build newer versions but we have to follow a certain build order when we make an update. > 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'? This is how it looks on Debian 9 "Stretch" at the moment. Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 1.8.0_181, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: de_DE, platform encoding: UTF-8 OS name: "linux", version: "4.9.0-8-amd64", arch: "amd64", family: "unix" It is obvious from Maven home I guess but there is no special emphasis on Debian because when you install Maven from Debian you will never get a prebuilt binary release, this is implicit for all software in Debian's main distribution. > - What is the optimum way of distributing Maven sources? For example: > also providing compile and package scripts (instead of calling > maven-plugins)? The major headache for us is the initial bootstrapping of new compilers or build tools. We often write our own Ant scripts to solve the chicken and egg problem. For Maven this is currently solved but if I recall correctly there are sometimes plugins that require a certain Maven version which in turn requires a specific plugin version, a classic dependency loop. So if there was a way to build Maven without Maven or certain plugins that would obviously make our life easier. [...] >> Our biggest challenge is Gradle. If Robert wants to help us then he >> should never rewrite parts of Maven in Kotlin or encourage developers to >> use a specific prebuilt version of Maven and to ship a script in every >> project that downloads it from the internet (gradle-wrapper). ;) > > Interesting :) We've been discussing how we could get more contributors > and Kotlin was one idea, but that one didn't make it. > Even though we as Maven developers don't like the wrapper, the community > is asking for it, so we're
Re: 3.6.1 release?
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 > >> > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
