Howdy, Some (historical) clarification here: The sisu-build-api has existed since 2009, but was _abandoned_ since by its initial author as being "incomplete". Also, that repo has been _archived_ since the 2010-ish year, also many years ago (I think it was longer archived than not).
Not long ago, there was a blunt attempt to "revive" it (here https://github.com/codehaus-plexus/plexus-build-api) only to figure out things are not so simple :) See https://github.com/codehaus-plexus/plexus-build-api/issues/21 As GAV seems baked into m2e. Since sisu-build-api abandoned, Igor had another iteration and ended up with this: https://github.com/takari/io.takari.incrementalbuild Sadly, he disappeared since. And regarding "integrating X API to work in IDE Y", it clearly does not work: - not happened since 2009 - gives us (Maven committers) extra work without ANY benefit (to our project) (yes, it will work in IDE Y, but only WHEN it runs in IDE Y, Maven per se will NOT become incremental not benefit anything from it, just extra dep and complexity). - I hate sprinkling dead libraries across mojos (see https://github.com/eclipse/sisu.mojos/pull/6) is IMHO just purely wrong, forcing ANY mojo to ingest a dead library just to "make it work in IDE Y"? - etc What will happen tomorrow, if Maven is approached by the NetBeans or IDEA team with some text like "What a nice tool you have here, it would be a shame to let something happen to it, right? So, you should integrate this library to make it work in our IDE...". I am pretty much sure (does not have exact numbers) that the IDE landscape DID change quite a bit since 2009. I find it hardly justifiable to make maven committers perform extra work (of integrating and maintaining) something that does not give them any benefit. TL;DR I keep it completely wrong that we (Maven Committers) have to integrate an IDE specific library ONLY to make it work in a given IDE. Obviously it will not scale, nor motivate us, not to mention the fact that the library itself is claimed "incomplete" and abandoned/dead/superseded by the author. === That above is part One :D Here comes part Two: Given Maven4 is about to introduce "Maven API", something that was missing for way too long, there was a decision to incorporate some API for "incremental" (per-mojo) capability as well, but, this is still "far from being done". The goal of this API would not only be to ease IDE integration, but also to make Maven itself possibly incremental in the proper way. My 5 cents T On Tue, Sep 27, 2022 at 8:14 AM Konrad Windszus <k...@apache.org> wrote: > The API exists since 2009, so we are not talking about a new thing here. > Also some things IMHO cannot be expressed with plain Mojo/Maven API (like > line number, column or file where error/warning occurred). > So let's focus the discussion rather on the concrete API/proposal for > extension. > Konrad > > > On 2022/09/26 17:53:54 Romain Manni-Bucau wrote: > > You are mixing two things: > > > > 1. IDE enhancement (incremental support or whatever you want) -> it is > > generally good IMHO > > 2. Need of an API to handle that -> this is not needed at all and IDE can > > already catch this data in a more relevant manner than adding an API > which > > wouldn't be embraced anyway before ~10 years at least by the *community* > (= > > no way IDE get the feature if you impl it this way in practise) > > > > So yes, this kind of API is definitively a bad thing IMHO but the feature > > behind is welcomed - but once again does not need any maven change. > > > > Le lun. 26 sept. 2022 à 19:23, Konrad Windszus <k...@apache.org> a > écrit : > > > > > Probably a misunderstanding then. It sounded a bit like you deny the > > > benefit of having an API for incremental builds and IDE integration in > > > general. > > > But good that we are on the same page that as an opt-in API this is > > > definitely a good thing to have. > > > > > > Konrad > > > > > > --------------------------------------------------------------------- > > > 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 > >
