keksmd opened a new pull request, #980:
URL: https://github.com/apache/incubator-graphar/pull/980
### Reason for this PR
Part of #979: consumers cannot depend on the pure-Java SDK today. No
`org.apache.graphar` artifact exists on Maven Central or in the ASF snapshot
repository, and the modules are not publishable as they stand: every SDK POM
uses `${graphar.version}` for its own and its parent's version, and the parent
`graphar-root` is never published, so an installed POM cannot be resolved
outside this reactor.
This PR prepares the build side only. It does not change the version, cut a
release, or publish anything by itself.
### What changes are included in this PR?
- `flatten-maven-plugin` (oss mode) on `graphar-info`,
`graphar-storage-api`, `graphar-storage-local`, `graphar-storage-s3`,
`graphar-io-api`, `graphar-core`, and on the root POM itself (not inherited).
Installed and deployed POMs carry concrete versions and no parent. The FastFFI
`java` module and `spark` are untouched.
- Root POM: the commented-out SCM and issue tracker restored with the
`apache/incubator-graphar` URLs, plus a `developers` entry pointing at dev@.
These are required repository metadata.
- `apache-incubator-disclaimer-resource-bundle` added to the Apache parent's
remote resources, so every jar carries `META-INF/DISCLAIMER` next to `LICENSE`
and `NOTICE`.
- `.github/workflows/java-sdk-snapshot.yml`: on pushes to main that touch
the SDK, runs the SDK tests and `mvn deploy` to `apache.snapshots.https`
(distribution management comes from the Apache parent). It refuses non-SNAPSHOT
versions, runs only in `apache/incubator-graphar`, and has a
`workflow_dispatch` dry run that stops at `install`. The same pattern is used
by apache/datafusion-comet.
When #975 and the reader/writer land, their modules get the same one-line
plugin entry and join `SDK_MODULES`.
### What maintainers need to do outside this PR
1. File an INFRA Jira ticket to configure the `org.apache.graphar` groupId
in the ASF Nexus and provision the `NEXUS_USER` / `NEXUS_PW` secrets on this
repository. Until then the deploy step fails with 401; the dry run works.
2. The Java version is still `0.13.0-SNAPSHOT` although v0.13.0 is released.
I left the bump to the release manager since it also affects `spark`.
3. A Maven release goes through the usual staging repository, PPMC vote, and
IPMC vote, then promotion to Central.
### Are these changes tested?
Locally:
- CI-equivalent `spotless:check`, `clean verify`, and `package
javadoc:javadoc` for `info,storage-api,storage-local,io-api,storage-s3,core`:
green.
- Installed the SDK, then built and ran a separate consumer project whose
local repository held only `graphar-info`, `graphar-core`,
`graphar-storage-api` and `graphar-storage-local` (no `graphar-root`). It
resolves and loads `org.apache.graphar.info.GraphInfo`.
- `graphar-core` jar contains `META-INF/DISCLAIMER`, `LICENSE`, `NOTICE`.
- `mvn -pl spark/graphar,java -am validate` succeeds.
- The workflow YAML parses; the deploy step itself can only be exercised
once the secrets exist.
### Are there any user-facing changes?
No API changes. Once the secrets are provisioned, SDK snapshots appear at
`https://repository.apache.org/content/repositories/snapshots/org/apache/graphar/`.
## Checklist
- [x] I have performed a self-review of my own code.
- [ ] I have formatted my own code using `make cpplint` before submitting
when changed files are in the `cpp` directory.
- [x] I have performed `pre-commit run` before commit the changed files.
- [x] I have added tests to prove my changes are effective.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
