search

bndtools / bnd

Bnd/Bndtools. Tooling to build OSGi bundles including Eclipse, Maven, and Gradle plugins.
https://bndtools.org
Other
532 stars 305 forks source link

Extract Workspace dependency from BuildpathQuickFixProcessor #3979

Closed rotty3000 closed 3 years ago

rotty3000 commented 4 years ago

BuildpathQuickFixProcessor directly uses the workspace for search. It would be great if workspace was but one of many possible providers so that we can contribute from other places like m2e (and soon buildship).

rotty3000 commented 4 years ago

As a note to my future self it would seem the logic for buildpath/testpath [1] could be extracted out to use IClasspathContainer which would allow for specific natures to be supported in an agnostic fashion. We could then introduce an abstraction to support writing back to the underlying model; bnd project, maven pom, build.gradle file.

[1] https://github.com/bndtools/bnd/blob/master/bndtools.core/src/org/bndtools/core/editors/quickfix/BuildpathQuickFixProcessor.java#L95-L111

pkriens commented 4 years ago

Not sure that is worth the effort. The class is really only a bridge, the necessary abstraction will likely double the code.

rotty3000 commented 4 years ago

M2e is having trouble with Workspace. Central is starting to hit real timing issues with all the various states of the Workspace which are incredibly painful to work around. Furthermore I would like to provide quickfix support from maven (and gradle buildship soon) and there is no real need for a Workspace.

pkriens commented 4 years ago

as long as I do not have to scale down functionality to go through a common denominator.

rotty3000 commented 4 years ago

Certainly not! :) It's not my intention to hamstring any innovations, quite the contrary.

kriegfrj commented 4 years ago

As a note to my future self it would seem the logic for buildpath/testpath [1] could be extracted out to use IClasspathContainer which would allow for specific natures to be supported in an agnostic fashion.

I think this could work.

We could then introduce an abstraction to support writing back to the underlying model; bnd project, maven pom, build.gradle file.

The abstraction would be fairly easy, I think. IJavaCompletionProposal already forms 90% of the basis of what you would need for such an abstraction - the apply() method would need to be overridden for each model type. But I think it would be hard to implement the automatic "apply" part in Gradle because there are so many different ways you could conceivably add dependencies in Gradle. (Maven, with its more structured dependency specifications, would probably be easier.) The remaining trick is to convert from the Bnd search result to the appropriate GAV coordinate to add into the build file.

It occurred to me that if we did this, the bnd Maven/Gradle plugins have a utility that goes beyond producing bundles - the indexing being a feature that stands on its own.

rotty3000 commented 4 years ago

It occurred to me that if we did this, the bnd Maven/Gradle plugins have a utility that goes beyond producing bundles - the indexing being a feature that stands on its own.

This is also part of my thinking. I think there's great advantage here.

rotty3000 commented 4 years ago

But I think it would be hard to implement the automatic "apply" part in Gradle because there are so many different ways you could conceivably add dependencies in Gradle.

I was thinking to rely on buildship's model for this. I believe their API already has a model (and that they've decided on some "best practice") for doing thins. That's my theory anyway.

rotty3000 commented 3 years ago

I'm not going to do this so let's just close.