Le dim. 2 oct. 2022 à 16:45, Hannes Wellmann <wellmann.hann...@gmx.net> a écrit :
> > 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. > > > I have not yet tried the transformer approach and have to admit I have > never used a transform yet at all, so please correct me if I'm wrong. > If we would use a transformer that would mean that we either have maintain > a list of transformations for each plug-in or search for certain code > patterns that are of interest and have to be transformed. > For the former approach we would have to check each plugin to assemble the > necessary transformation and would have to do that again for each new > version because the interesting parts are usually internal and therefore > can change arbitrarily with each plugin release. > That would require a lot of effort and testing of each plugin and would > not really be a difference to the current stand, maybe even weaker because > we would have to rely even more on internals of the plug-ins. > And all that only for the Eclipse-IDE, other IDEs would have to do the > same unless they have a different/better approaches for that. > No, you integrate the pointcuts which enable to write. There are not much in the jvm (writers, outputstreams mainly). It is way more relevant and less fragile than an api which will never really cover your need in time from my XP even if it does not look like that upfront. It is global so no lib patching - an api will never cover mojo wrapping libs like schema2java ones for ex. > If we would use the latter approach and only check for interesting > patterns like File creation, deletion, copying, writing, etc. there would > be different Java APIs to consider IO-File, NIO-Path, many different > patterns like using Input/OutStreams in various forms or methods like those > offered by the Files class. > Furthermore the interesting actions are maybe performed in some called > library or util, so that those classes would have to be scanned as well. > I might be wrong, but to me this looks like an approach that indeed > includes a lot of guessing/assumptions and therefore requires a lot of > testing and continuous monitoring thus effort as well. > > And as said before, we would like to spend that effort at the place where > it is most valuable for a better interaction between Maven and an IDE and > we assumed that would be Maven itself with something similar to the > presented approach. > > Of course the points Christoph mentioned are important as well. > > > 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. > > > Is there a summary/overview for the new API? The PR is quite large. :) > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
