Fix BEAUti startup, duplicate version listing, and example packaging#98
Merged
Merged
Conversation
Addresses issues from Remco's environment testing.
BEAUti and `applauncher LogAnalyser` failed with
ClassNotFoundException for beast.fx classes (BeautiConfig and the input
editors). Root cause: a package's service providers are listed in its
version.xml; when a version.xml scan registered a provider (via
resolveLoaderFor) before the owning beast.fx plugin ModuleLayer existed,
the provider was mapped to the fallback system loader, which cannot load
it. registerPluginLayer uses putIfAbsent and so could not replace the
stale mapping, so BEASTClassLoader.forName threw.
- forName now falls through to the plugin layers on ClassNotFoundException
from the mapped loader, and caches the loader that actually resolves the
class (self-healing, so the slow path runs at most once per class).
- resolveLoaderFor now also consults registered plugin layers, not just
the boot layer.
- Added a regression test reproducing the stale-mapping scenario.
`beast -version` listed BEAST.base twice (once from the user package
dir, once via the bundle-root version.xml that the install dir
contributes). printVersion (both the beast-base and beast-fx copies) now
lists each package once, noting where it was found, and reports later
duplicates as skipped only in verbose mode.
BEAST.base examples could not be updated by a point release: they shipped
only in the bundle root, which is replaced only by a full reinstall. The
BEAST.base package zip now includes examples/ (curated to match the
bundle), so the package manager extracts and updates them in
~/.beast/2.8/BEAST.base/examples on install/upgrade. The three release
scripts (Linux/Windows/Mac) now extract the bundle-root examples from
that same package zip, giving the example set a single source of truth
(beast-base/src/assembly/package.xml) so the copies cannot drift.
Member
|
tests are passed using Mac release: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
From Remco's environment testing of the v2.8.0 beta bundle. Three fixes:
1. BEAUti and
applaunchercrash withClassNotFoundException(the critical one)BEAUti would not start and
applauncher LogAnalyser -helpcrashed, both withClassNotFoundExceptionforbeast.fxclasses (BeautiConfig, the input editors).Root cause: a package's service providers are listed in its
version.xml. When aversion.xmlscan registered a provider (viaresolveLoaderFor) before the owningbeast.fxpluginModuleLayerwas registered, the provider was mapped to the fallback system loader, which can't load it.registerPluginLayerusesputIfAbsent, so it could never replace that stale mapping →forNamethrew.Fix (
BEASTClassLoader):forNamenow falls through to the plugin layers onClassNotFoundExceptionfrom the mapped loader, and caches the loader that actually resolves the class (self-healing).resolveLoaderFornow also consults registered plugin layers, not just the boot layer.2.
beast -versionlistedBEAST.basetwiceOnce from the user package dir, once via the bundle-root
version.xmlthe install dir contributes.printVersion(both copies) now lists each package once, notes where it was found, and reports later duplicates as skipped only in verbose mode.3. BEAST.base examples were not updatable by a point release
They shipped only in the bundle root, replaced only by a full reinstall. The BEAST.base package zip now includes
examples/, so the package manager extracts/updates them in~/.beast/2.8/BEAST.base/exampleson install/upgrade. The three release scripts now extract the bundle-rootexamples/from that same package zip, giving the example set a single source of truth (beast-base/src/assembly/package.xml) so the copies can't drift.Testing done
beast-pkgmgmtsuite passes (incl. the new regression test).mvn packagebuilds clean (all modules + assemblies).examples/(41 top-level +spec/+nexus/) and the release-script extraction produces the expected layout.The BEAUti/applauncher fix is covered by a unit regression test but has not been exercised in a real assembled bundle: the bug only manifests when
beast.base/beast.fxload as plugin layers from~/.beast/2.8/(a dev/IDE run keeps them on the boot module path and won't reproduce it). Walter: please assemble a bundle and confirmbeauti,applauncher LogAnalyser -help, andbeast -versionall behave, then hand on to Remco.Out of scope (deferred)
Skipping modules ... BEAST.app: [beast.fx]message on every run (first-pass skip resolved on retry).