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 > >
