infra: convert nested libs to wrapped OSGi bundles

[Bananeweizen]

EclipseCS uses several external libraries, which are copied manually into the libs folder. Since everything else comes from the Eclipse target platform, those 3 libraries are easier to maintain by fetching them directly from maven and letting Eclipse PDE automatically wrap them into OSGi bundles.

With that change in place, updating the external libraries is as easy as changing the version number in the .target file.

For end users, this change is in fact visible. Previously the nested libs were contained in the checkstyle jar, now they are visible as plugin in the IDE. This is how the newly wrapped javassist library looks like (that entry did not exist before):

The overall functionality and behavior are the same. Basically we just have another container around them to get them onto the classpath.

[Bananeweizen]

For reviewers: The interesting parts from the build are the lines around https://app.travis-ci.com/github/checkstyle/eclipse-cs/jobs/588568308#L346, where Tycho mentions how it wraps one of the libs from maven as Eclipse plugin.

[rnveach]

Please show that you did testing and Checkstyle still functions correctly.

are easier to maintain by fetching them directly from maven
it wraps one of the libs from maven as Eclipse plugin

This sounds great that the JARs are being removed. Why isn't this also possible with the Checkstyle JAR?

updating the external libraries is as easy as changing the version number in the .target file.

So this file is safe to modify? It says generated, so I was thinking some process need to run to create/update.

[Bananeweizen]

All the changes I commit have been tested locally by

• changing the configuration
• clearing all markers
• running checkstyle again and verifying I have the same markers as before.

Why isn't this also possible with the Checkstyle JAR?

That removal is probably also possible with the checkstyle jar. I did not yet do that, since I wanted to take a look at what else happens with that newly built checkstyle-all.jar and what #263 did instead. But it's on my todo list. :)

I would also like to fix #385 first, since having the fat jar twice is really not nice, no matter whether it is created manually, taken from maven etc. However, #385 seems not trivial, since there are classpath issues when "just removing" one of them.

So this file is safe to modify? It says generated, so I was thinking some process need to run to create/update.

Good catch, that line was a copy/paste error. I've taken time to update the readme and to explain the complete process in more details. It may look confusing on first glance, but it leads to a very simple structure for editing and generating files.

If you are curious, it looks like this now when opening the target file in a target editor:

[romani]

I am approving, but @Calixte need to review this to be aware and may be new ideas come up how to simplify dependency on main library

[Calixte]

You use a "partial" target file here just for code organization / clarity?

[Bananeweizen]

Yes. The Maven part of the target must be edited manually, and the remaining Eclipse part can be generated. However, you cannot have the generation and the manual editing in one target file, therefore the generated part is included as "partial". If you think there is a better name for more clarity ("generated" instead?), I'll happily accept every suggestion.

[Calixte]

Nope, partial sounds good to me. I'm just trying to make sure I understand.
We could take this a step further and make another partial for the maven libs, and the main target file would just be an aggregate of partials.

[Bananeweizen]

I would be fine with that, too. At work, I use exactly such a 3 target files setup. I wasn't sure if I confuse people even more if I go from 1 to 3 here. :)