Serge Huber created UNOMI-971:
---------------------------------
Summary: Obsolete Maven repositories slow and flake CI builds
Key: UNOMI-971
URL: https://issues.apache.org/jira/browse/UNOMI-971
Project: Apache Unomi
Issue Type: Improvement
Components: unomi(-core)
Affects Versions: unomi-3.0.1, unomi-3.1.0
Reporter: Serge Huber
Assignee: Serge Huber
Fix For: unomi-3.1.0
h2. Summary
Unomi’s build still asks several old or unused Maven repositories for
artifacts. When those hosts are slow, unreachable, or gone, CI burns time on
retries and can hit job timeouts even though the change under test is fine.
h2. What is going wrong today
* The root project declares extra Maven repositories beyond Maven Central. Some
of them are historical and no longer useful for current Unomi dependencies.
* Feature verification walks the full repository list. A bad repository early
in that list can stall the job with repeated network errors until the CI time
limit cancels the run.
* At least one declared repository is clearly obsolete (the old ServiceMix M2
tree on svn.apache.org). Another declared OPS4J snapshot URL currently returns
{{404}}.
* Snapshot repositories inherited from the Apache parent can overlap with
project-declared Apache snapshot URLs, so the build may probe more than one
place for the same kind of content.
* This showed up on a Dependabot pull request where unit-test CI was cancelled
at the 15-minute job timeout while retrying svn.apache.org; integration tests
never ran.
h2. Impact
* Pull request checks look red or cancelled without a real product regression.
* Contributors and Dependabot lose time on false CI failures.
* Every resolution path that probes a dead or slow repository adds latency to
local and CI builds, even when the final artifacts come from Central.
h2. Who is affected
* Contributors and committers running Unomi CI
* Dependabot / automated dependency update PRs
* Anyone doing a full build that includes feature verification
h2. What good would look like
* The Unomi build only uses Maven repositories that are still required and
healthy.
* Obsolete or unreachable repositories are removed (or clearly justified if any
must remain).
* Overlapping snapshot repository entries are reviewed so the build does not
probe redundant hosts for the same content.
* CI unit-test and feature-verification jobs no longer hang on dead repository
hosts.
* A short note in the ticket or PR records which repositories were kept,
removed, or deferred, and why.
h2. Scope of the review (expected outcome areas)
* Project-declared repositories in the Unomi root POM
* Repositories inherited from the Apache parent (including plugin repositories)
* Any other build path that feeds the same repository list into feature
verification
* Confirmation that current release dependencies still resolve from the
remaining repositories (especially Maven Central)
h2. Known starting points (for investigation, not a decision)
* ServiceMix M2 on svn.apache.org — historical, frozen for years; peer ASF
projects already dropped it
([CAMEL-12474|https://issues.apache.org/jira/browse/CAMEL-12474],
[KARAF-5294|https://issues.apache.org/jira/browse/KARAF-5294])
* OPS4J Sonatype snapshots URL currently returning {{404}} — likely unused if
Unomi only depends on released OPS4J/Pax artifacts
* Apache snapshot group vs Apache snapshots repository — check whether both are
still needed or whether one is enough
h2. References
* Example failure: [UNOMI PR 839|https://github.com/apache/unomi/pull/839] (CI
cancelled while retrying svn.apache.org during feature verification)
* Related prior art:
[CAMEL-12474|https://issues.apache.org/jira/browse/CAMEL-12474],
[KARAF-5294|https://issues.apache.org/jira/browse/KARAF-5294]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
