vbhanuchander-lang opened a new pull request, #8136:
URL: https://github.com/apache/hop/pull/8136
Fixes #8012
### The defect
The env file configured on a lifecycle environment (Project/Environment
dialog → **Plugins** tab) is documented as a reference that "may contain
variables", but nothing anchored it to the project. Two independent halves of
the same problem:
**1. Lookup.** `resolveEnvFile()` expanded variables and handed the result
to VFS. `HopVfs.resolveWith()` turns a name with no scheme into `new
File(name).getAbsolutePath()` — i.e. it anchors at `user.dir`, which for a
launched Hop GUI is the Hop installation directory. So `config/hop-env.yaml`
configured on an environment was looked up under the install, never under the
project, and the check silently found nothing.
**2. The chooser.** The **Browse** button on that tab called
`BaseDialog.presentFileDialog(...)` with no starting `FileObject`. For an
*open* dialog that is the only thing that sets the start location (`BaseDialog`
only calls `setFileName`/`setFilterPath` when a `FileObject` is supplied), so
the browser opened at its own default with no relation to the file already
configured — which is what the report shows.
`HopInstallSpecEditor.presentSpecFileDialog()` already seeds a starting file
since #8059; this call site was not updated with it.
**3.** `LifecycleEnvironmentDialog` builds the `AttributesContext` it hands
to plugin tabs but never called `setProjectHome(...)`, so a tab had no project
home to anchor against even if it wanted to.
### The fix
`HopInstallSpecFiles.resolveInProject(filename, variables, projectHome)`
expands variables and, only if the result is *still* relative, anchors it at
the project home (falling back to the `PROJECT_HOME` variable). Absolute POSIX
paths, Windows drive letters, UNC paths and VFS URLs (`s3://…`, `file://…`) are
returned untouched, as is anything relative when no absolute project home is
known — that keeps today's behaviour rather than inventing a base.
Wired into the runtime check and into both buttons on the tab. Browse and
Edit now start at the configured spec file when it resolves, and at the project
home otherwise.
One detail worth calling out: **the reference the user typed wins when it
already resolves.** Anchoring is only attempted as a fallback. Without that,
opening `${PROJECT_HOME}/hop-env.yaml` in the editor and saving would write the
expanded absolute path back into the field, quietly destroying the portable
reference.
### Tests
14 new tests in `HopInstallSpecFilesResolveInProjectTest`. **7 of them fail
if `resolveInProject` is reduced to today's `resolve`**, including
`relativeReferenceIsOnlyFoundOnceAnchoredAtTheProject`, which writes a real
`config/hop-env.yaml` under a temp project home and asserts through
`HopInstallSpecFiles.exists()` that the reference is only found once anchored —
that is the reported bug end to end, not just the helper's own contract. The
other 7 are the guards that absolute/UNC/drive/VFS references are never
rewritten, and they pass either way by design.
Verified locally on JDK 21: `hop-misc-marketplace` 252 tests,
`hop-misc-projects` 123 tests, 0 failures. `spotless:check` and
`apache-rat:check` clean on both modules.
### Not changed
`MarketplaceRepositoriesPanel`'s import/export choosers have the same
missing start location, but those handle repository definitions rather than the
environment spec file and are outside what #8012 reports. Happy to fold them in
if you would prefer one pass over all of them.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
