Hi,
Sounds like annotation processor abstraction but more general. Overall Im not sure the gain for anyone - IDE can get it with a classfiletransformer hacked on classrealm and just a dumb javaagent already - but I see the drawbacks for all plugins which will never use it so think I prefer to find a way not requiring to change any pojo which would be a huge requirement and regression for no feature gain IMHO. Le dim. 25 sept. 2022 à 22: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 > >
