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
