I wanted to clarify some things that got mixed up here:
1) Such an API is not for "IDE only" it can be used in various scenarios
including:
- Tools like mvnd (watch filesystem for changes and give good deltas)
- Build servers (know what has changed since last (successful) build)
- maven-cli with a finally useful --incremental option
2) The good thing is that no plugin is *forced* to adapt/use that API
but it *can* be used to be more useful in such scenarios
3) That API is actually used and already adopted by some plugins and it
greatly speedup builds and integration with such scenarios.
The only problem is, ans that's the whole purpose of this attempt here,
that there is no real "common standard" or official "API evolving"
possible with the current approach as outlined below as always there
will be concerns like "can I use it if it seems not officially supported".
That's why the proposal to host this on some official maven place (it
has not be maven-core but sounds obvious!) so we can have:
1) this covered and embedded in a workflow/governance that maven people
are familiar with to get better feedback, improvement and easier
adoption of such an API
2) People are certain that implementing this opens their plugin for a
variety of use-cases and not only restricted ones (e.g. m2e in this case)
3) Implements of the API (m2e/intelij/..., mvnd, build server
plugins,...) are certain that they support something common and not what
seems an edge-case and it works across tooling-bounds.
About the "maintenance effort" and "what if", this more sounds a bit
unrealistic (this is not a "library" nor is it a full blown IDE), this
is just an API, people are using it unchanged since 2009 with some
success, so having it hosted at maven won't really "hurt" much, beside
that already now maven is manly driven by volunteer contributions
(correct me if I'm wrong) that won't be different here.
Also in the past "special" APIs like those for supporting the mnvd
use-case are added already to maven to it seems in general there is no
rule that says "no API for external consumers".
Am 27.09.22 um 08:59 schrieb Tamás Cservenák:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
