Those past days, I've been looking at the takari incremental build api
mentioned by @cstamas in this thread. I've been importing and hacking it a
bit so the result is available at [1].

Maven plugins can be injected with a BuildContext [2] and use it to
indicate which input files need to be processed. This allows a real
incremental build.  The default implementation that is provided uses the
file system to detect changes and will result in the maven plugin to only
process the given input files.  The SPI allows integration of IDE with the
Workspace interface [3] which is responsible for actually computing a list
of new/deleted/modified resources and is given a list of processed outputs
and messages.

I think such an API would be much more beneficial than the sisu-build-api
as I see several benefits in going into such direction :
 * it actually benefits maven a lot with real performance boosts
 * it is testable by plugins because there is a real implementation (and
not only a no-op one)
 * it remains an opt-in for a given plugin
The main drawback is that plugins have to be refactored in order to
leverage this new api, but if it's integrated in the new v4 api, I think
this is a good opportunity for plugins to migrate.

Cheers,
Guillaume

[1]
https://github.com/gnodet/maven/tree/build-context/api/maven-api-core/src/main/java/org/apache/maven/api/build
[2]
https://github.com/gnodet/maven/blob/build-context/api/maven-api-core/src/main/java/org/apache/maven/api/build/BuildContext.java
[3]
https://github.com/gnodet/maven/blob/build-context/api/maven-api-core/src/main/java/org/apache/maven/api/build/spi/Workspace.java


Le dim. 25 sept. 2022 à 20:26, Hannes Wellmann <wellmann.hann...@gmx.net> a
écrit :

> Hello Maven developers,
>
> for the Maven integration for Eclipse IDE (called M2Eclipse or M2E) there
> is a mechanism of so called "connector plugins" or "connectors" which
> connect Maven plug-ins with the IDE. Their job is to tell the IDE what to
> do during a workspace-build within the IDE, if the connected plug-in is
> encountered when building a Maven-project. They decide if the maven-plugin
> is executed or not and can perform necessary extra configuration. But one
> important and often the only actual relevant task of such connector is to
> tell the Eclipse IDE which files have been updated so that it can refresh
> the internal data about those files and react to the changes if necessary.
> Therefore the need for a connector often vanishes if the plug-in would
> notify the IDE about the files it just changed.
>
> In order to deliver such notifications to the IDE the 'sisu-build-api' [1]
> project incubated the concept of a 'BuildContext' [2] that can be used by
> mojos to perform file-system operations like create new files or refresh
> the state of a file. Additionally it provides information about deltas
> since the last (incremental) build and therefore acts as cache. Maven
> Plugins then use the BuildContext to perform their file-system operations
> instead of using corresponding Java APIs directly. The default
> implementation, which is used in a standalone Maven build is rather
> straight forward and just performs the corresponding operation respectively
> always answers that a file has changed. [3] But within the IDE an enhanced
> BuildContext can be injected into the Maven session that notifies the IDE
> when a file-system operation happened and properly maintains the
> cache/delta data.
>
> Plug-ins that would for example benefit from that are the
> maven-clean-plugin and the maven-dependency-plugin. They only delete or
> copy/unpack files and the IDE only has to be notified about that.
>
> While the 'sisu-build-api'-project never left the prototype status and the
> repository has been archived in the meantime, the general idea still seems
> to be suitable. Therefore we, the Maven2Eclipse team, want to ask if there
> is a general interest from the Maven dev team to improve the connection
> between maven and IDEs by using such an approach? You can find the
> discussion at M2E with some more details under. [4] A corresponding API
> with default implementation for standalone Maven builds could be maintained
> as part of Maven so that not only Eclipse can use it. Of course the API
> could be reworked to better fit the most common usage patterns. Suggestions
> for other approaches to improve the connection without the need to maintain
> 'connectors' would of course be welcome as well.
>
>
> Regards
>
> Hannes
>
> [1] - https://github.com/sonatype/sisu-build-api
> [2] -
> https://github.com/sonatype/sisu-build-api/blob/master/src/main/java/org/sonatype/plexus/build/incremental/BuildContext.java
> [3] -
> https://github.com/sonatype/sisu-build-api/blob/master/src/main/java/org/sonatype/plexus/build/incremental/DefaultBuildContext.java
> [4] - https://github.com/eclipse-m2e/m2e-core/discussions/876
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
------------------------
Guillaume Nodet

Reply via email to