[RESULT] [VOTE] Maven Dependency Tree 3.2.1

Hi The vote has passed with 3 +1 Slawomir, Guillaume, Olivier I will finish the release process. cheers Olivier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

> Dreaming: but what if not a flag, but some filter(s) for "capabilities"? OSGi support generic capabilities/requirements model: https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html Just mentioning it ... for sure we one can re-implement this (again) in maven as well, as a pri

Re: [DISCUSS] Speed up release process?

I also fail to see how the 72 hours period is the root cause of any issue you have. Here are a few possible changes that could improve the release process: * Releases can be done in parallel or in batches. * If the fact that master branches are broken while releasing, we could certainly create

Re: [DISCUSS] Speed up release process?

Evidently you know something I don’t, and I hope you’ll explain it to me. For the 3rd time, > Which developers have to pause what activities? — Right now there are usually release votes in parallel. As I pointed out, all 308 could be in parallel. What relevance does your calculation have

Re: [DISCUSS] Quo Vadis Maven Site

Le vendredi 18 novembre 2022, 07:57:59 CET Slawomir Jaranowski a écrit : > Hi, > > some my thoughts > - site looks can be changed be skins - so can be more modern yes it seems people don't understand the menu generation with it's "decoration model", then we don't see many people doing more skins

Re: [DISCUSS] Quo Vadis Maven Site

+1000 this evaluation is much more fair it does not mean that looking at rearchitecturing a new site generation would not be useful key is > I like some parts of this. I don't agree with others. I suppose the good ideas from the Wiki should be prototyped: - on a basic mono-module project - on

[GitHub] [maven-project-utils] JLLeitschuh opened a new pull request, #5: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

JLLeitschuh opened a new pull request, #5: URL: https://github.com/apache/maven-project-utils/pull/5 # Security Vulnerability Fix This pull request fixes a Temporary File Information Disclosure Vulnerability, which existed in this project. ## Preamble The system temp

Re: [DISCUSS] Speed up release process?

damn me 16848 hours = 702 days = almost TWO YEARS of Maven releases just to build Maven itself. But, if you consider all apache artifacts (almost all, unsure is there other in different groupId) [cstamas@blondie local (master %)]$ find * -type f -name "*.jar" | grep "commons-" | wc -l 45 [cstamas

Re: [DISCUSS] Speed up release process?

+1 That sounds good to me. There is plenty of communication going on BEFORE the release is even kicked off.. from then on it really should be just process and minimal validation. If something goes wrong.. run another patch release. I would even go for .. lazy consensus after 48 hours counts

Re: [DISCUSS] Speed up release process?

David, I agree, and understand. But let me step back a bit: ASF (as it all started around httpd) as a foundation hosts MANY projects wildly different projects, and those projects usually have a handful (few, when compared to Maven) of "deliverables" or "artifacts" being released. Or in other word

Re: [DISCUSS] Speed up release process?

If all 153 projects released at once with 72 hour windows, that would be 72 hours. That’s just as plausible as sequential releases. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agre

Re: [DISCUSS] Speed up release process?

You are free to do your own research. I’ve seen plenty of “but we want the convenience of <72hr releases” discussions over the years, and the feedback I’ve seen is consistently that the reason for the “should” rather than “must” is to account for emergency security patches etc, not normal relea

[GitHub] [maven-shared-incremental] dependabot[bot] commented on pull request #15: Bump slf4j-api from 1.7.36 to 2.0.4

dependabot[bot] commented on PR #15: URL: https://github.com/apache/maven-shared-incremental/pull/15#issuecomment-1320510568 OK, I won't notify you about version 2.x.x again, unless you re-open this PR. 😢 -- This is an automated message from the Apache Git Service. To respond to the mess

[GitHub] [maven-shared-incremental] dependabot[bot] closed pull request #15: Bump slf4j-api from 1.7.36 to 2.0.4

dependabot[bot] closed pull request #15: Bump slf4j-api from 1.7.36 to 2.0.4 URL: https://github.com/apache/maven-shared-incremental/pull/15 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specif

[GitHub] [maven-shared-incremental] slachiewicz commented on pull request #15: Bump slf4j-api from 1.7.36 to 2.0.4

slachiewicz commented on PR #15: URL: https://github.com/apache/maven-shared-incremental/pull/15#issuecomment-1320510542 @dependabot ignore this major version -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL ab

Re: [DISCUSS] Speed up release process?

Lets try one question/issue per email… Which developers have to pause what activities. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agree with your statement about the board, as the

Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

My point was to get rid of sisu/plexus. In my mind, having the plugin do its own DI was a simple way to achieve that for maven4 plugins. But if that's not something we want, I'm certainly not advocating for additional complexity. I propose to have maven4 plugins be bootstrapped by maven with a s

Re: [DISCUSS] Speed up release process?

So Maven cares for us, hence the 72h? I don't get how one is deduced from another. And as they are (and usually are) dependent on each other from perspective of single release mgr local repo we could release all 150+, at the cost of breaking all the 150+ CI jobs and all source builds in the wild f

Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

No, I don't think so, the "capabilities" is just a "dream" piggybacked onto your story :) All in all, I think a flag but with reversed logic would be good: default is remain as-is (maven DI), and if flipped, then plugin DI. But again, "plugin DI" would not make much sense, if core still exposes a

Re: [DISCUSS] Speed up release process?

Side note: asf is about people not code so maven must care about people and this is why 72h came from. For me dependencies is not a reason to make release < 72h since you can release 10 projects in a single staging - anyone failling rolls back them all but that is the intent anyway right? It means

Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

You misunderstood me. I wasn't thinking about changing the way the classloader is built, just the way the dependency injection mechanism is done for plugins (and/or maven-core). Le ven. 18 nov. 2022 à 18:35, Tamás Cservenák a écrit : > Howdy, > > Am -1 on this. We just reached the point to (some

Re: [DISCUSS] Speed up release process?

As I wrote, we did have examples of changes + cascading, it is okay. But I don't agree with your statement about the board, as they themselves state "should" not "must" for 72h. If it does not cut with them, they should modify the refd page(s). And it's not "we're impatient" either, part of the r

Re: [DISCUSS] Speed up release process?

Which developers have to pause what activities? From previous discussions elsewhere, I’m strongly of the opinion that < 72 hr release votes are intended only for emergency security fixes and similar events, and that “we’re impatient” isn’t going to cut it with the board. It certainly wouldn’t

Re: [DISCUSS] Speed up release process?

David, I just meant that there is a "forced pause" of 72h. T On Fri, Nov 18, 2022 at 7:50 PM David Jencks wrote: > +1 from the sidelines. > > I don’t understand > >>>* current process causes (forced) context switching, and can likely > lead to > human mistakes: when the release vote is announc

Re: [DISCUSS] Speed up release process?

Howdy, I think you got it a bit "upside down": it is not a project that "cares" for people (this is not a corp), it is the other way around. As for key people, they should be "key" for a reason, I trust they care, so I am pretty much sure "key people" will be present when needed (they usually are)

Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

Errata: NOT imports, but rather "named capabilities". So now, I'd not let plugins fiddle with imports, but would rather "group" and name elements of extensions.xml On Fri, Nov 18, 2022 at 7:53 PM Tamás Cservenák wrote: > Now imports. But somewhat "named capabilities". Most of the plugins (vast >

Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

Now imports. But somewhat "named capabilities". Most of the plugins (vast majority) would use the default of "*" (give me whatever you have). If I look at this file: https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml I see "capabilities" like: -

Re: [DISCUSS] Speed up release process?

+1 from the sidelines. I don’t understand >>>* current process causes (forced) context switching, and can likely lead to human mistakes: when the release vote is announced, developer is FORCED to stop for 72h and possibly switch. This is just a productivity killer. <<< Who is forced to do anythin

Re: [DISCUSS] Speed up release process?

Hi Tamás, Is 3 days that bothering - didnt spot it to be honest? Indeed, strictly speaking you can do "until we get 3 bindings +1" - don't think you can say for a maximum otherwise it means you need to cancel if you don't get it ;) - but it also means you mean the project does not care about its c

Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

Guess if you start to enable imports of components outside the API all the API work done for m4 disappear and you get back in current state, ie a mojo is not able to know what it can rely on from maven until we create an enum and it would be we put jsr330 (note this one does not mean much since the

Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

Howdy, just to describe a bit what I meant under "reversed flag": default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today. Plugin classrealm gets (from memory, might be incomplete or wrong): - m4 API - m3 "plugin-api" - javax.inject - resolver api - etc as today consider that MAN

[DISCUSS] Speed up release process?

Howdy, My pet peeve these days is our release process. IMHO, we should be able to release ("move") much faster than today. My proposal would be: * vote is "done done" the moment quorum is reached * change the wording in the vote email from "Vote open for at least 72 hours." to "Vote open for a ma

[GitHub] [maven-shared-incremental] dependabot[bot] closed pull request #14: Bump slf4j-api from 1.7.36 to 2.0.3

dependabot[bot] closed pull request #14: Bump slf4j-api from 1.7.36 to 2.0.3 URL: https://github.com/apache/maven-shared-incremental/pull/14 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specif

[GitHub] [maven-shared-incremental] dependabot[bot] commented on pull request #14: Bump slf4j-api from 1.7.36 to 2.0.3

dependabot[bot] commented on PR #14: URL: https://github.com/apache/maven-shared-incremental/pull/14#issuecomment-1320341034 Superseded by #15. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to th

[GitHub] [maven-shared-incremental] dependabot[bot] opened a new pull request, #15: Bump slf4j-api from 1.7.36 to 2.0.4

dependabot[bot] opened a new pull request, #15: URL: https://github.com/apache/maven-shared-incremental/pull/15 Bumps [slf4j-api](https://github.com/qos-ch/slf4j) from 1.7.36 to 2.0.4. Commits https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2";>35dd

Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

Howdy, Am -1 on this. We just reached the point to (somewhat) undo the "Maven downloads the whole world", at least latest plugins by putting Maven and friends in provided scope will not download dozens of versions of maven-core and friends... If we do this, at one point we would end up with plugin

Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)

Following up on my previous response, and in a more realistic way than switching to OSGi, I wonder if we should let maven 4 plugins do their own DI injection and only care about the mojos, i.e. not rely on sisu/plexus to create and inject the mojo. Mojos using the v4 api do not need to be injected

Re: Surefire plain text reports

Please don't. I totally use that and expect them to be there without any extra markup or systems. Plain text, FTW. On Fri, Nov 18, 2022 at 8:23 AM Slawomir Jaranowski wrote: > > Hi, > > By default Surefire generate plain text reports which is stored in > target/surefire-reports/yourTestName.txt >

Re: Surefire plain text reports

Le ven. 18 nov. 2022 à 09:39, Slawomir Jaranowski a écrit : > pt., 18 lis 2022 o 09:24 Romain Manni-Bucau > napisał(a): > > > +1 to switch it off by default (but keep the feature since it can help > > investigations on CI) > > > > > Text reports contain exactly the same information that is displ

Re: Surefire plain text reports

pt., 18 lis 2022 o 09:24 Romain Manni-Bucau napisał(a): > +1 to switch it off by default (but keep the feature since it can help > investigations on CI) > Text reports contain exactly the same information that is displayed during build on console, so you should have it in logs from CI. Addition

Re: Surefire plain text reports

+1 to switch it off by default (but keep the feature since it can help investigations on CI) Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | Linke

Surefire plain text reports

Hi, By default Surefire generate plain text reports which is stored in target/surefire-reports/yourTestName.txt It can be disabled by using the "useFile" parameter. Question - Does somebody use such reports? I'm thinking about removing those at all and saving some CO2 :-) What do you think? --

Re: Maven 3 API, backwards compatibility

Le mer. 16 nov. 2022, 10:20, Konrad Windszus a écrit : > Hi, > Unfortunately Maven 3 didn’t define a proper API. In effect everything > somehow exposed through class loaders was considered API by > plugin/extension developers. > For Maven 4 a completely separate API was established in package > “

Re: Maven 3 API, backwards compatibility

Le ven. 18 nov. 2022 à 08:57, Christoph Läubrich a écrit : > > I fully understand the "under the hood" idea but once again, > > classrealm usage in maven is a tree which is very close to a flat > > classpath behavior whereas OSGi is a graph requiring all libs to have > > metadata - > > This i