Le lun. 6 mai 2024 à 18:55, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Romain, > > I have more and more the feeling that you are not reading what has been > written down, at least not carefully enough. > > Otherwise, you';d know that is it NOT "already doable", as explained in MDK > doco (but also in previous thread): > Just one example: the current "deploy at end" feature of m-deploy-p does > NOT deploy "at (build) end", but at "last module using m-deploy-p plugin". > Hence, you can end up with deployment done, and afterwards a build failure. > Exactly...this is what will always happen with plugins and extensions. Indeed you can add a phase after plugins then you moved the issue to one more step but the issue is still *exactly* the same but in a new concept and layer, so literally no gain there. > For example some latter module running tests that use non-standard > packaging and not using m-deploy-p on purpose. > No issue there, you still control the reactor and therefore control the last module built after all others if you want - I use that for the documentation module of a 100+ modules project, so not an issue, you can always have your last module have m-d-p. > > Second, again as explained, the point is to NOT mutilate your build with > hoops and loops, adapt to chosen build service, > as if you choose (or you are forced) to move to another service, you would > need to rinse-repeat, but this time for the other publishing service. > Not sure what you meant there but I don't see any mutilation: * you want to control more your lifecycle -> you can, indeed it requires some configuration since it breaks the default setup but it is doable and main case is still smooth (convention over config) * you want to plug a custom impl in a plugin -> you can (Guillaume even did the work for extensions) * you want to make plugins working altogether sharing a coupled or loosely coupled state? -> you can (using an extension to hold it or a generic JVM/Maven type in the session data) So there is not yet any describe use case requiring a new concept in maven AFAIK. > > > Thanks > T > > > > On Mon, May 6, 2024 at 5:56 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > Hi Tamas > > > > So it is just a spi consommable from a plugin using an extension to > share a > > state accross mojo execution...so nothing we already do. > > > > My understanding of your request is to bring to maven 4 api this concept > > for common needs (delayed tasks I'd say more than anything specific to > > deployment). > > > > But presented as in the wiki value stays quite low cause it is already > > doable either with or without an extension - using the session and a > plugin > > running at the end of the build. > > > > Le lun. 6 mai 2024 à 18:37, Tamás Cservenák <ta...@cservenak.net> a > écrit > > : > > > > > Howdy, > > > > > > Please take a peek at (and maybe try out) latest Maveniverse project, > > MDK: > > > > > > https://github.com/maveniverse/mdk > > > > > > This is like "proof of concept" or "demo" of what the Plugin SPI > pattern > > > would be able to do. > > > > > > The idea is to broaden the support, and provide services even like > > > "overlaid staging", when staging would receive deployments from > multiple > > > different sources (like for example OS native binaries). > > > > > > MDK is not yet, but will be integrated with Toolbox, to use it's sink > > > abstraction: > > > https://github.com/maveniverse/toolbox > > > > > > Have fun > > > T > > > > > >
