Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/pmd/pmd/issues/4446 below:

Circular dependencies between pmd-designer, pmd-core, pmd-cli · Issue #4446 · pmd/pmd · GitHub

We have a workaround for this problem (#4445), but I'd like to explore, whether we can make a real solution instead of allowing snapshot dependencies (and make the build not repeatable) for release candidates. Also, for the final release 7.0.0, we would need a pmd-designer, that depends on e.g. 7.0.0-rc3.

So, the dependencies look like this:

• pmd (that's what we release in one run)
  • pmd-core
  • pmd-cli
    • pmd-designer
      • pmd-core
  • pmd-dist
    • pmd-designer
      • pmd-core
• pmd-designer (the designer is released separately)
  • pmd-core

If we could release pmd-core separately first, then we could release pmd-ui second, and the rest of pmd as last.

pmd-core uses pmd as the parent project, so that would be needed to be released as well. Currently, we use our parent project as parent project and additionally as aggregator. That would need to change.

I don't think, I have a favorite yet...

We could just accept, that we need snapshot dependencies for the first release of a major version. However, the same problem will occur again for 8.0.0.

So, maybe we can have the following structure:

pmd/pom.xml (artifactId=pmd-aggregator): Just an aggregator to easily build everything at once. 
                                         Won't be released.
pmd/parent/pom.xml (pmd): the parent pom, without modules. So, not an aggregator anymore.
pmd/pmd-core/pom.xml (pmd-core): no changes - uses the same parent

We could then release parent and pmd-core first. That could be done by just setting the version of parent to a non-SNAPSHOT version, updating the reference in pmd-core and in other modules to the new parent. Commit this as "prepare release pmd-core x.y.z", and tag this as "pmd-core-x.y.z". Pushing that tag would build the aggregator pom, which would build all modules, while parent and core a released versions, all other are still SNAPSHOT. Not sure, how the nexus-staging-maven-plugin handles this situation (deploying a mix of SNAPSHOT and non-SNAPSHOT artifacts). If that causes a problem, we could create a separate build-script/workflow, that runs only on these tags (pmd-core-*) - since pmd-core is just a library, we don't need to do anything else (like creating release notes, etc.). The script can be very simple (just run "mvn deploy -f parent/pom.xml && mvn deploy -f pmd-core/pom.xml").
Once pmd-core is available in maven-central, we can simply update pmd-designer to use this new pmd-core version and release pmd-designer.
Once pmd-designer is available in maven-central, we can update the other modules and set everything to the same version, commit this as "prepare release x.y.z", and tag this as usual as "pmd_releases/x.y.z". Push the tag and let it build. We need to make sure, we don't build/deploy pmd-core again, as it is already in maven-central - redeploying it will definitively result in failure. The build script however would do all the magic we currently do (create documentation, upload binaries, publish release with release notes).

This as definitively an impact on reproducible builds - as reproducing a pmd release is then not anymore a single build.

What I don't like here is: it looks very complicated, we don't have a single tag, but two tags. The release process might take a while, because we need to wait between the steps.

Maybe we should separate pmd-core into its own repository. That would solve the tagging issue and makes the build scripts simpler. However, it might have an impact on the developer experience - but you can e.g. import an additional module in IntelliJ, so that you have pmd-core integrated during development.

Move pmd-designer back into the main repository. That way, we have all the moving parts in one place and can simply release everything in one go. Affects issues (designer bugs are separate), raises the question, why pmd-eclipse-plugin is separate, etc.

Alternatively we could use git submodules

• Don't include pmd-designer in pmd-dist anymore
• Don't provide a CLI command to start the designer
• The designer will need to be installed always additionally and in parallel to the PMD installation

That kind of a compromise:

• We don't include pmd-designer in the pmd-dist anymore. That's not possible, because the designer is not available yet
• We provide a CLI command to start the designer, but that figures out at runtime, whether the designer jar is there. If so: start the designer as usual. If not: ask the user, whether to download the jar. The jar can also be placed manually into the lib folder.
• In addition to the jar, we also provide a "fat" pmd-designer binary distribution, which includes also PMD. And javafx.

• Name of the repository: maybe "https://github.com/pmd/pmd-package"?
• pmd-designer is still separate
• Drop the statically generated shell completion for languages in the cli module (just affects the --use-version and --force-language flags IIRC). The shell completion does anyway not reflect the actual modules that are present on the classpath at runtime. This removes the dependency of pmd-cli on other language modules. PMD should give a error message if a wrong language is used (e.g. "did you mean...").
• Since pmd-cli doesn't have dependencies on language modules anymore, we can move it out of the main repo together with pmd-dist. They can then depend on pmd modules and the designer freely.

Dependency hierarchy now:

• pmd (single release unit)
  • pmd-core
  • pmd-java
  • pmd-cli
    • pmd-core
    • pmd-ui (references only, only old release available)
      • pmd-core
  • pmd-dist
    • pmd-core
    • pmd-cli
    • pmd-ui (references only, only old release available)
• pmd-ui (released separately)
  • pmd-core (references only, only old release available)

Dependency hierarchy after:

• pmd (single release unit)
  • pmd-core
  • pmd-java
• pmd-ui (released afterwards)
  • pmd-core (can reference the just released pmd-core)
• pmd-package (final release unit)
  • pmd-cli
    • pmd-ui (can reference the just released pmd-ui)
    • pmd-core (can reference the just released pmd-core)
  • pmd-dist
    • pmd-core (can reference the just released pmd-core)
    • pmd-ui (can reference the just released pmd-ui)
    • pmd-cli (in the same reactor of pmd-package)

Consequences:

• Releasing a new PMD version will require multiple steps. At least two steps (pmd itself and pmd-dist), if an updated pmd-designer is needed, 3 steps.
• The Release publishing step with release notes etc. will be done when pmd-package is built/released. The release of "pmd" itself will only deploy the jars into maven central. It could however prepare a draft release, to which pmd-dist can then add the assets.
• Automation: we could build a pipeline, so that the release build of pmd triggers a workflow on pmd-designer which triggers a workflow on pmd-package.

• I think, this problem is new. We moved out the pmd-designer with 6.13.0. In PMD 6.13.0, we shipped designer 6.12.0. Since we didn't do a major release since then, we not had this problem yet.
• We once seem to had a similar problem: 6.21.0 (with designer): PMD 6.21.0 shipped designer 6.19.0. PMD 6.21.0-full is actually PMD 6.22.0-SNAPSHOT with designer 6.21.0. However, with a major release change, we can't ship PMD 7 with designer 6.x...

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4