Le lun. 6 mai 2024 à 19:40, Tamás Cservenák <[email protected]> a écrit :
> Howdy, > > inline. > > > 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. > > > > This is not a new concept at all, one of the main reasons a lifecycle > participant was added was exactly this, > and the Takari lifecycle did leverage it for years. Unsure why this is a > "new concept" for you. > If you don't need to create a new module nor any new interface in maven core or a shared module I'm all for the change, otherwise it is a new shared thing whatever you present it. > > > > > 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. > > > > > But that's the point! I don't want to author an Ant-like Maven build! > I don't want to fiddle with each nit. I don't want to "fit carefully" > sticks, tricks and hacks, build a house of cards or Jenga-build. > I don't want to modify my build to "make it work". I don't want to adapt > extra hoops and loops in my build "make it happen". > I don't want "smart" and "intelligent" solutions. I don't want to check out > a Maven project and spend time figuring out "how it works". > > I want simple wooden-wedge level solutions. I am in a "Dead Simple Maven > Builds" camp. > I understand what you mean but it is the case of the "current" solution. We don't need a new module nor anything outside plugins scope. The "do at end" on maven built-in components is even a pretty bad example cause it would be saner for the goal you describe to add a parameter on maven components methods more than a new concept IMHO - concretely enable this feature in repositorySystem directly which is already shared by design. As soon as you make a plugin "living" more than its execution you are no more "dead simple" and have a ton of edge cases as the one you mentionned which is a simple one where both cases can make sense (don't deploy if the test fail or let it be deployed - depends if you release or dev, close to "fail test at end"). If you take the deploy jar + oci container case, the recover case is not trivial, the "deploy at end" is just a broken concept by design and requires something different to recover. What I mean is that we cover way enough cases without adding a new thing in core and that moving just one step further is not sufficient in most cases so the solution will be complex for a poor concrete gain so we should probably look for something else - but I agree covering it completely is quite more challenging cause either you can embrace reproducible builds and upsert/get-and-update or you have to burn a version (snapshot or not) if you can't recover manually. > > > > > 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. > > > > Explained above what I mean by "mutilation". > > But you can enumerate all the things you want, but still miss the point :) > Again, this is not a "new tech" or anything, not a "revolutionary solution" > for anything. > This is IMHO "deployment done right" (and more to come). > No what you look at is "only artifacts deployment done my way", but it breaks all the cases maven deploys something else - and once again it is not rare today. > > Oh yes, and this thread is about MDK. > hehe, if so nothing to discuss ;) > > Thanks > T >
