There are two kinds of project in _ext. One is a glue code shim which is built and compiled normally (eclipse-base and eclipse-jdt). The other is a combination of glue code and a fat jar that bundles up a bunch of dependencies from Eclipse p2 repositories that are otherwise not available on mavenCentral (eclipse-cdt, eclipse-groovy, and eclipse-wtp).

You can tell which is which based on whether they have apply from: rootProject.file('../gradle/p2-fat-jar-setup.gradle'). If they do, then they are using the p2asmaven plugin to download a bunch of p2 dependencies and then smush them into a local maven repository. The big sin of this plugin is that this giant download is done at configuration time, not task time. I wrote the p2asmaven plugin, and this sin is committed for a reason, and it's very hard to fix.

I love how you have broken out the options. With the p2 fat jar problem in mind, here are the consequences:

Option 1 will mean that any Spotless dev who wants to run any gradle task will first have to sit through a p2 download that will take minutes. These p2 repos don't have great uptime, and if they happen to be down, the build will fail and devs will have to know which part of the buildscript to magically comment out. I'm against Option 1.
Option 2 and 3 both seem great to me. 2 seems strictly better than 3, so long as it turns out to be possible to get the composite build to work. If it's not, then 3 is still useful.
Option 0, the status quo, does have one small advantage over 2 and 3. Which is that you don't have to run all of the p2 download tasks, only the one you care about. It's not a huge advantage though, and I think 2 or 3 is better overall.

An important challenge in this is that the interproject dependencies won't really work unless the fat jar part is taken into account. When you open the eclipse-cdt code, you're compiling against the jars in the local maven repo that you downloaded from p2. And when we publish, those local jars (and some even have nested jars!!!) all get mushed together into the final jar that gets uploaded to maven. And that mushed jar is required for the FormatterStep to work - it won't work without the fat jar step.

In general, we can release a new version of the JDT formatter just by bumping versions in the lockfile. We only need to change eclipse-base or eclipse-jdt if we want to change the shim code. At this point, they only ever change when @fvgh makes improvements to them, which have been increasingly minor improvements as time goes on (a testament to how successful his work on this has been! He's fixed a lot of things in a permanent way).

To release cdt, groovy, or wtp, it is rare that we need to change the shim code, we just need to publish a new fat jar containing the new deps, and then update the lock files.

So I think that the code in question is probably less-active than it seems at first. Regardless of how active this code is, the changes you suggest would definitely be a welcome improvement!

Reorganize _ext projects #483

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions