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 which can be done usi
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 tricks or unexpected be
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 regard it is a breaking chan
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] Release Apache Maven Version 3.6.2
+1 On 28.08.2019 21:17, Enrico Olivelli wrote: Hi, We have solved 52 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12345234 There are issues left in JIRA for Maven core: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1529 The distributable binaries and sources can be found here: https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/ Specifically the zip, tarball and source archives can be found here: https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.zip https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.tar.gz https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.zip https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.tar.gz The release artifacts are staged for distribution in: https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.2 Source release checksum(s): apache-maven-3.6.2-src.tar.gz sha1: 373ffbe9fc88e5facbe10d7a6f6badd243545ade sha512: 235198b48d29fe2f2394f2607a9a1637acfd0286beacb974c566f7f36ac6c469871a0db287539b2b62e6322d7423f586949e41cbbfea330fe03bf690688f6fd7 apache-maven-3.6.2-src.zip: sha1: c6c5bd9828b3350905e97177978724eed0698de3 sha512: d7fdafbc16bd547bc3c2513255df375c2a616b04d414c2ffd7d9deb9931fab5db4c7ac912cc4bb0d96d0a083560b3cc1848ea9eecc3aeb4e4c5184329a7ead5b Git tag: https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=40f52333136460af0dc0d7232c0dc0bcf0d9e117 Staging site: https://maven.apache.org/components/ref/3-LATEST/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Enrico Olivelli - 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] Retire Maven Ant Plugin
Hi! +1 - about time! :-) Cheers Jesper On 28.05.2019 20:54, Robert Scholte wrote: Hi, The Apache Maven project consist of about 100 (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. The goal of the Apache Maven Ant Plugin it to generate Ant build files based on a pom.xml and was released for the last time in December 2014. Due to the different ways that Ant and Maven work I don't think it makes sense anymore to maintain a plugin to transform Maven files to Ant. See https://maven.apache.org/plugins/maven-ant-plugin/ [https://maven.apache.org/plugins/maven-ant-plugin/] To be clear, this is NOT the plugin you can use to run Ant within Maven; that's the maven-antrun-plugin. I therefore propose that we retire the maven-ant-plugin. 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 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=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=12330848=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
[jira] Created: (MSUREFIRE-58) Cannot override read-only parameter: classpathElements
Cannot override read-only parameter: classpathElements -- Key: MSUREFIRE-58 URL: http://jira.codehaus.org/browse/MSUREFIRE-58 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.2 Reporter: Jesper Zedlitz Priority: Minor When calling mvn site on a multi-module project the goal surefire:test fails for the second project: Error configuring: org.apache.maven.plugins:maven-surefire-plugin. Reason: ERROR: Cannot override read-only parameter: classpathElements in goal: surefire:test mvn test works and runs the tests on all modules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNGECLIPSE-67) show progress of download
show progress of download - Key: MNGECLIPSE-67 URL: http://jira.codehaus.org/browse/MNGECLIPSE-67 Project: Maven 2.x Extension for Eclipse Type: Improvement Reporter: Jesper Zedlitz Assigned to: Eugene Kuleshov It would be very nice if the user could see something while downloading artifacts from a repository. I was quite frustrated because Eclipse seems to hang during Building workspace. Only with a network sniffer I saw that a lot was happening in the background. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNGECLIPSE-68) possibility to disable download of sources
possibility to disable download of sources -- Key: MNGECLIPSE-68 URL: http://jira.codehaus.org/browse/MNGECLIPSE-68 Project: Maven 2.x Extension for Eclipse Type: Improvement Versions: 0.0.4 Reporter: Jesper Zedlitz Assigned to: Eugene Kuleshov I suppose all users of slow or expensive internet connections would be happy if there was a switch to disable the download of (usually quite large) source packages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-67) show progress of download
[ http://jira.codehaus.org/browse/MNGECLIPSE-67?page=comments#action_57322 ] Jesper Zedlitz commented on MNGECLIPSE-67: -- Eclipse's progress bar stopped at 27% for a really long time. In the Console View lines like these were repeated (I think for every artifact being downloaded): 30.01.06 20:00:13 CET: [DEBUG] Found 0 components to load on start 30.01.06 20:00:13 CET: [DEBUG] Building Maven user-level plugin registry from: '/home/jesper/.m2/plugin-registry.xml' 30.01.06 20:00:13 CET: [DEBUG] Trying repository central 30.01.06 20:00:58 CET: [WARN] Unable to get resource from repository central (http://repo1.maven.org/maven2) 30.01.06 20:00:58 CET: Unable to download the artifact from any repository show progress of download - Key: MNGECLIPSE-67 URL: http://jira.codehaus.org/browse/MNGECLIPSE-67 Project: Maven 2.x Extension for Eclipse Type: Improvement Reporter: Jesper Zedlitz Assignee: Eugene Kuleshov It would be very nice if the user could see something while downloading artifacts from a repository. I was quite frustrated because Eclipse seems to hang during Building workspace. Only with a network sniffer I saw that a lot was happening in the background. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNGECLIPSE-69) offline mode does not work
offline mode does not work Key: MNGECLIPSE-69 URL: http://jira.codehaus.org/browse/MNGECLIPSE-69 Project: Maven 2.x Extension for Eclipse Type: Bug Versions: 0.0.4 Reporter: Jesper Zedlitz Assigned to: Eugene Kuleshov Priority: Minor Setting the offline switch does not stop the plugin to download source jars from the central repository. Because of that the start of Eclipse takes very very long time. And since the source jar files do not exist in the repository this is repeated on every start. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-66) unable to find artifacts from attached tests
[ http://jira.codehaus.org/browse/MNGECLIPSE-66?page=comments#action_57232 ] Jesper Zedlitz commented on MNGECLIPSE-66: -- Yes, it works from the command line. Using 1.0-SNAPSHOT-test as version does not work because there is no directory 1.0-SNAPSHOT-test in .m2/repository/com/myco/app/foo. unable to find artifacts from attached tests Key: MNGECLIPSE-66 URL: http://jira.codehaus.org/browse/MNGECLIPSE-66 Project: Maven 2.x Extension for Eclipse Type: Bug Components: Dependency Resolver Versions: 0.0.3 Reporter: Jesper Zedlitz Assignee: Jason van Zyl I am using attached tests as described here: http://maven.apache.org/guides/mini/guide-attached-tests.html Although the test jar is already installed the plugin states it is Unable to download the artifact from any repository: com.myco.app:foo-1.0-SNAPSHOT.test-jar (using the same name as in the docu here as example). In the repository the name of the jar file is com.myco.app:foo-1.0-SNAPSHOT-tests.jar. Maybe just '-' and '.' are mixed up...? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNGECLIPSE-66) unable to find artifacts from attached tests
unable to find artifacts from attached tests Key: MNGECLIPSE-66 URL: http://jira.codehaus.org/browse/MNGECLIPSE-66 Project: Maven 2.x Extension for Eclipse Type: Bug Components: Dependency Resolver Versions: 0.0.3 Reporter: Jesper Zedlitz Assigned to: Eugene Kuleshov I am using attached tests as described here: http://maven.apache.org/guides/mini/guide-attached-tests.html Although the test jar is already installed the plugin states it is Unable to download the artifact from any repository: com.myco.app:foo-1.0-SNAPSHOT.test-jar (using the same name as in the docu here as example). In the repository the name of the jar file is com.myco.app:foo-1.0-SNAPSHOT-tests.jar. Maybe just '-' and '.' are mixed up...? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
