Allow third-party launch config types to re-use Buildships runtime classpath provider

[donat]

Source: https://bugs.eclipse.org/bugs/show_bug.cgi?id=543328

[kdvolder]

Continuing the discussion from Eclipse bugzilla here...

@donat said:

I've given it some thought and it seems to me that making SupportedLaunchConfigType extensible would be a way to go in this case.

I think that makes sense, but STS may still need to copy a non trivial amount of BuildShip code just to make STS Boot app launch configs behave exactly like Java. Basically, I think we'd have to copy the implementation of SupportedLaunchConfigType.JDT_JAVA_APPLICATION pretty much verbatim.

That is unless the extension could somehow declare that 'this launch type should be treated exactly the same as X' (where X in our case is SupportedLaunchConfigType.JDT_JAVA_APPLICATION)

That being said I don't want to introduce a new stable API. I'd instead refactor the internal API for your use case specifically.

I'd be on board with that. Actually, maybe just slightly altering the behavior for 'unsupported' launch types might be good enough (no changes to api at all, only changes to how the 'unsupported' case is implemente). I.e. what if... for unsupported types, a default implementation would be provided that falls back on the 'plain java' logic assuming that a 'main type' attribute is present? Instead of falling back on 'no filtering'.

BTW: Since I have a workaround that seems to work right now, this isn't urgent. So you shouldn't feel rushed to put something together you might regret later :-). I'm okay it you want to take your time to think about it and discuss pros and cons of various options.

[donat]

Thanks for the insights.

[donat]

I'll look into the implementation and the possible alternatives later. I'm going to be mostly offline for the next couple of weeks. Then, we'll look into what's next for Buildship.

[mbach979]

I've just encountered this issue as well using the TestNG plugin and wasted a fair bit of time trying to figure out what was going on. After debugging and getting my head into the Eclipse/Buildship object model, I finally had enough info to be able to google to hit on this issue (or more specifically the linked eclipse issue). While I understand that custom launcher plugins might require a more generic solution, given 1) gradle's support of TestNG and 2) the prevalence of TestNG, I would think that a built-in solution would be appropriate. Is it possible to at least implement a TestNG specific solution?

btw, I was testing this with buildship 3.1.5.v20210113-0929 eclipse 2021-06, gradle 6.8.3, and TestNG plugin 7.4.0.202106051955.

I would like to help with a submitted fix, but I'm afraid I still don't have enough knowledge to know how to correctly implement a solution.

Thanks, Matt