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
