This does not really answer the question. Extensions are made for
extending maven(-plugins) (either on the core or the project level) so
if plugins are only ever getting maven4-api available how will it be
possible then?
Whether or not Extensions are "bad" or not "maven spirit" seems a
differ
Le sam. 19 nov. 2022 à 15:23, Tamás Cservenák a
écrit :
> Romain,
>
> Who talks here about "release without feedback"?
>
Well there are two kind of consequences to reduce release time (making a
minimum a maximum):
* You drop part of the opportunity of feedback you had (by construction)
* You en
Hi
I'm not a member of the developer community here, just a watcher
offering a comment from the peanut gallery.
On 2022-11-18, Tamás Cservenák wrote:
> * vote cannot be vetoed by definition (only release mgr can cancel it).
while this is true there also is a rule that says "and more positive
bi
Romain,
Who talks here about "release without feedback"?
Or explain to me what you mean by "feedback" (as obviously you don't count
the mandatory votes as "feedback").
And, to help me in better understanding, can you point me to any example of
"feedback" (in your understanding) that happened on
Agree asf enables to release without feedbackquestion is not if it is
legal IMHO but is it what maven wants to do for thz mentionned reasons?
For me it would clearly be negative - even at asf level - and the sign the
project does not belong to asf anymore (people first) so ultimately means
it
Sounds like some code needing to move to extensions more than some mojo
interactions to me to stick to a simple and maven spirit.
Le sam. 19 nov. 2022 à 13:14, Christoph Läubrich a
écrit :
> > That's a good question. Plugins currently don't interact.
> > Is that really something we want ?
>
>
> That's a good question. Plugins currently don't interact.
> Is that really something we want ?
At least there are several places where I wish I could "plug" into an
existing plugin, curently for example surefire allows some limited
extension using test-frameworks but this requires special co
Howdy,
Let's all step back a little bit. Let's go back to my original "postulate".
- release vote SHOULD take 72h
- release vote CANNOT be vetoed (only release mgr can cancel it)
- release vote MUST reach PMC quorum
Hence, in my reading, the above set of constraints does not conflicts with
this
it looks like one key issue you're facing is specific to
https://maven.apache.org site, = our own site that is:
1. an aggregation of near 100 subsites representing each one Maven subproject
(see https://maven.apache.org/scm.html#maven-sources-overview)
2. that uses Apache infra's svnpubsub engine
Sorry for top posting.
At least 72 hours is needed because we are all volunteers and it takes time
to validate a release.
Also I see that in a few projects (maybe not Maven) the VOTE starts during
the weekend and this is a problem because sometimes in the weekend you are
not at the keyboard and we
Le ven. 18 nov. 2022 à 21:40, Tamás Cservenák a
écrit :
> 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 o
I agree with Guillaume and as discussed by the past we must not expose
anything existing so o.a.maven.whatever.inject sounds the way to go to
ensure we own it in time, and behavior is defined bybus and not a random
not well defined or stable impl.
Le sam. 19 nov. 2022 à 09:37, Guillaume Nodet a é
Requiring OSGi for anything user facing in maven is a no-go for me.
Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich a
écrit :
> > Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
>
> OSGi support generic capabilities/requirements model:
> https://blog.osgi.org/2015/12/u
13 matches
Mail list logo
