Le mer. 28 sept. 2022 à 06:35, Christoph Läubrich <m...@laeubi-soft.de> a écrit :
> For ClassFileTransformer: > > Just let us assume "the IDE" can just transform any class, this still do > not offer a way for the plugin(!) to get information back. > One of the most valuable things is that a plugin can store state across > calls and get reliable information if a file changed since last call, > what currently it can only do by comparing existing files. > > Beside this, its likely that such approach is not very portable across > tools and will require a lot of guessing. > > Also one part of the build-api is (what might be split into an > individual one) that a plugin can report back a line and column where > the error/warning occurs. If not one needs to parse the log and again > "guess whats going on" to give the user valuable information about the > location of the error. > > Another thing to guess regarding things like: > > https://github.com/takari/io.takari.incrementalbuild > > please correct me if I'm wrong, but this will require me to completely > rewrite my mojo, while with the plexus-build-api it is less intrusive, I > can use all features, I can only use some of them. > That's true. That's a more long term goal but with real benefits for maven and imho that would nicely fit with the new API coming up in https://github.com/apache/maven/pull/703. > > Am 28.09.22 um 05:18 schrieb Romain Manni-Bucau: > > Hi Hannes, > > > > Out of curiosity, why did you reject the transformer approach (if you > tried > > it)? > > Agree it can slow down a bit first startup but it is solething very easy > to > > cache for an IDE - at indexation time even. > > > > Sounds like more efficient and generic for an IDE than anything API > related > > at maven level to me. > > > > > > Le mer. 28 sept. 2022 à 03:45, Hannes Wellmann <wellmann.hann...@gmx.net> > a > > écrit : > > > >> Hello, > >> > >> first of all I have to correct myself M2E is currently using the > >> 'org.sonatype.plexus:plexus-build-api'. I looked that up incorrectly. > Thank > >> you for mentioning that and for the historical background. > >> > >>> 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 have to say that I disagree with your summary of my initial mail. > >> For clarification, the intention of my mail was to ask if there is a > >> general interest in providing an API (anywhere) at maven that *any* IDE > can > >> use and even other maven tools as Christoph already said. > >> I did not request to use an IDE specific API, not even any specific > API, I > >> just mentioned the one M2E is currently using and how it is using it as > an > >> example to make the purpose more clear. We would be happy with any > suitable > >> API. > >> And as the GAV indicates, the plexus-build-api is not Eclipse/M2E > specific > >> and not maintained by Eclipse/M2E. M2E is just the only user, as far as > I > >> know, and therefore it is often falsely labeled as being for > >> M2E-integration. > >> But in fact any other IDE can use that as well. I have not checked other > >> IDEs and therefore don't know if or why they don't use it or if they > have > >> better approaches. But I hoped to maybe find that out as part of this > >> discussion. > >> If you already have (plans for) a "Maven API" in Maven 4 that goes in > that > >> direction, that's great. > >> > >> The current approach of M2E to have one Eclipse-M2E specific connector > per > >> Maven plug-in simply does not scale well and maybe other IDEs face the > same > >> issue? > >> Assuming that other IDEs work in similar ways it means that there would > be > >> one such 'connector' respectively special treatment of that plugin per > IDE > >> for each Maven-Plugin, that is reasonably executed during workspace > builds. > >> Therefore we thought it would be better if Plugins of Maven(-Core), but > >> also third-Party Plugins, would operate on some form of > >> abstract-FileSystem/BuildContext instead of performing file-system > >> operation directly or maintaining own logics to determine if something > >> changed. Each IDE can then provide one corresponding IDE-specific > context > >> implementation that is injected when the plugins are executed as part of > >> the IDE build. But the N connectors respectively the special treatment > per > >> IDE and Plugin would not be necessary. In total there would be much less > >> code and there would be less code that would have to be synchronized in > >> case a Maven plugins changes. > >> All that at the 'cost' of performing (mainly) file-system operations > >> differently. If the API is well designed I expect/hope that it won't be > >> more complicated than today, just different. > >> > >>> I find it hardly justifiable to make maven committers perform extra > work > >>> (of integrating and maintaining) something that does not give them any > >>> benefit. > >> > >> Improved integration for any IDE is a benefit for me. > >> And personally (and I think I speak for the other M2E committers as > well) > >> I would rather contribute adjustments of Plugins to Maven than > maintaining > >> Eclipse specific connectors at M2E. That way I think my freetime, in > which > >> I mainly contribute to Eclipse and M2E is used most effectively. And if > >> other IDEs can use that API as well, there is potential that their > >> maintainers contribute as well. > >> > >>> 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 > >> > >> Thanks for that suggestion, we have not yet considered that. > >> But wouldn't that require to be perpared for all different patterns of > >> file-system modifications used in any class of the realm to be able to > >> manipluate the bytecode accordingly? > >> Maybe I have not yet fully understand the topic, but for me that sounds > >> like many Mojos/Pojos have to be considered/tested individually by devs > >> again. > >> > >>> For the IDE to be notified, why not using a FileWatcher on the project > >>> folder and see if anything has changed ? > >> > >> > >> Do you know if this is implemented based on real file-system events on > all > >> major OS? > >> If polling is used, a FileWatcher probably has a bad performance when > >> there are many/large projects in the workspace. > >> > >> > >> Hannes > >> > >> > >> > >> --------------------------------------------------------------------- > >> 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 > > -- ------------------------ Guillaume Nodet
