Maven's snapshot of central repository
Hi, I am a newbie and wants to work with maven data. I found a dataset at: https://data.4tu.nl/repository/uuid:68a0e837-4fda-407a-949e-a159546e67b6 But that was the snapshot of the central repository dated July 30, 2011. I would like to use the latest snapshot. I will use the data for my master's work. I tried to search a bit and did not find any data dump. Please help me if you know how to store a data dump of the central repository of maven just like StackOverflow or GitHub. Thanks C M Khaled Saifullah - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Resolver version 1.3.2
+1 on *.jar binaries check, I was able to rebuild the jars: they were built with javac compiler from JDK 11 on a unix family OS, and I get the exact same bytecode (even if I built with JDK 11.0 when Karl Heinz built with JDK 11.0.1) There were the usual not Reproducible Build little differences, with 2 additional issues: 1. "Private-Package" manifest entry content has not the same order between builds 2. META-INF/sisu/javax.inject.Named content has non reproducible order for content Regards, Hervé Le samedi 23 février 2019, 17:20:23 CET Karl Heinz Marbaise a écrit : > Hi to all, > > We solved 3 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628 > rsion=12344318 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%2 > 0resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DES > C%2C%20updated%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1488 > > https://repository.apache.org/content/repositories/maven-1488/org/apache/mav > en/resolver/maven-resolver/1.3.2/maven-resolver-1.3.2-source-release.zip > > Source release checksum(s): > maven-resolver-1.3.2-source-release.zip sha1: > 44c0b4f5c97cabe790ef27b7e74fadf554d6506a > > maven-resolver-1.3.2-source-release.zip sha512: > 4a795e63c896e75bb6cfd1aab276a4ab8099be42b2e6091c58df9f5a992e045c263231350ac0 > 218d64954937cbd9691c2a880992e36c52d3378f30e29914a582 > > Staging site: > http://maven.apache.org/resolver-archives/resolver-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 > > Kind regards > Karl Heinz Marbaise > > - > 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: Surefire maintenance release
Hi Using slack is a good idea for discussion. But bear mind @ASF all decisions must appear on a mailing list or in a jira ticket. Interesting blog entry regarding this topic "If it didn’t happen on the mailing list, it didn’t happen." http://theapacheway.com/on-list/ think about timezone or people availability and btw this slack is only for @apache user etc... On Wed, 27 Feb 2019 at 04:01, Tibor Digana wrote: > Stephane, > I have been quite busy with other JUnit5 work - SUREFIRE-1585. > Can you join us in the chat on Slack "the-asf.slack.com"? > You will find the Channel named "surefire". > Ping us as soon as you are ready and we will find some way. > I am glad! > > Cheers > Tibor > > On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll > > wrote: > > > Hi everyone, > > > > It's great to see the progress on Surefire 3.0 and I wanted to reach out > to > > discuss a practicable problem with the 2.x line. There are a number of > > fixes for JUnit 5 that are only available in the 3.x line that isn't GA > > yet. [1][2] > > > > Putting my Spring Boot hat for a min, this actually prevents us from > > upgrading our test support to JUnit 5: our plan is to offer maximum > > flexibility by providing the vintage engine (so that users can keep their > > tests and migrate at their own pace). > > > > We can't upgrade to a milestone as our upgrade policy prevents that > > (regardless of how stable this is and especially since backward > > incompatible changes have been pushed to the latest milestone). So we're > > kind of stuck. > > > > Would there be an appetite to backport those fixes and release a 2.22.2? > > > > Thanks, > > S. > > > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614 > > [2] > https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546 > > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Surefire maintenance release
Stephane, I have been quite busy with other JUnit5 work - SUREFIRE-1585. Can you join us in the chat on Slack "the-asf.slack.com"? You will find the Channel named "surefire". Ping us as soon as you are ready and we will find some way. I am glad! Cheers Tibor On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll wrote: > Hi everyone, > > It's great to see the progress on Surefire 3.0 and I wanted to reach out to > discuss a practicable problem with the 2.x line. There are a number of > fixes for JUnit 5 that are only available in the 3.x line that isn't GA > yet. [1][2] > > Putting my Spring Boot hat for a min, this actually prevents us from > upgrading our test support to JUnit 5: our plan is to offer maximum > flexibility by providing the vintage engine (so that users can keep their > tests and migrate at their own pace). > > We can't upgrade to a milestone as our upgrade policy prevents that > (regardless of how stable this is and especially since backward > incompatible changes have been pushed to the latest milestone). So we're > kind of stuck. > > Would there be an appetite to backport those fixes and release a 2.22.2? > > Thanks, > S. > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614 > [2] https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546 >
Re: [VOTE] Release Apache Maven Artifact Transfer Version 0.11.0
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 24.02.19 21:34, Karl Heinz Marbaise wrote: Hi to all, We solved 3 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12344643 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20maven-artifact-transfer Staging repo: https://repository.apache.org/content/repositories/maven-1489 https://repository.apache.org/content/repositories/maven-1489/org/apache/maven/shared/maven-artifact-transfer/0.11.0/maven-artifact-transfer-0.11.0-source-release.zip Source release checksum(s): maven-artifact-transfer-0.11.0-source-release.zip sha1: c8c60ebb6046450ff75bfb60f64af415b3b5ea72 maven-artifact-transfer-0.11.0-source-release.zip sha512: daccd4844ebc389d8e269be41b59c0754a473da9b447c86556b6c80b0208f3b08bc822372d4c6055a09b4130665cb7803b807e427daf160bc29d20d026c85963 Staging site: http://maven.apache.org/shared-archives/maven-artifact-transfer-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 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire maintenance release
Thanks Robert. To emphasis on the goal, we'd like to get a GA release of surefire that fully supports JUnit 5 (including the use of the vintage engine) and we'd like to see if it would be possible to backport the two fixes I've mentioned. If there is an appetite for that, we're happy to help and test snapshos and I believe the JUnit team would also be willing to help as they have contributed numerous PRs in the past. If a fix cannot be enabled by default in a maintenance release, we'd like to understand why and how we can mitigate this for our users. Thank you, S. On Mon, Feb 25, 2019 at 3:01 PM Robert Scholte wrote: > Let me guide this discussion a bit, because I see tends to go to the > negative side, whereas I'd like to see this as an open and fair discussion. > > It is not up to us to decide what any company/organization policy is > regarding versions. > Putting yourself in the position of Pivotal it makes sense to rely only > on > GA versions. > There must be a reason why Surefire is released with milestones: things > might break and maybe for valid reasons. > We should prevent the situation where contributors see a milestone and > "kindly" update it because there's a non-milestone version available, > whereas one of the next surefire milestone would decide to break > backwards > compatibility. So this is not just about looking back and knowing that > the > latest milestone still works like 2.22.1, but also about the upcoming > versions! > > To me the question of Stephane is fair: is it possible to backport > SUREFIRE-1614 and SUREFIRE-1546? In other words: do these fixes depend on > 3.0.0 specific changes or not? If so, then there's no reason to continue. > Otherwise is it possible (with or without help of Pivotal or other > volunteers) to provide patches which can be applied and released? > > Stephane could have picked this up on his own, bypassing the main > maintainers of surefire, but he didn't. Instead he's asking for > cooperation. > > So try to keep the discussion polite and let's work together toward > solutions. > > thanks, > Robert > > On Mon, 25 Feb 2019 12:53:04 +0100, Tibor Digana > > wrote: > > > Sorry, in normal circumstances projects release BOM with > > dependencyManagement but not the pluginManagement. > > We did not break current users and so we split the entire work into > > multiple stages. The naming convention really is not a problem as you can > > see and Stephane confirmed it. > > So we made welcome compromises on our side in ASF and now your steps in > > Spring should be to make compromise in your internal policies. > > > > Cheers > > Tibor > > > > On Mon, Feb 25, 2019 at 11:44 AM Stephane Nicoll > > > > wrote: > > > >> Thanks for the reply. See my feedback below > >> > >> On Mon, Feb 25, 2019 at 11:20 AM Tibor Digana > >> wrote: > >> > >> > Stephane, the problem is with Spring upgrade policy as I have > >> understood. > >> > > >> > What about releasing RC4 for you? > >> > > >> > >> It does not matter how you call it. We don't want to be in a position > >> where > >> our users get plugin management for a given version of surefire that: > >> > >> 1. is not GA > >> 2. subsequent milestone/RC/release will break backward compatibility > >> > >> > >> > >> > Do you really need to have SUREFIRE-1546 done? We do not want to > >> enable > >> it > >> > implicitly as it is done in master right now, and therefore M4 needs > >> to > >> > take more time to enable this feature via configuration. > >> > > >> > >> I think we do. > >> > >> A minor release of Spring Boot cannot require users to write their tests > >> using the JUnit 5 API as it would be a breaking change for every test > >> they’ve written using JUnit 4. On the other hand, we know that users > >> want > >> to be able to use JUnit 5 and we’re holding them back at the moment. > >> > >> The way the JUnit team has dealt with the migration is the use of the > >> vintage engine that we would provide by default. Users that have > >> migrated > >> their tests can exclude the vintage engine while users that are in the > >> process of migrating can benefit from a setup where they can start > >> migrating while keeping some of their tests unchanged. > >> > >> We need surefire to support that scenario and the 2.x line does not. > >> > >> > >> > > >> > I see that the policy is against itself. If you concentrate only on > >> > policies with project dependencies, you won't break anything. > >> > We made a big investment (SUREFIRE-1614, ...) to not to break current > >> > users. So please let us continue our work and let you and yourself use > >> > 3.0.0-M3 and continue whatever it means with Spring policies.Our > plan > >> is > >> to > >> > not to break backwards compatibility till 3.0.0-M5. > >> > > >> > >> As I've indicated, we cannot upgrade to a version and then be stuck on > >> milestones because a later one introduces backward incompatible changes. > >> > >> > >> > > >> > There is reason that you use Surefire in your project
