rangareddy opened a new pull request, #19420:
URL: https://github.com/apache/hudi/pull/19420
### Describe the issue this Pull Request addresses
Closes #15909 (HUDI-6111).
Building a single module from inside its own directory fails on checkstyle.
Reproduced on current
master, unchanged from the 2023 report:
```
cd hudi-cli && mvn checkstyle:check
[ERROR] Failed during checkstyle configuration: cannot initialize module
TreeWalker
- cannot initialize module ImportControl - illegal value
'<repo>/hudi-cli/style/import-control.xml' for property 'file':
Unable to find: <repo>/hudi-cli/style/import-control.xml
```
`style/checkstyle.xml` locates that file via
`${basedir}/style/import-control.xml`, and the root pom
supplies the property as `basedir=${maven.multiModuleProjectDirectory}`.
Maven derives that property by
walking up from the working directory looking for a `.mvn` directory; with
none in the repo it falls back
to the directory Maven was invoked from. From the root that is the repo
root, so root builds work; from
inside a submodule it becomes the submodule, and checkstyle looks for
`style/import-control.xml` there.
### Summary and Changelog
- Add `.mvn/extensions.xml` declaring **no** extensions. The file's purpose
is that the `.mvn` directory
exists, which is the hook Maven uses to resolve
`maven.multiModuleProjectDirectory` to the repo root
from any working directory. It carries an ASF header and a comment
explaining why an otherwise-empty
file is tracked.
- `.gitignore`: narrow `.mvn/` to `.mvn/*` plus `!.mvn/extensions.xml`. Git
cannot re-include a file whose
parent directory is excluded by a `dir/` pattern, so the negation alone
would not have worked. Locally
generated `.mvn` content (maven wrapper, IDE output) stays ignored.
Verified, before and after, from three places: repo root (`-pl hudi-common`,
unchanged — still passes),
`cd hudi-cli` (was failing, now passes), and `cd
hudi-client/hudi-client-common` (was failing, now
passes). Also confirmed the rule is actually enforced afterwards rather than
merely initialising:
temporarily adding `import scala.Option;` to `HoodieWriteConfig.java` and
running checkstyle from inside
`hudi-client-common` reports `ImportControl: Disallowed import -
scala.Option.` and fails the build.
`apache-rat:check` passes with the new file (`Unapproved: 0`).
Two alternatives were tried and rejected:
- `${config_loc}/import-control.xml`, the idiomatic checkstyle form — fails
with `Property ${config_loc}
has not been set`, because the pom's explicit `propertyExpansion` replaces
the plugin's default
properties.
- `basedir=${main.basedir}`, reusing the repo's own property — no new files,
but `main.basedir` defaults
to `${project.basedir}` and is only overridden in 72 of 82 poms. The 10
that don't override it include
the largest source modules, among them `hudi-client-common`, which is the
only module `ImportControl`
applies to. Fixing it that way needs 10 more pom edits with per-module
parent-depth reasoning.
I am aware `.mvn/` was ignored on purpose; if you would rather not track
anything under `.mvn`, the
alternative above is workable and I am happy to switch.
### Impact
No effect on a build run from the repo root, which is how CI builds —
`maven.multiModuleProjectDirectory`
already resolved to the repo root there. The change makes module-scoped
builds started from inside a
submodule behave the same as root builds. No production code, API, config,
or format change.
### Risk Level
low — build configuration only. Verified that root builds are unchanged,
that submodule builds now pass,
that checkstyle still fails on a real violation, and that rat and the
`.gitignore` narrowing behave as
intended.
### Documentation Update
none — no new config and no user-facing behavior change.
### Contributor's checklist
- [x] Read through [contributor's
guide](https://hudi.apache.org/contribute/how-to-contribute)
- [x] Enough context is provided in the sections above
- [x] Adequate tests were added if applicable
- [x] CI passes on my PR
--
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]
