search

JetBrains / sbt-idea-plugin

Develop IntelliJ plugins with Scala and SBT
Apache License 2.0
97 stars 28 forks source link

Xml patcher doesn't patch empty fields #66

Closed hmemcpy closed 4 years ago

hmemcpy commented 4 years ago

I noticed that if the fields in my plugin.xml are empty, e.g.<version></version> or <change-notes></change-notes>, the patcher does not patch any values in them. Upon closer look, this seems to be due to the regex: https://github.com/JetBrains/sbt-idea-plugin/blob/174ce88a416f7157952d464f4dab41be0fe2c5a5/ideaSupport/src/main/scala/org/jetbrains/sbtidea/xml/PluginXmlPatcher.scala#L53

expecting one or more characters (.+) between the tags. Is this intentional?

mutcianm commented 4 years ago

Yes, this is intentional, since IJ expects these tags to be non-empty during plugin loading. The plugin.xml is only patched during artifact assembly and running via sbt, so to keep things compatible with IJ-based workflow and avoid potential bugs the non-empty requirement is in place.

hmemcpy commented 4 years ago

Ah, I see, this makes sense.

The plugin.xml is only patched during artifact assembly

This also explains why I didn't get the changes after each build, only when assembling. I believe the gradle plugin patches the fields on every build.

Anyway, thank you, I'll make the changes in my plugin accordingly!

mutcianm commented 4 years ago

Gradle-based plugin development workflow delegates all build related tasks(compilation/assembly/testing) to gradle, bypassing JPS(IJ embedded build system) altogether. Their approach is simplier and easier to maintain but at the same time imposes a performance penalty on all tasks, especially for larger plugin projects. sbt-idea-plugin supports this kind of workflow(and it has been the primary one up until a few years ago) but at the moment batch build systems such as sbt or gradle are just not ready for even moderately big project's on-line development when it comes latency. And while JPS is far less flexible than any other mainstream build system, latency is where is shines: its incremental analyser is less precise than zinc but it's much faster, compilation starts as soon as you hit the hotkey and artifact assembly takes almost half the time of sbt's. This is the reason why there are two distinct workflows: 1) CI - which is entirely managed by sbt from compilation to testing and uploading the artifact E.g. plugin patching(which cannot be done in terms of JPS) is critical here since we don't want to release a build with a placeholder of a version, obviously. In other words: "precision >>> latency" 2) local development - in which sbt is only required to export the project model to IJ and later on all tasks are executed by IJ itself. Here we value low latency above precision: I don't want to wait a minute for sbt to fire up and another 10 seconds to start each compilation.