Re: Road forward for: New flag to verify the status
"3" for core Cheers Jesper On 26/04/2024 16.11, Juul Hobert wrote: Hi, It's been a while since changes have been made to MNG-6869. It adds helpful functionality that is particularly useful when you're on a company network and want to do some basic checks to verify if Maven is working. This will be helpful for a large group of users and helps in solving basic issues and therefore could reduce false issues being reported about "Maven not working". The pull request unsatisfyingly ended up in a discussion where three flavors came across: implement it in core, in a plugin or in an extension. In summary the following arguments apply to the three different flavors: Move it to a plugin + Does not introduce extra complexity in core - Needs additional downloads and could fail before the basic checks occur Move it to an extension + Does not introduce extra complexity in core - Requires additional installation steps before it can be used (we could consider to ship the extension with Maven to circumvent that) Put it in core + Works without requiring additional downloads / installation steps + Can do all basic checks I like to know how the community thinks about this, so please reply briefly with the following if you have a opinion about it: - "1" for plugin - "2" for extension - "3" for core - "4" drop the idea, close the ticket I'm planning to work on it on the 10th of May and would like to continue working on it then. I would appreciate it if replies are given before this date. Cheers Juul Hobert, also on behalf of Giovanni van der Schelde - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Require Java 17 for Maven 4
+1 On 28/02/2024 08.30, Benjamin Marwell wrote: Hi Maven Devs/Users/Committers and PMC members! After several discussions on the mailing lists, I would like to start a vote in favour of setting the minimal Java bytecode target of Maven-Core 4 to 17 and hence require Java 17 for Maven 4. This is a procedural majority vote [1*]: You can also vote with fractions and negative votes are not vetoes. Please also notice: * Maven 3 will stay at Java 8 no matter what. * We may raise Maven 4 to JDK 21 later if we feel like it (depending on the release date). This is not part of this vote. * The linked PR is not part of this vote (this is not a code vote). But you may take a look at it to understand the intended change. PR: https://github.com/apache/maven/pull/1430 Maven-Parent will not be raised with this vote, the other PR is not part of this vote. Please refrain from starting discussions in this thread, but do include a reasoning on downvotes and feel free to start a new discussion on the mailing list, or comment on the existing ones. --- Vote open for 72 hours: [ ] +1 (set JDK17 min version for Maven 4.x) [ ] +0 [ ] -1 (please include reasoning) --- - Ben [1*]: https://www.apache.org/foundation/voting.html - 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: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
I think removing the "suprise" part of a minor upgrade would be a good compromise :-) Brgds Jesper Udby On 29/03/2021 10.34, Romain Manni-Bucau wrote: Le lun. 29 mars 2021 à 10:24, Jesper Udby a écrit : @Romain: no not really. I'd hate to be in that situation where an "innocent" 3.6.3->3.6.4 upgrade failed and I'd had to go into more details about why. I've been to one of these orgs where I was doing architecture, data modelling, solution development and devops (as a one-man army) where unexpected surprises were not welcome. I hear that but I fail to see how 3.x x > 6 solves that. In all cases you will go that way - or not upgrade which is not a topic for that thread - and since 3.x will be advertised as fixing a security issue it wil be required anyway to go that way, no? So, at the moment, I only see people as being forced to backport the fix and configuration in all their settings to be able to pass security validations/certifications/... and still use the 3.6 to respect their versioning constraint. Would doing a 3.6.4 without the default config but the fix (which means it can be enabled but does not break OOTB) and a 3.7 (or whatever) with the config added in *by default* would be saner for everyone? Sounds like a good compromise for everyone, no? Brgds Jesper Udby On 29/03/2021 09.37, Romain Manni-Bucau wrote: @Jesper: just to refine, it is just a matter of adding a custom settings.xml for the build/on the CLI (or override it in maven depending what the org wants) to enable back http so you still don't have to set SSL on nexus. Does it change your answer since the first point becomes no more fully accurate with that fact? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github < https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book < https://www.packtpub.com/application-development/java-ee-8-high-performance Le lun. 29 mars 2021 à 09:23, Som Lima a écrit : Any way thanks for the cli API On Mon, 29 Mar 2021, 08:18 Som Lima, wrote: When you put a url in a browser and hit enter. IF the url has to travel to a server on the intranet then an algorithm ensuring tight coupling will be executed. IF the url has to travel on the internet to get to a server then a completely different algorithm gets executed. The WAN algorithm relies on CHECKSUM to ensure data integrity. It is weak and prone to easy vulnerability. At the very minimum the user needs to implement encryption (HTTPS). The LAN algorithm is quite different, there is far more network traffic between two parties to ensure strong secure connection. API developers and application developers do not have access to this layer. It is transparent. On Mon, 29 Mar 2021, 08:03 Romain Manni-Bucau, wrote: Hi, I kind of agree intranet is as secure as the internet (ie a lot of attacks done last years were done on intranets). yes you are in a local vpc not accessible from the outside but it is also where hackers try to enter first since then it is open bar for them. That said it is very common to use http as a quick serving too - thinking to trainings and hacking sessions where a tomcat serves a local m2 for example. I guess this all lead to the fact we need to support HTTP anyway and enable/document how to still use it in the coming version (and not prevent it in a hardcoded fashion). In terms of security it would be left to the user to enable it explicitly - defaults being secured, exactly as the 0-day vulnerability got fixed in all softwares. Sounds more than relevant to me to enable that case while it is not the default. That said, having this kind of toggle pushes to 3.6.4 more than all others by design then, no? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github < https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book < https://www.packtpub.com/application-development/java-ee-8-high-performance Le lun. 29 mars 2021 à 08:51, Som Lima a écrit : I thought we were talking about computer programming algorithms. Social engineering is outside the scope of the discussion on the subject of the algorithm devised in the invisible ( to API developers), network layer implementation. The scope of discussion is that the intranet is a tightly coupled comm system therefore secure by design. Imagine a couple holding each other tightly so no intruder, (third party) can come in between and interfere. Meanwhile the internet (loosely coupled) due to physical limitations could not be implemented using the same algorithm. It was left to users to work out the security wh
Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
@Romain: no not really. I'd hate to be in that situation where an "innocent" 3.6.3->3.6.4 upgrade failed and I'd had to go into more details about why. I've been to one of these orgs where I was doing architecture, data modelling, solution development and devops (as a one-man army) where unexpected surprises were not welcome. Brgds Jesper Udby On 29/03/2021 09.37, Romain Manni-Bucau wrote: @Jesper: just to refine, it is just a matter of adding a custom settings.xml for the build/on the CLI (or override it in maven depending what the org wants) to enable back http so you still don't have to set SSL on nexus. Does it change your answer since the first point becomes no more fully accurate with that fact? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 29 mars 2021 à 09:23, Som Lima a écrit : Any way thanks for the cli API On Mon, 29 Mar 2021, 08:18 Som Lima, wrote: When you put a url in a browser and hit enter. IF the url has to travel to a server on the intranet then an algorithm ensuring tight coupling will be executed. IF the url has to travel on the internet to get to a server then a completely different algorithm gets executed. The WAN algorithm relies on CHECKSUM to ensure data integrity. It is weak and prone to easy vulnerability. At the very minimum the user needs to implement encryption (HTTPS). The LAN algorithm is quite different, there is far more network traffic between two parties to ensure strong secure connection. API developers and application developers do not have access to this layer. It is transparent. On Mon, 29 Mar 2021, 08:03 Romain Manni-Bucau, wrote: Hi, I kind of agree intranet is as secure as the internet (ie a lot of attacks done last years were done on intranets). yes you are in a local vpc not accessible from the outside but it is also where hackers try to enter first since then it is open bar for them. That said it is very common to use http as a quick serving too - thinking to trainings and hacking sessions where a tomcat serves a local m2 for example. I guess this all lead to the fact we need to support HTTP anyway and enable/document how to still use it in the coming version (and not prevent it in a hardcoded fashion). In terms of security it would be left to the user to enable it explicitly - defaults being secured, exactly as the 0-day vulnerability got fixed in all softwares. Sounds more than relevant to me to enable that case while it is not the default. That said, having this kind of toggle pushes to 3.6.4 more than all others by design then, no? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github < https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book < https://www.packtpub.com/application-development/java-ee-8-high-performance Le lun. 29 mars 2021 à 08:51, Som Lima a écrit : I thought we were talking about computer programming algorithms. Social engineering is outside the scope of the discussion on the subject of the algorithm devised in the invisible ( to API developers), network layer implementation. The scope of discussion is that the intranet is a tightly coupled comm system therefore secure by design. Imagine a couple holding each other tightly so no intruder, (third party) can come in between and interfere. Meanwhile the internet (loosely coupled) due to physical limitations could not be implemented using the same algorithm. It was left to users to work out the security which can be done using encryption (HTTPS) as one means of security. Other strategies are also available. Only the CHECKSUM was supplied as means of data integrity by the network Gods. Anybody want to talk about intraprocess (tight coupling) and Interprocess (loose coupling) ? On Sun, 28 Mar 2021, 15:39 Markus KARG, wrote: Nonsense. It is common sense that most criminal acts are spawned from within the local network, due to social engineering. -Markus -Ursprüngliche Nachricht- Von: Som Lima [mailto:somplastic...@gmail.com] Gesendet: Sonntag, 28. März 2021 15:06 An: Maven Developers List Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other BTW there should be an option to still use unsecure http as many people run http in their LANs. I could be wrong but I think the intranet is a tightly coupled comm system therefore it is secure by design. On Sun, 28 Mar 2021, 13:31 Markus KARG, wrote: We should not do any tri
Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
Hi, I'd like to give my input too. 3.6.4 is IMHO not an option since there is change of behavior that would come as a surprise for some. I know of smaller organisations where running nexus, jenkins etc on HTTP is fine and switching to SSL is not trivial since they do not have proper DevOps or certificate management in place. 3.7.0 is controversial since it would not contain "advertised features". 3.8.0+ is better, even if it will cause some surprises for people who'd believe that features not delivered in 3.7 would then at least be available in 3.8... And I think we should always be pragmatic. Semver is a scheme that can be interpreted/implemented in different ways. I don't see skipping a number as a big deal. Best regards Jesper Udby On 29/03/2021 09.03, Romain Manni-Bucau wrote: Hi, I kind of agree intranet is as secure as the internet (ie a lot of attacks done last years were done on intranets). yes you are in a local vpc not accessible from the outside but it is also where hackers try to enter first since then it is open bar for them. That said it is very common to use http as a quick serving too - thinking to trainings and hacking sessions where a tomcat serves a local m2 for example. I guess this all lead to the fact we need to support HTTP anyway and enable/document how to still use it in the coming version (and not prevent it in a hardcoded fashion). In terms of security it would be left to the user to enable it explicitly - defaults being secured, exactly as the 0-day vulnerability got fixed in all softwares. Sounds more than relevant to me to enable that case while it is not the default. That said, having this kind of toggle pushes to 3.6.4 more than all others by design then, no? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 29 mars 2021 à 08:51, Som Lima a écrit : I thought we were talking about computer programming algorithms. Social engineering is outside the scope of the discussion on the subject of the algorithm devised in the invisible ( to API developers), network layer implementation. The scope of discussion is that the intranet is a tightly coupled comm system therefore secure by design. Imagine a couple holding each other tightly so no intruder, (third party) can come in between and interfere. Meanwhile the internet (loosely coupled) due to physical limitations could not be implemented using the same algorithm. It was left to users to work out the security which can be done using encryption (HTTPS) as one means of security. Other strategies are also available. Only the CHECKSUM was supplied as means of data integrity by the network Gods. Anybody want to talk about intraprocess (tight coupling) and Interprocess (loose coupling) ? On Sun, 28 Mar 2021, 15:39 Markus KARG, wrote: Nonsense. It is common sense that most criminal acts are spawned from within the local network, due to social engineering. -Markus -Ursprüngliche Nachricht- Von: Som Lima [mailto:somplastic...@gmail.com] Gesendet: Sonntag, 28. März 2021 15:06 An: Maven Developers List Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other BTW there should be an option to still use unsecure http as many people run http in their LANs. I could be wrong but I think the intranet is a tightly coupled comm system therefore it is secure by design. On Sun, 28 Mar 2021, 13:31 Markus KARG, wrote: We should not do any tricks or unexpected behavior but just stick with SemVer. If there is a need for a security fix, it has to be 3.6.4 and BTW there should be an option to still use unsecure http as many people run http in their LANs. If it contains backwards-compatible features, it has to be 3.7.0. If it breaks backwards-compatibility, it has to be 4.0.0. In no case it can be 3.8.0. If mvnw was proposed for 3.7 but is not here now, then we either have to wait with 3.7.0, or we have to tell people that we move mvnw to 3.8 or 4.0. I do not see a need for any discussion at all, as SemVer is pretty clear about the sole correct answer. -Markus -Ursprüngliche Nachricht- Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] Gesendet: Sonntag, 28. März 2021 11:47 An: Maven Developers List Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other Hi all, Before we reroll the failed 3.8.0 I'd like we discuss openly the next versioning since it seems we didn't reach a consensus yet and trying to not create too much friction for users and in the community. As a reminder the only feature the release will get is to prevent HTTP repo (in favor of HTTPS ones). In that reg
Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0
+1 😃 Jesper Udby Hent BlueMail til Android Den 30. okt. 2019 02.34, fra 02.34, Manfred Moser skrev: >+1 > >or more ... haha > >Manfred > >Stephen Connolly wrote on 2019-10-29 16:23 (GMT -07:00): > >> +1 >> >> On Tue 29 Oct 2019 at 20:11, Karl Heinz Marbaise >wrote: >> >>> Hi to all, >>> >>> based on the discusion this is the formal VOTE to lift the minimum >of >>> Maven Core with version 3.7.0 to JDK 8 minimum. >>> >>> Vote open for at least 72 hours. >>> >>> [ ] +1 >>> [ ] +0 >>> [ ] -1 >>> >>> >>> Kind regards >>> Karl Heinz Marbaise >>> >>> >- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> -- >> Sent from my phone >> > > >- >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Retire Maven Repository Builder
+1 Hent BlueMail til Android Den 7. aug. 2019 21.13, fra 21.13, Robert Scholte skrev: >Hi, > >The Apache Maven project consist of about 90 (sub)projects. Due to the > >small number of volunteers and the huge amount of code to maintain >we're >missing enough space to make real progress on all these projects, >including our ambitious ideas for the next major version(s) of Maven >itself. >To be able to gain more focus we need to criticize the current >subprojects >and decide if it is worth maintaining. > >https://maven.apache.org/shared/maven-repository-builder/ describes the > >main purpose in one line: Maven shared components. Okay, that's >actually >quite bad. >Based on >https://mvnrepository.com/artifact/org.apache.maven.shared/maven-repository-builder > >the library isn't used a lot. Both maven-assembly-plugin and >maven-plugin-testing-tools don't use this library anymore. >The sourcecode looks a bit like it has the same purpose as >dependency:copy-dependencies. > >I therefore propose that we retire the maven-repository-builder. > >I don't think it makes sense to do a final release. Instead we should >update the documentation and freeze the codebase. > >The process for retiring a plugin is described here: >https://maven.apache.org/developers/retirement-plan-plugins.html >[https://maven.apache.org/developers/retirement-plan-plugins.html] > >The vote is open for 72 hours. >[ ] +1 Yes, it's about time >[ ] -1 No, because... > > > > >- >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Wagon version 3.2.0
+1 > Den 26. september 2018 klokken 21:50 skrev Michael Osipov > : > > > Hi, > > We solved 15 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=12343926 > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1452/ > > https://repository.apache.org/content/repositories/maven-1452/org/apache/maven/wagon/wagon/3.2.0/wagon-3.2.0-source-release.zip > > > Source release checksum(s): > wagon-3.2.0-source-release.zip > sha512: > > 31d79dc25c66f14739b4fd51aa906e4f884287f690d133db4a4021ff013e939618b772124f1a8efb009261facbe229d1a86512ef75b4dc37e95589f1717749b5 > > > Staging site: > https://maven.apache.org/wagon-archives/wagon-LATEST/ > > > Guide to testing staged releases: > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > Vote open for 72 hour s. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > 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: [VOTE] Release Apache Maven JXR Plugin version 3.0.0
+1 :-) > Den 24. september 2018 klokken 01:19 skrev Olivier Lamy : > > > > +1 > > On Sat, 22 Sep 2018 at 21:29, Robert Scholte > wrote: > > > Hi, > > > > We solved 18 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527&version=12330848&styleName=Text > > > > > There is still 1 issues left in JIRA: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317527%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > > > > Staging repo: > > > https://repository.apache.org/content/repositories/maven-1449/ > > > > > https://repository.apache.org/content/repositories/maven-1449/org/apache/maven/jxr/jxr/3.0.0/jxr-3.0.0-source-release.zip > > > > > Source release checksum(s): > > jxr-3.0.0-source-release.zip sha512: > > > > > > ccf691d97fa933030af58755fcf18678b7f4ed65b5ee4733e45cdbf023a51f755049fa3355e9d4aad8e78da510915695263f3363d517a2d562bc8780c765734b > > > > > Staging site: > > https://maven.apache.or g/jxr-archives/jxr-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > - > > 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org