date:20221118

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 branches and release from them.  But we do usually work
with PRs, so you can branch your PR from not the latest master and work
from that.
  * We could also (but I think this has been discussed) reduce the number
of git repos and always release things in batches, this could reduce the
friction.


Le ven. 18 nov. 2022 à 22:48, Tamás Cservenák  a
écrit :

> 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@blondie local (master %)]$ find * -type f -name "*.jar" | grep
> "org/apache" | wc -l
> 263
>
> In total, 308 JARs = 22176 hours = 924 days = 2,5 years.
>
> T
>
> On Fri, Nov 18, 2022 at 10:30 PM Tamás Cservenák 
> wrote:
>
> > 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 words (and am not trying to lessen their complexity or nor to
> > present Maven as something "special" here), most of ASF projects have
> few,
> > very few deliverables (again, I am talking about the majority, correct me
> > if I am wrong). Really, are there any statistics about:
> > - number of reposes used per ASF project
> > - number of different (!) artifact releases done per project?
> >
> > Maven on the other hand, while id DOES also have ONE "downloadable" item
> > on download page (https://maven.apache.org/download.cgi) we all know
> that
> > story does not end there: it is known to "download the whole internet",
> > just to run Maven "mvn clean verify" it will download zillion of plugins
> > and their dependant artifacts (and I did not even mention 3rd party, non
> > ASF plugins). So, Maven, as a "deliverable" or "product" is definitely
> not
> > one ZIP file you see on the download page. ASF Maven project has many
> > interconnected reposes/artifacts/releases.
> >
> > So, what I want to say: is it possible that ASF "way" works for "typical"
> > projects, while Maven is more like "atypical"?
> >
> > Or, to make my example more concrete:
> > 1. I checked out master of maven from http://github.com/apache/maven
> > 2. built it w/ pristine local repo
> > 3. and run some stats on it:
> > 4. https://gist.github.com/cstamas/ee2bba03f61d09fa3f5e9c57844207b7
> >
> > This simply means that for the end user, the "experience of ASF Maven" is
> > literally 1 (that on download page) + 233 = 234 releases. And it is all
> > very interconnected.
> >
> > Btw, I just downloaded 16848 hours :)
> >
> > T
> >
> > On Fri, Nov 18, 2022 at 9:53 PM David Jencks 
> > wrote:
> >
> >> 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
> >> 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 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 response for that
> is
> >> in
> >> > "hasty changes" canned response.
> >> >
> >> > Simply put:
> >> > - people see releases as a chore, as some "burden" that needs to be
> done
> >> > once in a while (see refd Slack messages in 1st mail), and when it
> >> comes to
> >> > be done, "let's do it when it's worth". We have MANY user questions on
> >> ML
> >> > of type "when is X released? As the issue [the user is interested in]
> is
> >> > fixed". And we have too many "dropped balls" in our court. IMHO,
> >> modifying
> >> > the process (to take less than 72+2h) is one step toward making
> release
> >> > less painful, less blocker.
> >> >
> >> > Fun fact: maven project consists of (not sure of exact count, just
> >> > guessing) 150+ repositories (GH on ASF org gives 153 when I type in
> >> > "maven-" in the repo search bar). This is a LOT. If we'd, for some
> >> reason,
> >> > start releasing all of those in 72h windows, it would be 10800 hours,
> or
> >> > 450 days, more than a year.
>

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 to 
anything?

This discussion looks to me like the others I’ve seen about shortening release 
votes: someone is basically complaining that the apache process is inconvenient 
for a particular subset of developers on a particular project, without 
examining what the actual roadblocks to effective development are or what other 
solutions might be possible.

In particular, I’d like to see an analysis of what would happen if a “release” 
was for a particular project plus all downstream changes needed to use it, 
whether as a single vote or as concurrent votes.

Thanks
David Jencks

> On Nov 18, 2022, at 1:48 PM, Tamás Cservenák  wrote:
> 
> 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@blondie local (master %)]$ find * -type f -name "*.jar" | grep
> "org/apache" | wc -l
> 263
> 
> In total, 308 JARs = 22176 hours = 924 days = 2,5 years.
> 
> T
> 
> On Fri, Nov 18, 2022 at 10:30 PM Tamás Cservenák 
> wrote:
> 
>> 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 words (and am not trying to lessen their complexity or nor to
>> present Maven as something "special" here), most of ASF projects have few,
>> very few deliverables (again, I am talking about the majority, correct me
>> if I am wrong). Really, are there any statistics about:
>> - number of reposes used per ASF project
>> - number of different (!) artifact releases done per project?
>> 
>> Maven on the other hand, while id DOES also have ONE "downloadable" item
>> on download page (https://maven.apache.org/download.cgi) we all know that
>> story does not end there: it is known to "download the whole internet",
>> just to run Maven "mvn clean verify" it will download zillion of plugins
>> and their dependant artifacts (and I did not even mention 3rd party, non
>> ASF plugins). So, Maven, as a "deliverable" or "product" is definitely not
>> one ZIP file you see on the download page. ASF Maven project has many
>> interconnected reposes/artifacts/releases.
>> 
>> So, what I want to say: is it possible that ASF "way" works for "typical"
>> projects, while Maven is more like "atypical"?
>> 
>> Or, to make my example more concrete:
>> 1. I checked out master of maven from http://github.com/apache/maven
>> 2. built it w/ pristine local repo
>> 3. and run some stats on it:
>> 4. https://gist.github.com/cstamas/ee2bba03f61d09fa3f5e9c57844207b7
>> 
>> This simply means that for the end user, the "experience of ASF Maven" is
>> literally 1 (that on download page) + 233 = 234 releases. And it is all
>> very interconnected.
>> 
>> Btw, I just downloaded 16848 hours :)
>> 
>> T
>> 
>> On Fri, Nov 18, 2022 at 9:53 PM David Jencks 
>> wrote:
>> 
>>> 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
>>> 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 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 response for that is
>>> in
 "hasty changes" canned response.
 
 Simply put:
 - people see releases as a chore, as some "burden" that needs to be done
 once in a while (see refd Slack messages in 1st mail), and when it
>>> comes to
 be done, "let's do it when it's worth". We have MANY user questions on
>>> ML
 of type "when is X released? As the issue [the user is interested in] is
 fixed". And we have too many "dropped balls" in our court. IMHO,
>>> modifying
 the process (to take less than 72+2h) is one step toward making release
 less painful, less blocker.
 
 Fun fact: maven project consists of (not sure of exact count, just
 guessing) 150+ repositories (GH on ASF org gives 153 when I type in
 "maven-" in

Re: [DISCUSS] Quo Vadis Maven Site

2022-11-18 Thread Hervé Boutemy

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

Having graphic people being able to do skins would be awesome, that's one of 
the benefits I see in Tamas proposal: I still need to understand how the other 
static generation tools manage the menu creation and overall "decoration" of 
the main content of a page

> - long time on build site is caused by multiple executing the same Maven
> phase for many reports [1]
true
thinking at "why": because the maven-site-plugin does the report goals 
invocation, it's not Maven core
that's one of the reasons why I love Tamas idea about having Maven generate 
"*-reports.jar" then the new site rending process just rendering to HTML

I don't like some words of Tamas on the topic, but there are also very good 
ideas that could halp a better new site generation architecture :)

> - some reports, like tests result, static code analize is not usable for
> static documentation - such reports should be generated by CI nowadays
as you know, I disagree: it is usable for some use cases, which are not the 
use cases you are interested in

> 
> [1] https://issues.apache.org/jira/browse/MSHARED-1044
> 
> śr., 16 lis 2022 o 11:19 Tamás Cservenák  napisał(a):
> > Howdy,
> > 
> > This is really just a brainstorming thread I'd like to spin, regarding
> > Maven Site stuff.
> > 
> > Again, the message is in wiki
> > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site
> > 
> > But I would like to make discussion happen here on dev ML.
> > 
> > Thanks
> > T





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Quo Vadis Maven Site

2022-11-18 Thread Hervé Boutemy

+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 a multi-module project
- and eventually on an aggregation of sites (seeing if it can scale to the 
Maven site itself)

Le mercredi 16 novembre 2022, 13:08:08 CET Elliotte Rusty Harold a écrit :
> I like some parts of this. I don't agree with others. I agree that
> maven site isn't competitive with other site builders, but that was
> never really its purpose. I think it's OK for generating  a site for a
> Maven project. I wouldn't expect it to be used for anything else. As a
> maintainer of one such site  it
> would be very inconvenient for me if this plugin disappeared or
> changed in a major way.
> 
> The old site design just works. We don't need so-called modern,
> responsive sites. For our purposes — documenting code — the 20 year
> old classic HTML we use is just fine. In fact, I'd say it's superior
> to modern designs as implemented in practice.
> 
> I do wish Maven hadn't gone its own way with NIH components like
> Plexus, APT, and Doxia that are all essentially used today by maven
> and no one else. However in fairness this all happened twenty years
> ago when alternatives that have become de facto standards was not
> obviously better or simply did not exist. We should modernize our
> dependencies where possible, but I don't think a rewrite is worth the
> effort and I would oppose anything that broke existing sites, links,
> and workflows.
> 
> When counting "wasted engineering hours spent on it", these are at
> least a couple of orders of magnitude lower than would be spent on a
> radical replacement of the sort being proposed. It's like proposing we
> build a new Lamborghini to save the money we spend on oil changes for
> our 2002 Ford pickup. Of course this is open source, so if anyone has
> the time and money to spend  on an alternative site plugin that
> scratches their itch, by all means they can do it. However this should
> be a new plugin projects can adopt or not at a time that's convenient
> for them. It should not replace the existing plugin so many projects
> already use.
> 
> On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák  wrote:
> > Howdy,
> > 
> > This is really just a brainstorming thread I'd like to spin, regarding
> > Maven Site stuff.
> > 
> > Again, the message is in wiki
> > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site
> > 
> > But I would like to make discussion happen here on dev ML.
> > 
> > Thanks
> > T





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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 temporary directory is shared between all users on most unix-like
systems (not MacOS, or Windows). Thus, code interacting with the system
temporary directory must be careful about file interactions in this directory,
and must ensure that the correct file posix permissions are set.

This PR was generated because a call to `File.createTempFile(..)` was
detected in this repository in a way that makes this project vulnerable to
local information disclosure.
With the default uname configuration, `File.createTempFile(..)` creates a
file with the permissions `-rw-r--r--`. This means that any other user on the
system can read the contents of this file.

### Impact

Information in this file is visible to other local users, allowing a
malicious actor co-resident on the same machine to view potentially sensitive
files.

Other Examples

- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) -
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) -
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) -
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) -
netty/netty

# The Fix

The fix has been to convert the logic above to use the following API that
was introduced in Java 1.7.

```java
File tmpDir = Files.createTempFile("temp dir").toFile();
```

The API both creates the file securely, ie. with a random, non-conflicting
name, with file permissions that only allow the currently executing user to
read or write the contents of this file.
By default, `Files.createTempFile("temp dir")` will create a file with the
permissions `-rw---`, which only allows the user that created the file to
view/write the file contents.

# :arrow_right: Vulnerability Disclosure :arrow_left:

:wave: Vulnerability disclosure is a super important part of the
vulnerability handling process and should not be skipped! This may be
completely new to you, and that's okay, I'm here to assist!

First question, do we need to perform vulnerability disclosure? It depends!

1. Is the vulnerable code only in tests or example code? No disclosure
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability
disclosure is probably required!

## Vulnerability Disclosure How-To

You have a few options options to perform vulnerability disclosure. However,
I'd like to suggest the following 2 options:

1. Request a CVE number from GitHub by creating a repository-level [GitHub
Security
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
This has the advantage that, if you provide sufficient information, GitHub
will automatically generate Dependabot alerts for your downstream consumers,
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).

## Detecting this and Future Vulnerabilities

This vulnerability was automatically detected by GitHub's CodeQL using this
[CodeQL
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).

You can automatically detect future vulnerabilities like this by enabling
the free (for open-source) [GitHub
Action](https://github.com/github/codeql-action).

I'm not an employee of GitHub, I'm simply an open-source security researcher.

## Source

This contribution was automatically generated with an
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to
bring this security fix to your repository.

The source code that generated this PR can be found here:

[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)

## Opting-Out

If you'd like to opt-out of future automated security vulnerability fixes
like this, please consider adding a file called
`.github/GH-ROBOTS.txt` to your repository with the line:

```
User-agent: JLLeitschuh/security-research
Disallow: *
```

This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt)
format for future contributions.

Alternatively, if this project is no longer actively maintained, consider
[archiving](https://help.github.com/en/github/creating-cloning-an

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@blondie local (master %)]$ find * -type f -name "*.jar" | grep
"org/apache" | wc -l
263

In total, 308 JARs = 22176 hours = 924 days = 2,5 years.

T

On Fri, Nov 18, 2022 at 10:30 PM Tamás Cservenák 
wrote:

> 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 words (and am not trying to lessen their complexity or nor to
> present Maven as something "special" here), most of ASF projects have few,
> very few deliverables (again, I am talking about the majority, correct me
> if I am wrong). Really, are there any statistics about:
> - number of reposes used per ASF project
> - number of different (!) artifact releases done per project?
>
> Maven on the other hand, while id DOES also have ONE "downloadable" item
> on download page (https://maven.apache.org/download.cgi) we all know that
> story does not end there: it is known to "download the whole internet",
> just to run Maven "mvn clean verify" it will download zillion of plugins
> and their dependant artifacts (and I did not even mention 3rd party, non
> ASF plugins). So, Maven, as a "deliverable" or "product" is definitely not
> one ZIP file you see on the download page. ASF Maven project has many
> interconnected reposes/artifacts/releases.
>
> So, what I want to say: is it possible that ASF "way" works for "typical"
> projects, while Maven is more like "atypical"?
>
> Or, to make my example more concrete:
> 1. I checked out master of maven from http://github.com/apache/maven
> 2. built it w/ pristine local repo
> 3. and run some stats on it:
> 4. https://gist.github.com/cstamas/ee2bba03f61d09fa3f5e9c57844207b7
>
> This simply means that for the end user, the "experience of ASF Maven" is
> literally 1 (that on download page) + 233 = 234 releases. And it is all
> very interconnected.
>
> Btw, I just downloaded 16848 hours :)
>
> T
>
> On Fri, Nov 18, 2022 at 9:53 PM David Jencks 
> wrote:
>
>> 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
>> 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 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 response for that is
>> in
>> > "hasty changes" canned response.
>> >
>> > Simply put:
>> > - people see releases as a chore, as some "burden" that needs to be done
>> > once in a while (see refd Slack messages in 1st mail), and when it
>> comes to
>> > be done, "let's do it when it's worth". We have MANY user questions on
>> ML
>> > of type "when is X released? As the issue [the user is interested in] is
>> > fixed". And we have too many "dropped balls" in our court. IMHO,
>> modifying
>> > the process (to take less than 72+2h) is one step toward making release
>> > less painful, less blocker.
>> >
>> > Fun fact: maven project consists of (not sure of exact count, just
>> > guessing) 150+ repositories (GH on ASF org gives 153 when I type in
>> > "maven-" in the repo search bar). This is a LOT. If we'd, for some
>> reason,
>> > start releasing all of those in 72h windows, it would be 10800 hours, or
>> > 450 days, more than a year.
>> >
>> >
>> > On Fri, Nov 18, 2022 at 8:34 PM David Jencks 
>> > wrote:
>> >
>> >> 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 with me.
>> >>
>> >> How many of these annoyances would be eliminated by an easy way to
>> release
>> >> and vote on a set of changed artifacts + the cascading dependencies
>> all at
>> >> once?
>> >>
>> >> thanks
>> >> David Jencks
>> >>
>> >>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák 
>> >> wrote:
>> >>>
>> >>> David,
>> >>>
>> >>> I just meant that there is a "forced pause" of 72h.
>> >>>
>> >>> T
>> >>>
>> >>> On Fri, Nov 18, 2022 at 7:50 PM David Jenc

Re: [DISCUSS] Speed up release process?

2022-11-18 Thread Manfred Moser


+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 as well.

Manfred

On 2022-11-18 9:55 a.m., Tamás Cservenák wrote:

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 maximum of 72 hours.".

Reasoning:
* vote cannot be vetoed by definition (only release mgr can cancel it).
* change would not conflict with ASF defined rules, the 72h is not
compulsory (document states "should" not "must").
* the release process is already wearisome, complex, and is easy to miss
(over-represented) manual steps. For example yesterday for some reason it
took almost 2 hours to sync release artifacts to Maven Central, during
which you are in a "busy loop" (the announcement and site depends on sync).
Leaving it "for tomorrow" may cause users to learn about a new release thru
Artifact Listener or whatever other service, causing confusion. Ideally,
site and announcement mail should be tied to sync, and that does lead to
"busy loop".
* 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.
* which part do you like: as a developer sitting on needles while being
blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
* we already agreed on one minor process improvement: we have quite long
"chains" of dependencies, so a bugfix that can span on long trails could
take weeks to be done serially, even if the bugfix itself is trivial. Hence
we did accept that we can do "batch votes" (release together) and can do
one vote for this case.
* on positive site this could lead to mindset change of bugfix releases, as
today, few wants to go thru painful release process for "single simple
change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
wrong: we all should release early and often. And be happy with it, not
feel it like chores :)

Finally some "canned responses":
* "time is needed for all interested parties to review": If someone cannot
get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
does not matter, as release is to happen anyway (unless release mgr cancels
it). One not getting to it, will be notified via mails anyway (vote,
result, announce). We can already observe that there are "areas of
interests", but also there is the customary habit of "review invitation"
which is a good thing IMHO, as usually one invites a colleague with whom
the topic was or is under discussion already, so both of them are
"contextualized". Those initiated developers will most probably join in
voting for release as well, as either they depend on the fix or they know
what the problem was.
* "this will lead to more bugs" or "we are too hasty making changes": no,
it will not and we are not. As in essence, this change would allow us, in
case of need, to release even multiple times per day (so release the
project carrying a bug in the morning, then have a patch release for it in
the afternoon). Really, as bugs are inevitable, they happen with or without
72 hours, still the current process just causes problems IMHO. As the new
release is sitting on Central, without immediate remediation possibility.
Or to put it another way, having this option open does not mean we will
make all releases like it, and we will not start competing by releasing all
the plugins several times a day :) You can see there are "hot spots'' (if
you look at maveniverse as whole, sometimes plugins, sometimes shared
stuff, sometime maven, etc), especially with closing releases of Maven, but
those hotspots come and go, move, and just like today, some components will
not be released for quite some time, as the hotspots move from here to
there.

Applying this process change, if accepted, would not alter anything
regarding "commit policy" of code changes (PRs, JIRA attached patches, etc).

Refs:
https://www.apache.org/foundation/voting.html
https://www.apache.org/legal/release-policy.html

Please comment, add your opinion. Ideally, if discussion closes with
"positive outcome", I would like to propose a vote for these changes.

Thanks
T



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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 words (and am not trying to lessen their complexity or nor to
present Maven as something "special" here), most of ASF projects have few,
very few deliverables (again, I am talking about the majority, correct me
if I am wrong). Really, are there any statistics about:
- number of reposes used per ASF project
- number of different (!) artifact releases done per project?

Maven on the other hand, while id DOES also have ONE "downloadable" item on
download page (https://maven.apache.org/download.cgi) we all know that
story does not end there: it is known to "download the whole internet",
just to run Maven "mvn clean verify" it will download zillion of plugins
and their dependant artifacts (and I did not even mention 3rd party, non
ASF plugins). So, Maven, as a "deliverable" or "product" is definitely not
one ZIP file you see on the download page. ASF Maven project has many
interconnected reposes/artifacts/releases.

So, what I want to say: is it possible that ASF "way" works for "typical"
projects, while Maven is more like "atypical"?

Or, to make my example more concrete:
1. I checked out master of maven from http://github.com/apache/maven
2. built it w/ pristine local repo
3. and run some stats on it:
4. https://gist.github.com/cstamas/ee2bba03f61d09fa3f5e9c57844207b7

This simply means that for the end user, the "experience of ASF Maven" is
literally 1 (that on download page) + 233 = 234 releases. And it is all
very interconnected.

Btw, I just downloaded 16848 hours :)

T

On Fri, Nov 18, 2022 at 9:53 PM David Jencks 
wrote:

> 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
> 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 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 response for that is
> in
> > "hasty changes" canned response.
> >
> > Simply put:
> > - people see releases as a chore, as some "burden" that needs to be done
> > once in a while (see refd Slack messages in 1st mail), and when it comes
> to
> > be done, "let's do it when it's worth". We have MANY user questions on ML
> > of type "when is X released? As the issue [the user is interested in] is
> > fixed". And we have too many "dropped balls" in our court. IMHO,
> modifying
> > the process (to take less than 72+2h) is one step toward making release
> > less painful, less blocker.
> >
> > Fun fact: maven project consists of (not sure of exact count, just
> > guessing) 150+ repositories (GH on ASF org gives 153 when I type in
> > "maven-" in the repo search bar). This is a LOT. If we'd, for some
> reason,
> > start releasing all of those in 72h windows, it would be 10800 hours, or
> > 450 days, more than a year.
> >
> >
> > On Fri, Nov 18, 2022 at 8:34 PM David Jencks 
> > wrote:
> >
> >> 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 with me.
> >>
> >> How many of these annoyances would be eliminated by an easy way to
> release
> >> and vote on a set of changed artifacts + the cascading dependencies all
> at
> >> once?
> >>
> >> thanks
> >> David Jencks
> >>
> >>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák 
> >> wrote:
> >>>
> >>> 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 announced, developer is
> FORCED
> >> to
>  stop for 72h and possibly switch. This is just a productivity killer.
>  <<<
>  Who is forced to do anything and for what reason?
> 
> 
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
>
> --

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 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 response for that is in
> "hasty changes" canned response.
> 
> Simply put:
> - people see releases as a chore, as some "burden" that needs to be done
> once in a while (see refd Slack messages in 1st mail), and when it comes to
> be done, "let's do it when it's worth". We have MANY user questions on ML
> of type "when is X released? As the issue [the user is interested in] is
> fixed". And we have too many "dropped balls" in our court. IMHO, modifying
> the process (to take less than 72+2h) is one step toward making release
> less painful, less blocker.
> 
> Fun fact: maven project consists of (not sure of exact count, just
> guessing) 150+ repositories (GH on ASF org gives 153 when I type in
> "maven-" in the repo search bar). This is a LOT. If we'd, for some reason,
> start releasing all of those in 72h windows, it would be 10800 hours, or
> 450 days, more than a year.
> 
> 
> On Fri, Nov 18, 2022 at 8:34 PM David Jencks 
> wrote:
> 
>> 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 with me.
>> 
>> How many of these annoyances would be eliminated by an easy way to release
>> and vote on a set of changed artifacts + the cascading dependencies all at
>> once?
>> 
>> thanks
>> David Jencks
>> 
>>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák 
>> wrote:
>>> 
>>> 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 announced, developer is FORCED
>> to
 stop for 72h and possibly switch. This is just a productivity killer.
 <<<
 Who is forced to do anything and for what reason?
 
 
>> 
>> 
>> -
>> 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] 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 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 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 response for that is in
> "hasty changes" canned response.
> 
> Simply put:
> - people see releases as a chore, as some "burden" that needs to be done
> once in a while (see refd Slack messages in 1st mail), and when it comes to
> be done, "let's do it when it's worth". We have MANY user questions on ML
> of type "when is X released? As the issue [the user is interested in] is
> fixed". And we have too many "dropped balls" in our court. IMHO, modifying
> the process (to take less than 72+2h) is one step toward making release
> less painful, less blocker.
> 
> Fun fact: maven project consists of (not sure of exact count, just
> guessing) 150+ repositories (GH on ASF org gives 153 when I type in
> "maven-" in the repo search bar). This is a LOT. If we'd, for some reason,
> start releasing all of those in 72h windows, it would be 10800 hours, or
> 450 days, more than a year.
> 
> 
> On Fri, Nov 18, 2022 at 8:34 PM David Jencks 
> wrote:
> 
>> 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 with me.
>> 
>> How many of these annoyances would be eliminated by an easy way to release
>> and vote on a set of changed artifacts + the cascading dependencies all at
>> once?
>> 
>> thanks
>> David Jencks
>> 
>>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák 
>> wrote:
>>> 
>>> 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 announced, developer is FORCED
>> to
 stop for 72h and possibly switch. This is just a productivity killer.
 <<<
 Who is forced to do anything and for what reason?
 
 
>> 
>> 
>> -
>> 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

[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 message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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 specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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 above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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 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 response for that is in
> "hasty changes" canned response.
> 
> Simply put:
> - people see releases as a chore, as some "burden" that needs to be done
> once in a while (see refd Slack messages in 1st mail), and when it comes to
> be done, "let's do it when it's worth". We have MANY user questions on ML
> of type "when is X released? As the issue [the user is interested in] is
> fixed". And we have too many "dropped balls" in our court. IMHO, modifying
> the process (to take less than 72+2h) is one step toward making release
> less painful, less blocker.
> 
> Fun fact: maven project consists of (not sure of exact count, just
> guessing) 150+ repositories (GH on ASF org gives 153 when I type in
> "maven-" in the repo search bar). This is a LOT. If we'd, for some reason,
> start releasing all of those in 72h windows, it would be 10800 hours, or
> 450 days, more than a year.
> 
> 
> On Fri, Nov 18, 2022 at 8:34 PM David Jencks 
> wrote:
> 
>> 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 with me.
>> 
>> How many of these annoyances would be eliminated by an easy way to release
>> and vote on a set of changed artifacts + the cascading dependencies all at
>> once?
>> 
>> thanks
>> David Jencks
>> 
>>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák 
>> wrote:
>>> 
>>> 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 announced, developer is FORCED
>> to
 stop for 72h and possibly switch. This is just a productivity killer.
 <<<
 Who is forced to do anything and for what reason?
 
 
>> 
>> 
>> -
>> 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: 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 simple
(compared to sisu/plexus) DI that would support jakarta.inject package (the
javax.inject package being deprecated) or maybe even better,  maven's own
annotations which would then be part of the maven4 API.  This could be a
pure Guice container, a simple adhoc framework, or whatever.  We just need
to clearly define that API. The goal is to isolate plugins from any maven
service and get rid of the sisu additional complexity with realms,
descriptors and such.
And for  maven4 plugin class loaders, I think we should only expose the
maven4 API + the DI package if we don't use our own.


Le ven. 18 nov. 2022, 21:26, Tamás Cservenák  a écrit :

> 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 all
> of javax.inject, does it?
> For me the two are somehow connected => "capabilities"
>
> T
>
> On Fri, Nov 18, 2022 at 8:59 PM Guillaume Nodet  wrote:
>
> > 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 (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
> > > plugins downloading dozens of DI container (or their versions), as even
> > ASF
> > > plugins would not be in "lockstep".
> > >
> > > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> > that
> > > would say maven "I will be in charge of my components" (defaults to
> > false,
> > > Maven behaves as today). When true, it would mean Mojo wants to
> > > bootstrap some DI/whatever container of its own, and then, for plugins
> > like
> > > these, Maven could even "narrow" the list of exported classes? (like
> > > javax.inject?)
> > >
> > > T
> > >
> > > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet 
> > wrote:
> > >
> > > > 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 with other components from maven, they should all come from
> > the
> > > > api and should be retrieved using Session.getService(xx), or simply
> > using
> > > > session's shortcut methods.  The injection of Project and Session is
> > not
> > > > controlled by sisu. For the ComponentConfigurator, we could change
> the
> > > mojo
> > > > descriptor to have the full configuration class name for mojos that
> > > require
> > > > custom configuration injection, the plugin manager being in charge of
> > > > instantiating this class and using it as a ComponentConfigurator
> (which
> > > is
> > > > not part yet of the api btw).
> > > >
> > > > Complex plugins which rely on plexus/sisu to do some custom injection
> > > would
> > > > have to be changed to do their own DI, maybe using a simple Guice
> > setup.
> > > >
> > > > If that sounds like too big a change for those plugins, we may be
> able
> > to
> > > > add a flag on the mojo descriptor so that those v4-enabled mojos
> would
> > > > trigger a DI injection on behalf of the plugin.  But if we have to
> > > > implement something like that, I would go for a plain CDI-like api,
> > > either
> > > > using guice or another DI library supporting the javax.inject
> package,
> > or
> > > > rather the jakarta.inject package, as it would be nice to switch to
> the
> > > > jakarta version at the same time.  Or maybe even plexus if we really
> > need
> > > > to, but with a limited scope, i.e. no visibility on the maven
> > components,
> > > > so that plugins are better decoupled from maven-core.
> > > >
> > > > Thoughts ?
> > > >
> > > > Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet  a
> > > écrit
> > > > :
> > > >
> > > > > I do agree that debugging the provisioning side is *very*
> complicated
> > > > when
> > > > > there's a problem.
> > > > > I'd be happy to get rid of sisu/plexus and use a more simple DI
> > > > framework,
> > > > > at least for simple plugins.
> > > > > However, I definitely don't th

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 for at
least 72+2h (actually more, as _during_ release preparation they would
start breaking, not only during vote). So, thank you, but no, thank you :D

Strange, that you say "no user complained of waiting". From where did you
source this information, or from where can you support this claim?

Just as an example, complaints on Slack do happen, quite often and
regularly.

T



On Fri, Nov 18, 2022 at 9:19 PM Romain Manni-Bucau 
wrote:

> 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 releasing 150+ projects can be done in72h ;).
>
> It is done with success at apache by multiple projects and respects the
> core of our foundation, human beings.
>
> Now no user complained of waiting for 72h and if we are good enough in
> votes it is the needed time so think the issue you want to tackle is
> elsewhere, really.
>
> Le ven. 18 nov. 2022 à 20:55, Tamás Cservenák  a
> écrit :
>
> > 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 response for that is
> in
> > "hasty changes" canned response.
> >
> > Simply put:
> > - people see releases as a chore, as some "burden" that needs to be done
> > once in a while (see refd Slack messages in 1st mail), and when it comes
> to
> > be done, "let's do it when it's worth". We have MANY user questions on ML
> > of type "when is X released? As the issue [the user is interested in] is
> > fixed". And we have too many "dropped balls" in our court. IMHO,
> modifying
> > the process (to take less than 72+2h) is one step toward making release
> > less painful, less blocker.
> >
> > Fun fact: maven project consists of (not sure of exact count, just
> > guessing) 150+ repositories (GH on ASF org gives 153 when I type in
> > "maven-" in the repo search bar). This is a LOT. If we'd, for some
> reason,
> > start releasing all of those in 72h windows, it would be 10800 hours, or
> > 450 days, more than a year.
> >
> >
> > On Fri, Nov 18, 2022 at 8:34 PM David Jencks 
> > wrote:
> >
> > > 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 with me.
> > >
> > > How many of these annoyances would be eliminated by an easy way to
> > release
> > > and vote on a set of changed artifacts + the cascading dependencies all
> > at
> > > once?
> > >
> > > thanks
> > > David Jencks
> > >
> > > > On Nov 18, 2022, at 11:17 AM, Tamás Cservenák 
> > > wrote:
> > > >
> > > > David,
> > > >
> > > > I just meant that there is a "forced pause" of 72h.
> > > >
> > > > T
> > > >
> > > > On Fri, Nov 18, 2022 at 7:50 PM David Jencks <
> david.a.jen...@gmail.com
> > >
> > > > 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 announced, developer is
> > FORCED
> > > to
> > > >> stop for 72h and possibly switch. This is just a productivity
> killer.
> > > >> <<<
> > > >> Who is forced to do anything and for what reason?
> > > >>
> > > >>
> > >
> > >
> > > -
> > > 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)

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 all
of javax.inject, does it?
For me the two are somehow connected => "capabilities"

T

On Fri, Nov 18, 2022 at 8:59 PM Guillaume Nodet  wrote:

> 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 (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
> > plugins downloading dozens of DI container (or their versions), as even
> ASF
> > plugins would not be in "lockstep".
> >
> > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> that
> > would say maven "I will be in charge of my components" (defaults to
> false,
> > Maven behaves as today). When true, it would mean Mojo wants to
> > bootstrap some DI/whatever container of its own, and then, for plugins
> like
> > these, Maven could even "narrow" the list of exported classes? (like
> > javax.inject?)
> >
> > T
> >
> > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet 
> wrote:
> >
> > > 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 with other components from maven, they should all come from
> the
> > > api and should be retrieved using Session.getService(xx), or simply
> using
> > > session's shortcut methods.  The injection of Project and Session is
> not
> > > controlled by sisu. For the ComponentConfigurator, we could change the
> > mojo
> > > descriptor to have the full configuration class name for mojos that
> > require
> > > custom configuration injection, the plugin manager being in charge of
> > > instantiating this class and using it as a ComponentConfigurator (which
> > is
> > > not part yet of the api btw).
> > >
> > > Complex plugins which rely on plexus/sisu to do some custom injection
> > would
> > > have to be changed to do their own DI, maybe using a simple Guice
> setup.
> > >
> > > If that sounds like too big a change for those plugins, we may be able
> to
> > > add a flag on the mojo descriptor so that those v4-enabled mojos would
> > > trigger a DI injection on behalf of the plugin.  But if we have to
> > > implement something like that, I would go for a plain CDI-like api,
> > either
> > > using guice or another DI library supporting the javax.inject package,
> or
> > > rather the jakarta.inject package, as it would be nice to switch to the
> > > jakarta version at the same time.  Or maybe even plexus if we really
> need
> > > to, but with a limited scope, i.e. no visibility on the maven
> components,
> > > so that plugins are better decoupled from maven-core.
> > >
> > > Thoughts ?
> > >
> > > Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet  a
> > écrit
> > > :
> > >
> > > > I do agree that debugging the provisioning side is *very* complicated
> > > when
> > > > there's a problem.
> > > > I'd be happy to get rid of sisu/plexus and use a more simple DI
> > > framework,
> > > > at least for simple plugins.
> > > > However, I definitely don't think pushing OSGi to plugins would be a
> > good
> > > > idea : the cost and burden on plugin developers would outweigh the
> > > benefits.
> > > >
> > > > For extensions, and for maven itself, that is a different story
> though.
> > > > Maven and extensions could definitely benefit from OSGi, but this
> would
> > > be
> > > > a complete breakage and it would be hard to keep some level of
> > > > compatibility.
> > > >
> > > > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> m...@laeubi-soft.de>
> > a
> > > > écrit :
> > > >
> > > >>  > Guess classrealm is fine for maven, it does not bring much issues
> > > >>
> > > >> As long as it works, maybe, maybe even if you write a simple maven
> > > >> plugin, but for any more complex it is just a complete mess.
> > > >>
> > > >> Last time I asked on the mailing list how to debug that stuff ...
> > > >> complete silence ...
> > > >>
> > > >> Today I tried to refactor the name of one module of a more complex
> > > >> maven-plugin (with core extension), now I end up with
> > > >>
> > > >> org.apache.maven.InternalErrorException: Internal error:
> > > >> com.google.inject.ProvisionException: Unable to provision,

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 releasing 150+ projects can be done in72h ;).

It is done with success at apache by multiple projects and respects the
core of our foundation, human beings.

Now no user complained of waiting for 72h and if we are good enough in
votes it is the needed time so think the issue you want to tackle is
elsewhere, really.

Le ven. 18 nov. 2022 à 20:55, Tamás Cservenák  a
écrit :

> 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 response for that is in
> "hasty changes" canned response.
>
> Simply put:
> - people see releases as a chore, as some "burden" that needs to be done
> once in a while (see refd Slack messages in 1st mail), and when it comes to
> be done, "let's do it when it's worth". We have MANY user questions on ML
> of type "when is X released? As the issue [the user is interested in] is
> fixed". And we have too many "dropped balls" in our court. IMHO, modifying
> the process (to take less than 72+2h) is one step toward making release
> less painful, less blocker.
>
> Fun fact: maven project consists of (not sure of exact count, just
> guessing) 150+ repositories (GH on ASF org gives 153 when I type in
> "maven-" in the repo search bar). This is a LOT. If we'd, for some reason,
> start releasing all of those in 72h windows, it would be 10800 hours, or
> 450 days, more than a year.
>
>
> On Fri, Nov 18, 2022 at 8:34 PM David Jencks 
> wrote:
>
> > 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 with me.
> >
> > How many of these annoyances would be eliminated by an easy way to
> release
> > and vote on a set of changed artifacts + the cascading dependencies all
> at
> > once?
> >
> > thanks
> > David Jencks
> >
> > > On Nov 18, 2022, at 11:17 AM, Tamás Cservenák 
> > wrote:
> > >
> > > 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 announced, developer is
> FORCED
> > to
> > >> stop for 72h and possibly switch. This is just a productivity killer.
> > >> <<<
> > >> Who is forced to do anything and for what reason?
> > >>
> > >>
> >
> >
> > -
> > 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)

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 (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
> plugins downloading dozens of DI container (or their versions), as even ASF
> plugins would not be in "lockstep".
>
> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag that
> would say maven "I will be in charge of my components" (defaults to false,
> Maven behaves as today). When true, it would mean Mojo wants to
> bootstrap some DI/whatever container of its own, and then, for plugins like
> these, Maven could even "narrow" the list of exported classes? (like
> javax.inject?)
>
> T
>
> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet  wrote:
>
> > 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 with other components from maven, they should all come from the
> > api and should be retrieved using Session.getService(xx), or simply using
> > session's shortcut methods.  The injection of Project and Session is not
> > controlled by sisu. For the ComponentConfigurator, we could change the
> mojo
> > descriptor to have the full configuration class name for mojos that
> require
> > custom configuration injection, the plugin manager being in charge of
> > instantiating this class and using it as a ComponentConfigurator (which
> is
> > not part yet of the api btw).
> >
> > Complex plugins which rely on plexus/sisu to do some custom injection
> would
> > have to be changed to do their own DI, maybe using a simple Guice setup.
> >
> > If that sounds like too big a change for those plugins, we may be able to
> > add a flag on the mojo descriptor so that those v4-enabled mojos would
> > trigger a DI injection on behalf of the plugin.  But if we have to
> > implement something like that, I would go for a plain CDI-like api,
> either
> > using guice or another DI library supporting the javax.inject package, or
> > rather the jakarta.inject package, as it would be nice to switch to the
> > jakarta version at the same time.  Or maybe even plexus if we really need
> > to, but with a limited scope, i.e. no visibility on the maven components,
> > so that plugins are better decoupled from maven-core.
> >
> > Thoughts ?
> >
> > Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet  a
> écrit
> > :
> >
> > > I do agree that debugging the provisioning side is *very* complicated
> > when
> > > there's a problem.
> > > I'd be happy to get rid of sisu/plexus and use a more simple DI
> > framework,
> > > at least for simple plugins.
> > > However, I definitely don't think pushing OSGi to plugins would be a
> good
> > > idea : the cost and burden on plugin developers would outweigh the
> > benefits.
> > >
> > > For extensions, and for maven itself, that is a different story though.
> > > Maven and extensions could definitely benefit from OSGi, but this would
> > be
> > > a complete breakage and it would be hard to keep some level of
> > > compatibility.
> > >
> > > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich 
> a
> > > écrit :
> > >
> > >>  > Guess classrealm is fine for maven, it does not bring much issues
> > >>
> > >> As long as it works, maybe, maybe even if you write a simple maven
> > >> plugin, but for any more complex it is just a complete mess.
> > >>
> > >> Last time I asked on the mailing list how to debug that stuff ...
> > >> complete silence ...
> > >>
> > >> Today I tried to refactor the name of one module of a more complex
> > >> maven-plugin (with core extension), now I end up with
> > >>
> > >> org.apache.maven.InternalErrorException: Internal error:
> > >> com.google.inject.ProvisionException: Unable to provision, see the
> > >> following errors:
> > >> 1) No implementation for org.eclipse.aether.RepositorySystem was
> bound.
> > >>
> > >> A whole bunch of stack trace but not a little info why the * it is
> > >> not happy. Now I need to add random "exportedArtifact" /
> > >> "exportedPackage" stuff to hope finding out where it has lost a
> > >> transitive dependency, also here absolutely no documentation what this
> > >> is supposed to do/work exactly beside some introduction that these xml
> > >> tags exits and reading the code... or probably add maven-compat
> > >> anywhere... or change provided to compile scope (even maven is jelling
> > >> at me that's bad and I will be punished soon)... not co

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 response for that is in
"hasty changes" canned response.

Simply put:
- people see releases as a chore, as some "burden" that needs to be done
once in a while (see refd Slack messages in 1st mail), and when it comes to
be done, "let's do it when it's worth". We have MANY user questions on ML
of type "when is X released? As the issue [the user is interested in] is
fixed". And we have too many "dropped balls" in our court. IMHO, modifying
the process (to take less than 72+2h) is one step toward making release
less painful, less blocker.

Fun fact: maven project consists of (not sure of exact count, just
guessing) 150+ repositories (GH on ASF org gives 153 when I type in
"maven-" in the repo search bar). This is a LOT. If we'd, for some reason,
start releasing all of those in 72h windows, it would be 10800 hours, or
450 days, more than a year.


On Fri, Nov 18, 2022 at 8:34 PM David Jencks 
wrote:

> 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 with me.
>
> How many of these annoyances would be eliminated by an easy way to release
> and vote on a set of changed artifacts + the cascading dependencies all at
> once?
>
> thanks
> David Jencks
>
> > On Nov 18, 2022, at 11:17 AM, Tamás Cservenák 
> wrote:
> >
> > 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 announced, developer is FORCED
> to
> >> stop for 72h and possibly switch. This is just a productivity killer.
> >> <<<
> >> Who is forced to do anything and for what reason?
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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 with me.

How many of these annoyances would be eliminated by an easy way to release and 
vote on a set of changed artifacts + the cascading dependencies all at once?

thanks
David Jencks

> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák  wrote:
> 
> 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 announced, developer is FORCED to
>> stop for 72h and possibly switch. This is just a productivity killer.
>> <<<
>> Who is forced to do anything and for what reason?
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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 announced, developer is FORCED to
> stop for 72h and possibly switch. This is just a productivity killer.
> <<<
> Who is forced to do anything and for what reason?
>
>

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). On the other hand, if a PMC member decides to take a bus tour and
crashes, the fact he lies in a hospital (in gypsum with hanging limbs, like
in cartoons) does not mean he doesn't care, as he will not vote even after
72h (replace here child birth, hangover after a too successful party, or
whatever). And again, unsure what 3 days matter. Release process is already
HOURS (just sync is 2+), so let's make it AT LEAST 72h? It should be a push
of a button.

But I think I described where 72h does matter, in my 1st mail.

The answer to "it is a good thing to enable people to review a release and
have the opportunity to give feedback" is among canned responses :)


T

On Fri, Nov 18, 2022 at 7:44 PM Romain Manni-Bucau 
wrote:

> 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 core people - if you start the release on friday night you
> potentially let 0s to some PMC and users to review the release.
> Indeed it is ont an apache requirement but I think it is a good thing to
> enable people to review a release and have the opportunity to give feedback
> so 3 days sounds like a very good default if you take into account the
> world side - timezones - of our project.
>
> Side note: guess exceptions can be done for CVE, milestones, beta, alpha,
> ... - anything not final or urgent but very located.
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 18 nov. 2022 à 18:55, Tamás Cservenák  a
> écrit :
>
> > 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 maximum of 72 hours.".
> >
> > Reasoning:
> > * vote cannot be vetoed by definition (only release mgr can cancel it).
> > * change would not conflict with ASF defined rules, the 72h is not
> > compulsory (document states "should" not "must").
> > * the release process is already wearisome, complex, and is easy to miss
> > (over-represented) manual steps. For example yesterday for some reason it
> > took almost 2 hours to sync release artifacts to Maven Central, during
> > which you are in a "busy loop" (the announcement and site depends on
> sync).
> > Leaving it "for tomorrow" may cause users to learn about a new release
> thru
> > Artifact Listener or whatever other service, causing confusion. Ideally,
> > site and announcement mail should be tied to sync, and that does lead to
> > "busy loop".
> > * 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.
> > * which part do you like: as a developer sitting on needles while being
> > blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
> > * we already agreed on one minor process improvement: we have quite long
> > "chains" of dependencies, so a bugfix that can span on long trails could
> > take weeks to be done serially, even if the bugfix itself is trivial.
> Hence
> > we did accept that we can do "batch votes" (release together) and can do
> > one vote for this case.
> > * on positive site this could lead to mindset change of bugfix releases,
> as
> > today, few wants to go thru painful release process for "single simple
> > change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
> > wrong: we all should release early and often. And be happy with it, not
> > feel it like chores :)
> >
> > Finally some "canned responses":
> > * "time is needed for all interested parties to review": If someone
> cannot
> > get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
> > does not matter, as release is to happen anyway (unless release mgr
> cancels
> > it). One not getting to it, will be notified via mails anyway (vote,
> > result, announce). We can already observe that there are "areas of
> > interests", but also there is the customary

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
> 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:
> - m4 api
> - m3 api x
> - wagon x?
> - resolver x
> - classworlds x?
> - plexus-xml x? <- Guillaume?
> - plexus-container x
> - jsr330
> - jsr250
> - slf4j
> - jansi
>
> Note: in some future maven 4.5/5/whatever entries marked with "x" are
> gone. Those with "?" capabilities are unsure if I am right or not (that
> will be gone), Guillaume will chime in hopefully.
>
> The vast majority of plugins will not bother with these settings at all
> (will have default value of "*").
> Some may want to tune it, like not having jsr330 or slf4j, or purist
> plugins may ask only for "m4api".
>
> Point is (whether enum or not) is:
> if a plugin asks for capability that maven runtime does not have (for
> example m3api in maven 5) -> leads to breakage.
>
> ===
>
> BUT, I said this would be a "dream" :) Do not stick to it. Am completely
> fine with a flag as I described before.
>
> T
>
>
> On Fri, Nov 18, 2022 at 7:36 PM Romain Manni-Bucau 
> wrote:
>
>> 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
>> injected type will be the most important), slf4j are part of the API and
>> we
>> said we don't want that - for goods so sounds like we should stick to the
>> API respect IMHO and if needed promote some new API, no?
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le ven. 18 nov. 2022 à 19:11, Tamás Cservenák  a
>> écrit :
>>
>> > 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 MANY plugins have components, and creating components in
>> > MAJORITY of plugins is easy and should remain easy (and offered "out of
>> the
>> > box").
>> >
>> > but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin
>> realm
>> > that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
>> > plugin can do whatever it wants, but still has access to m4 API (that is
>> > heaven vs earth when compared to m3 state of affairs).
>> >
>> > ===
>> >
>> > in future, when we drop m3 support, this could mean:
>> >
>> > false (default)
>> > - m4 API
>> > - javax.inject
>> >
>> > true
>> > -m4 API
>> >
>> > ===
>> >
>> > Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
>> > values:
>> > - * <- plugin classrealm should have all "capabilities" current Maven
>> > runtime provides
>> > - m4api <- I want maven 4 api ONLY
>> > - m3api, slf4j, jsr330  <- I want to m3 api (would break in m4+ that
>> drops
>> > m3 backward compat), slf4j logging and would use jsr330 components
>> > "capability"
>> >
>> > But this is getting too wild maybe :)
>> >
>> >
>> > T
>> >
>> > On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák 
>> > wrote:
>> >
>> > > 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
>> > > plugins downloading dozens of DI container (or their versions), as
>> even
>> > ASF
>> > > plugins would not be in "lockstep".
>> > >
>> > > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
>> > > that would say maven "I will be in charge of my components" (defaults
>> to
>> > > false, Maven behaves as today). When true, it would mean Mojo wants to
>> > > bootstrap some DI/whatever container of its own, and then, for plugins
>> > like
>> > > these, Maven could even "narrow" the list of exported classes? (like
>> > > javax.inject?)
>> > >
>> > > T
>> > >
>> > > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet 
>> > wrote:
>>

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:
- m4 api
- m3 api x
- wagon x?
- resolver x
- classworlds x?
- plexus-xml x? <- Guillaume?
- plexus-container x
- jsr330
- jsr250
- slf4j
- jansi

Note: in some future maven 4.5/5/whatever entries marked with "x" are gone.
Those with "?" capabilities are unsure if I am right or not (that will be
gone), Guillaume will chime in hopefully.

The vast majority of plugins will not bother with these settings at all
(will have default value of "*").
Some may want to tune it, like not having jsr330 or slf4j, or purist
plugins may ask only for "m4api".

Point is (whether enum or not) is:
if a plugin asks for capability that maven runtime does not have (for
example m3api in maven 5) -> leads to breakage.

===

BUT, I said this would be a "dream" :) Do not stick to it. Am completely
fine with a flag as I described before.

T


On Fri, Nov 18, 2022 at 7:36 PM Romain Manni-Bucau 
wrote:

> 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
> injected type will be the most important), slf4j are part of the API and we
> said we don't want that - for goods so sounds like we should stick to the
> API respect IMHO and if needed promote some new API, no?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 18 nov. 2022 à 19:11, Tamás Cservenák  a
> écrit :
>
> > 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 MANY plugins have components, and creating components in
> > MAJORITY of plugins is easy and should remain easy (and offered "out of
> the
> > box").
> >
> > but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm
> > that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
> > plugin can do whatever it wants, but still has access to m4 API (that is
> > heaven vs earth when compared to m3 state of affairs).
> >
> > ===
> >
> > in future, when we drop m3 support, this could mean:
> >
> > false (default)
> > - m4 API
> > - javax.inject
> >
> > true
> > -m4 API
> >
> > ===
> >
> > Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
> > values:
> > - * <- plugin classrealm should have all "capabilities" current Maven
> > runtime provides
> > - m4api <- I want maven 4 api ONLY
> > - m3api, slf4j, jsr330  <- I want to m3 api (would break in m4+ that
> drops
> > m3 backward compat), slf4j logging and would use jsr330 components
> > "capability"
> >
> > But this is getting too wild maybe :)
> >
> >
> > T
> >
> > On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák 
> > wrote:
> >
> > > 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
> > > plugins downloading dozens of DI container (or their versions), as even
> > ASF
> > > plugins would not be in "lockstep".
> > >
> > > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> > > that would say maven "I will be in charge of my components" (defaults
> to
> > > false, Maven behaves as today). When true, it would mean Mojo wants to
> > > bootstrap some DI/whatever container of its own, and then, for plugins
> > like
> > > these, Maven could even "narrow" the list of exported classes? (like
> > > javax.inject?)
> > >
> > > T
> > >
> > > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet 
> > wrote:
> > >
> > >> 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 with other components from maven, they should all come from

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 anything and for what reason?

AFAIK cascading dependencies can be handled by releasing cause + all effects at 
once.  If that’s hard to do now, maybe there’s a way to make it easier. I’d 
expect it would make testing a change more plausible as well.

David Jencks

> On Nov 18, 2022, at 10:44 AM, Romain Manni-Bucau  
> wrote:
> 
> 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 core people - if you start the release on friday night you
> potentially let 0s to some PMC and users to review the release.
> Indeed it is ont an apache requirement but I think it is a good thing to
> enable people to review a release and have the opportunity to give feedback
> so 3 days sounds like a very good default if you take into account the
> world side - timezones - of our project.
> 
> Side note: guess exceptions can be done for CVE, milestones, beta, alpha,
> ... - anything not final or urgent but very located.
> 
> Hope it makes sense.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le ven. 18 nov. 2022 à 18:55, Tamás Cservenák  a
> écrit :
> 
>> 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 maximum of 72 hours.".
>> 
>> Reasoning:
>> * vote cannot be vetoed by definition (only release mgr can cancel it).
>> * change would not conflict with ASF defined rules, the 72h is not
>> compulsory (document states "should" not "must").
>> * the release process is already wearisome, complex, and is easy to miss
>> (over-represented) manual steps. For example yesterday for some reason it
>> took almost 2 hours to sync release artifacts to Maven Central, during
>> which you are in a "busy loop" (the announcement and site depends on sync).
>> Leaving it "for tomorrow" may cause users to learn about a new release thru
>> Artifact Listener or whatever other service, causing confusion. Ideally,
>> site and announcement mail should be tied to sync, and that does lead to
>> "busy loop".
>> * 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.
>> * which part do you like: as a developer sitting on needles while being
>> blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
>> * we already agreed on one minor process improvement: we have quite long
>> "chains" of dependencies, so a bugfix that can span on long trails could
>> take weeks to be done serially, even if the bugfix itself is trivial. Hence
>> we did accept that we can do "batch votes" (release together) and can do
>> one vote for this case.
>> * on positive site this could lead to mindset change of bugfix releases, as
>> today, few wants to go thru painful release process for "single simple
>> change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
>> wrong: we all should release early and often. And be happy with it, not
>> feel it like chores :)
>> 
>> Finally some "canned responses":
>> * "time is needed for all interested parties to review": If someone cannot
>> get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
>> does not matter, as release is to happen anyway (unless release mgr cancels
>> it). One not getting to it, will be notified via mails anyway (vote,
>> result, announce). We can already observe that there are "areas of
>> interests", but also there is the customary habit of "review invitation"
>> which is a good thing IMHO, as usually one invites a colleague with whom
>> the topic was or is under discussion already, so both of them are
>> "contextualized". Those initiated developers will most probably join in
>> voting for release as well, as either they depend on the fix or they know
>> what the problem was.
>> * "this will lead to more bugs" or "we are too hasty making changes": no,
>> it will not and we are not. As in e

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 core people - if you start the release on friday night you
potentially let 0s to some PMC and users to review the release.
Indeed it is ont an apache requirement but I think it is a good thing to
enable people to review a release and have the opportunity to give feedback
so 3 days sounds like a very good default if you take into account the
world side - timezones - of our project.

Side note: guess exceptions can be done for CVE, milestones, beta, alpha,
... - anything not final or urgent but very located.

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 18 nov. 2022 à 18:55, Tamás Cservenák  a
écrit :

> 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 maximum of 72 hours.".
>
> Reasoning:
> * vote cannot be vetoed by definition (only release mgr can cancel it).
> * change would not conflict with ASF defined rules, the 72h is not
> compulsory (document states "should" not "must").
> * the release process is already wearisome, complex, and is easy to miss
> (over-represented) manual steps. For example yesterday for some reason it
> took almost 2 hours to sync release artifacts to Maven Central, during
> which you are in a "busy loop" (the announcement and site depends on sync).
> Leaving it "for tomorrow" may cause users to learn about a new release thru
> Artifact Listener or whatever other service, causing confusion. Ideally,
> site and announcement mail should be tied to sync, and that does lead to
> "busy loop".
> * 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.
> * which part do you like: as a developer sitting on needles while being
> blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
> * we already agreed on one minor process improvement: we have quite long
> "chains" of dependencies, so a bugfix that can span on long trails could
> take weeks to be done serially, even if the bugfix itself is trivial. Hence
> we did accept that we can do "batch votes" (release together) and can do
> one vote for this case.
> * on positive site this could lead to mindset change of bugfix releases, as
> today, few wants to go thru painful release process for "single simple
> change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
> wrong: we all should release early and often. And be happy with it, not
> feel it like chores :)
>
> Finally some "canned responses":
> * "time is needed for all interested parties to review": If someone cannot
> get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
> does not matter, as release is to happen anyway (unless release mgr cancels
> it). One not getting to it, will be notified via mails anyway (vote,
> result, announce). We can already observe that there are "areas of
> interests", but also there is the customary habit of "review invitation"
> which is a good thing IMHO, as usually one invites a colleague with whom
> the topic was or is under discussion already, so both of them are
> "contextualized". Those initiated developers will most probably join in
> voting for release as well, as either they depend on the fix or they know
> what the problem was.
> * "this will lead to more bugs" or "we are too hasty making changes": no,
> it will not and we are not. As in essence, this change would allow us, in
> case of need, to release even multiple times per day (so release the
> project carrying a bug in the morning, then have a patch release for it in
> the afternoon). Really, as bugs are inevitable, they happen with or without
> 72 hours, still the current process just causes problems IMHO. As the new
> release is sitting on Central, without immediate remediation possibility.
> Or to put it another way, having this option open does not mean we will
> make all releases like it, and we will not start competing by releasing all
> the plugins several times a day :) You can see there are "hot spots'' (if
> you look at maveniverse as whole, sometimes plugins, sometimes shared
> stuff, sometime ma

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
injected type will be the most important), slf4j are part of the API and we
said we don't want that - for goods so sounds like we should stick to the
API respect IMHO and if needed promote some new API, no?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 18 nov. 2022 à 19:11, Tamás Cservenák  a
écrit :

> 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 MANY plugins have components, and creating components in
> MAJORITY of plugins is easy and should remain easy (and offered "out of the
> box").
>
> but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm
> that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
> plugin can do whatever it wants, but still has access to m4 API (that is
> heaven vs earth when compared to m3 state of affairs).
>
> ===
>
> in future, when we drop m3 support, this could mean:
>
> false (default)
> - m4 API
> - javax.inject
>
> true
> -m4 API
>
> ===
>
> Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
> values:
> - * <- plugin classrealm should have all "capabilities" current Maven
> runtime provides
> - m4api <- I want maven 4 api ONLY
> - m3api, slf4j, jsr330  <- I want to m3 api (would break in m4+ that drops
> m3 backward compat), slf4j logging and would use jsr330 components
> "capability"
>
> But this is getting too wild maybe :)
>
>
> T
>
> On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák 
> wrote:
>
> > 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
> > plugins downloading dozens of DI container (or their versions), as even
> ASF
> > plugins would not be in "lockstep".
> >
> > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> > that would say maven "I will be in charge of my components" (defaults to
> > false, Maven behaves as today). When true, it would mean Mojo wants to
> > bootstrap some DI/whatever container of its own, and then, for plugins
> like
> > these, Maven could even "narrow" the list of exported classes? (like
> > javax.inject?)
> >
> > T
> >
> > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet 
> wrote:
> >
> >> 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 with other components from maven, they should all come from the
> >> api and should be retrieved using Session.getService(xx), or simply
> using
> >> session's shortcut methods.  The injection of Project and Session is not
> >> controlled by sisu. For the ComponentConfigurator, we could change the
> >> mojo
> >> descriptor to have the full configuration class name for mojos that
> >> require
> >> custom configuration injection, the plugin manager being in charge of
> >> instantiating this class and using it as a ComponentConfigurator (which
> is
> >> not part yet of the api btw).
> >>
> >> Complex plugins which rely on plexus/sisu to do some custom injection
> >> would
> >> have to be changed to do their own DI, maybe using a simple Guice setup.
> >>
> >> If that sounds like too big a change for those plugins, we may be able
> to
> >> add a flag on the mojo descriptor so that those v4-enabled mojos would
> >> trigger a DI injection on behalf of the plugin.  But if we have to
> >> implement something like that, I would go for a plain CDI-like api,
> either
> >> using guice or another DI library supporting the javax.inject package,
> or
> >> rather the jakarta.inject package, as it would be nice to switch to the
> >> jakarta version at the same time.  Or maybe even plexus if we really
> need
> >> to, but with a limited scope, i.e. no visibility on the maven
> components,
> >> so that plugins are better decoupled from maven-core.
> >>
> >>

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 MANY plugins have components, and creating components in
MAJORITY of plugins is easy and should remain easy (and offered "out of the
box").

but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm
that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
plugin can do whatever it wants, but still has access to m4 API (that is
heaven vs earth when compared to m3 state of affairs).

===

in future, when we drop m3 support, this could mean:

false (default)
- m4 API
- javax.inject

true
-m4 API

===

Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
values:
- * <- plugin classrealm should have all "capabilities" current Maven
runtime provides
- m4api <- I want maven 4 api ONLY
- m3api, slf4j, jsr330  <- I want to m3 api (would break in m4+ that drops
m3 backward compat), slf4j logging and would use jsr330 components
"capability"

But this is getting too wild maybe :)


T

On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák  wrote:

> 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
> plugins downloading dozens of DI container (or their versions), as even ASF
> plugins would not be in "lockstep".
>
> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> that would say maven "I will be in charge of my components" (defaults to
> false, Maven behaves as today). When true, it would mean Mojo wants to
> bootstrap some DI/whatever container of its own, and then, for plugins like
> these, Maven could even "narrow" the list of exported classes? (like
> javax.inject?)
>
> T
>
> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet  wrote:
>
>> 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 with other components from maven, they should all come from the
>> api and should be retrieved using Session.getService(xx), or simply using
>> session's shortcut methods.  The injection of Project and Session is not
>> controlled by sisu. For the ComponentConfigurator, we could change the
>> mojo
>> descriptor to have the full configuration class name for mojos that
>> require
>> custom configuration injection, the plugin manager being in charge of
>> instantiating this class and using it as a ComponentConfigurator (which is
>> not part yet of the api btw).
>>
>> Complex plugins which rely on plexus/sisu to do some custom injection
>> would
>> have to be changed to do their own DI, maybe using a simple Guice setup.
>>
>> If that sounds like too big a change for those plugins, we may be able to
>> add a flag on the mojo descriptor so that those v4-enabled mojos would
>> trigger a DI injection on behalf of the plugin.  But if we have to
>> implement something like that, I would go for a plain CDI-like api, either
>> using guice or another DI library supporting the javax.inject package, or
>> rather the jakarta.inject package, as it would be nice to switch to the
>> jakarta version at the same time.  Or maybe even plexus if we really need
>> to, but with a limited scope, i.e. no visibility on the maven components,
>> so that plugins are better decoupled from maven-core.
>>
>> Thoughts ?
>>
>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet  a
>> écrit :
>>
>> > I do agree that debugging the provisioning side is *very* complicated
>> when
>> > there's a problem.
>> > I'd be happy to get rid of sisu/plexus and use a more simple DI
>> framework,
>> > at least for simple plugins.
>> > However, I definitely don't think pushing OSGi to plugins would be a
>> good
>> > idea : the cost and burden on plugin developers would outweigh the
>> benefits.
>> >
>> > For extensions, and for maven itself, that is a different story though.
>> > Maven and extensions could definitely benefit from OSGi, but this would
>> be
>> > a complete breakage and it would be hard to keep some level of
>> > compatibility.
>> >
>> > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich 
>> a
>> > écrit :
>> >
>> >>  > Guess classrealm is fine for maven, it does not bring much issues
>> >>
>> >> As long as it works, maybe, maybe even if you write a simple maven
>> >> plugin, but for any more complex it is just a complete mess.
>> >>
>> >> Last time I asked on the mailing list how to debug that stuff ...
>> >> compl

[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 maximum of 72 hours.".

Reasoning:
* vote cannot be vetoed by definition (only release mgr can cancel it).
* change would not conflict with ASF defined rules, the 72h is not
compulsory (document states "should" not "must").
* the release process is already wearisome, complex, and is easy to miss
(over-represented) manual steps. For example yesterday for some reason it
took almost 2 hours to sync release artifacts to Maven Central, during
which you are in a "busy loop" (the announcement and site depends on sync).
Leaving it "for tomorrow" may cause users to learn about a new release thru
Artifact Listener or whatever other service, causing confusion. Ideally,
site and announcement mail should be tied to sync, and that does lead to
"busy loop".
* 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.
* which part do you like: as a developer sitting on needles while being
blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
* we already agreed on one minor process improvement: we have quite long
"chains" of dependencies, so a bugfix that can span on long trails could
take weeks to be done serially, even if the bugfix itself is trivial. Hence
we did accept that we can do "batch votes" (release together) and can do
one vote for this case.
* on positive site this could lead to mindset change of bugfix releases, as
today, few wants to go thru painful release process for "single simple
change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
wrong: we all should release early and often. And be happy with it, not
feel it like chores :)

Finally some "canned responses":
* "time is needed for all interested parties to review": If someone cannot
get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
does not matter, as release is to happen anyway (unless release mgr cancels
it). One not getting to it, will be notified via mails anyway (vote,
result, announce). We can already observe that there are "areas of
interests", but also there is the customary habit of "review invitation"
which is a good thing IMHO, as usually one invites a colleague with whom
the topic was or is under discussion already, so both of them are
"contextualized". Those initiated developers will most probably join in
voting for release as well, as either they depend on the fix or they know
what the problem was.
* "this will lead to more bugs" or "we are too hasty making changes": no,
it will not and we are not. As in essence, this change would allow us, in
case of need, to release even multiple times per day (so release the
project carrying a bug in the morning, then have a patch release for it in
the afternoon). Really, as bugs are inevitable, they happen with or without
72 hours, still the current process just causes problems IMHO. As the new
release is sitting on Central, without immediate remediation possibility.
Or to put it another way, having this option open does not mean we will
make all releases like it, and we will not start competing by releasing all
the plugins several times a day :) You can see there are "hot spots'' (if
you look at maveniverse as whole, sometimes plugins, sometimes shared
stuff, sometime maven, etc), especially with closing releases of Maven, but
those hotspots come and go, move, and just like today, some components will
not be released for quite some time, as the hotspots move from here to
there.

Applying this process change, if accepted, would not alter anything
regarding "commit policy" of code changes (PRs, JIRA attached patches, etc).

Refs:
https://www.apache.org/foundation/voting.html
https://www.apache.org/legal/release-policy.html

Please comment, add your opinion. Ideally, if discussion closes with
"positive outcome", I would like to propose a vote for these changes.

Thanks
T

[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 specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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 the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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";>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485";>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553";>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15";>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1";>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074";>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf";>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139";>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1";>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778";>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.4";>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.slf4j:slf4j-api&package-manager=maven&previous-version=1.7.36&new-version=2.0.4)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
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 specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
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)

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
plugins downloading dozens of DI container (or their versions), as even ASF
plugins would not be in "lockstep".

OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag that
would say maven "I will be in charge of my components" (defaults to false,
Maven behaves as today). When true, it would mean Mojo wants to
bootstrap some DI/whatever container of its own, and then, for plugins like
these, Maven could even "narrow" the list of exported classes? (like
javax.inject?)

T

On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet  wrote:

> 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 with other components from maven, they should all come from the
> api and should be retrieved using Session.getService(xx), or simply using
> session's shortcut methods.  The injection of Project and Session is not
> controlled by sisu. For the ComponentConfigurator, we could change the mojo
> descriptor to have the full configuration class name for mojos that require
> custom configuration injection, the plugin manager being in charge of
> instantiating this class and using it as a ComponentConfigurator (which is
> not part yet of the api btw).
>
> Complex plugins which rely on plexus/sisu to do some custom injection would
> have to be changed to do their own DI, maybe using a simple Guice setup.
>
> If that sounds like too big a change for those plugins, we may be able to
> add a flag on the mojo descriptor so that those v4-enabled mojos would
> trigger a DI injection on behalf of the plugin.  But if we have to
> implement something like that, I would go for a plain CDI-like api, either
> using guice or another DI library supporting the javax.inject package, or
> rather the jakarta.inject package, as it would be nice to switch to the
> jakarta version at the same time.  Or maybe even plexus if we really need
> to, but with a limited scope, i.e. no visibility on the maven components,
> so that plugins are better decoupled from maven-core.
>
> Thoughts ?
>
> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet  a écrit
> :
>
> > I do agree that debugging the provisioning side is *very* complicated
> when
> > there's a problem.
> > I'd be happy to get rid of sisu/plexus and use a more simple DI
> framework,
> > at least for simple plugins.
> > However, I definitely don't think pushing OSGi to plugins would be a good
> > idea : the cost and burden on plugin developers would outweigh the
> benefits.
> >
> > For extensions, and for maven itself, that is a different story though.
> > Maven and extensions could definitely benefit from OSGi, but this would
> be
> > a complete breakage and it would be hard to keep some level of
> > compatibility.
> >
> > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich  a
> > écrit :
> >
> >>  > Guess classrealm is fine for maven, it does not bring much issues
> >>
> >> As long as it works, maybe, maybe even if you write a simple maven
> >> plugin, but for any more complex it is just a complete mess.
> >>
> >> Last time I asked on the mailing list how to debug that stuff ...
> >> complete silence ...
> >>
> >> Today I tried to refactor the name of one module of a more complex
> >> maven-plugin (with core extension), now I end up with
> >>
> >> org.apache.maven.InternalErrorException: Internal error:
> >> com.google.inject.ProvisionException: Unable to provision, see the
> >> following errors:
> >> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
> >>
> >> A whole bunch of stack trace but not a little info why the * it is
> >> not happy. Now I need to add random "exportedArtifact" /
> >> "exportedPackage" stuff to hope finding out where it has lost a
> >> transitive dependency, also here absolutely no documentation what this
> >> is supposed to do/work exactly beside some introduction that these xml
> >> tags exits and reading the code... or probably add maven-compat
> >> anywhere... or change provided to compile scope (even maven is jelling
> >> at me that's bad and I will be punished soon)... not counting the many
> >> times where I messed up the realms because I accidentally trying to use
> >> XppDom objects in extensions and plugins and something between got
> >> messed up.
> >>
> >> With OSGi i get clear errors for missing requirements, I can clearly
> >> share API (or declare I don't want to share it) and can reliable use it
> >> without classlaoding problems.
> >> If one wan't can even implement service filtering that would h

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 with other components from maven, they should all come from the
api and should be retrieved using Session.getService(xx), or simply using
session's shortcut methods.  The injection of Project and Session is not
controlled by sisu. For the ComponentConfigurator, we could change the mojo
descriptor to have the full configuration class name for mojos that require
custom configuration injection, the plugin manager being in charge of
instantiating this class and using it as a ComponentConfigurator (which is
not part yet of the api btw).

Complex plugins which rely on plexus/sisu to do some custom injection would
have to be changed to do their own DI, maybe using a simple Guice setup.

If that sounds like too big a change for those plugins, we may be able to
add a flag on the mojo descriptor so that those v4-enabled mojos would
trigger a DI injection on behalf of the plugin.  But if we have to
implement something like that, I would go for a plain CDI-like api, either
using guice or another DI library supporting the javax.inject package, or
rather the jakarta.inject package, as it would be nice to switch to the
jakarta version at the same time.  Or maybe even plexus if we really need
to, but with a limited scope, i.e. no visibility on the maven components,
so that plugins are better decoupled from maven-core.

Thoughts ?

Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet  a écrit :

> I do agree that debugging the provisioning side is *very* complicated when
> there's a problem.
> I'd be happy to get rid of sisu/plexus and use a more simple DI framework,
> at least for simple plugins.
> However, I definitely don't think pushing OSGi to plugins would be a good
> idea : the cost and burden on plugin developers would outweigh the benefits.
>
> For extensions, and for maven itself, that is a different story though.
> Maven and extensions could definitely benefit from OSGi, but this would be
> a complete breakage and it would be hard to keep some level of
> compatibility.
>
> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich  a
> écrit :
>
>>  > Guess classrealm is fine for maven, it does not bring much issues
>>
>> As long as it works, maybe, maybe even if you write a simple maven
>> plugin, but for any more complex it is just a complete mess.
>>
>> Last time I asked on the mailing list how to debug that stuff ...
>> complete silence ...
>>
>> Today I tried to refactor the name of one module of a more complex
>> maven-plugin (with core extension), now I end up with
>>
>> org.apache.maven.InternalErrorException: Internal error:
>> com.google.inject.ProvisionException: Unable to provision, see the
>> following errors:
>> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
>>
>> A whole bunch of stack trace but not a little info why the * it is
>> not happy. Now I need to add random "exportedArtifact" /
>> "exportedPackage" stuff to hope finding out where it has lost a
>> transitive dependency, also here absolutely no documentation what this
>> is supposed to do/work exactly beside some introduction that these xml
>> tags exits and reading the code... or probably add maven-compat
>> anywhere... or change provided to compile scope (even maven is jelling
>> at me that's bad and I will be punished soon)... not counting the many
>> times where I messed up the realms because I accidentally trying to use
>> XppDom objects in extensions and plugins and something between got
>> messed up.
>>
>> With OSGi i get clear errors for missing requirements, I can clearly
>> share API (or declare I don't want to share it) and can reliable use it
>> without classlaoding problems.
>> If one wan't can even implement service filtering that would hide all
>> "illegal implemented API" ... and you can even make sure API is
>> (backward) compatible with implementation without waiting for a method
>> not found exception or alike.
>>
>> Beside that I find it often more clear to distinguish between API (that
>> is only implemented by the framework) and SPI (that might be implemented
>> by extenders). So probably it would be good to have maven-api and
>> maven-spi (instead of "maven-core") to make this clear.
>>
>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>> > Hi,
>> >
>> > Guess classrealm is fine for maven, it does not bring much issues (less
>> > than OSGi or JPMS to be concrete), the real issue is the stability of
>> the
>> > exposed API.
>> > Thanks the hard work Guillaume did on that for maven 4 I guess it is
>> mainly
>> > a matter of deciding what we do for maven 3.
>> > Due to the resources and work needed I assume we can just play the
>> > status-quo for maven 3.
>> > Remaining question is for maven 4 do we drop the co

Re: Surefire plain text reports

2022-11-18 Thread Elliotte Rusty Harold

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
>
> 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?
>
> --
> Sławomir Jaranowski



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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 displayed during
> build on console, so you should have it in logs from CI.
> Additionally xml reports also have it.
>
> Do you really use it on your CI?
>

Yes the stdxxx output is disabled and text file enabled when a failure is
hard to analyse.


>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 18 nov. 2022 à 09:23, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > a écrit :
> >
> > > 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?
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: Surefire plain text reports

2022-11-18 Thread Slawomir Jaranowski

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.
Additionally xml reports also have it.

Do you really use it on your CI?


>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 18 nov. 2022 à 09:23, Slawomir Jaranowski 
> a écrit :
>
> > 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?
> >
> > --
> > Sławomir Jaranowski
> >
>


-- 
Sławomir Jaranowski

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  |
LinkedIn  | Book



Le ven. 18 nov. 2022 à 09:23, Slawomir Jaranowski 
a écrit :

> 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?
>
> --
> Sławomir Jaranowski
>

Surefire plain text reports

2022-11-18 Thread Slawomir Jaranowski

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?

-- 
Sławomir Jaranowski

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
> “org.apache.maven.api”, but what about the old packages used and exported
> in Maven 3?
>
> For example in the context of
> https://issues.apache.org/jira/browse/MNG-7588 <
> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> package “org.apache.maven.plugin.descriptor”.
> We already figured out that this particular package (although not part of
> the Maven 4 API) is used from both Maven Core as well as Maven Plugin
> Tools, therefore this probably needs to stay backwards compatible.
> What about others like
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java?
> <
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> ?>
> This interface should IMHO never been implemented outside Maven Core but
> in fact it was exposed to all plugins/extensions (via
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> <
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >).
>
> There are three options coming to my mind:
>
> 1. Deprecate the interfaces we don’t consider API and create new ones for
> Maven 4 which are not exported!
>

I think that's the way to go.
We'd also need to deprecate a bunch of jars and in maven-shared like
m-artifact-transfer, maven-dependency-tree etc...
One of the goal is also to completely hide the resolver.

2. Modify the existing interfaces in a backwards compatible way (but
> somehow add a marker that they should not be implemented outside core)
>



3. Modify the existing  interfaces in a backwards compatible way (but
> somehow add a marker that they should not be implemented outside core)
>
> For all three options we somehow need to come up with a list of
> classes/interfaces currently being exported through the API class loader,
> which should be considered private and agree on an Annotation/Javadoc for
> that (something like
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> <
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29>
> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>
> WDYT?
>
> Konrad
>
>

Re: Maven 3 API, backwards compatibility