slachiewicz opened a new pull request, #913:
URL: https://github.com/apache/maven-wagon/pull/913
Backport of #911 to the 3.x line. Same four commits, cherry-picked; the only
conflict
was the root POM property block, where 3.x had nothing to remove.
`maven-parent` 49 bans `plexus-container-default` in its
`drop-legacy-dependencies`
profile, and 3.x sits on the same parent with the same six declarations, so
`wagon-provider-test` trips the ban here exactly as it did on master. The
profile has no
activation today, so this is preparation for the ban becoming unconditional
rather than a
fix for a broken build.
### Why this one is safe for a patch release
The components stay declared in the generated
`META-INF/plexus/components.xml`, and the
shim reads those regardless of classpath scanning. I checked the built jars:
**every
provider still ships its `components.xml` and none gains a sisu index**, so
the published
artifacts are unchanged and third-party consumers see no difference.
The JSR-330 annotation migration (#912) is deliberately **not** backported.
That one
replaces the descriptors with a sisu index, which would silently break
embedders building
a default `DefaultPlexusContainer`. It belongs to 4.0.0.
### Carried over from #911
Four behavioural differences between the shim and the original container,
one commit each:
1. Nested XML configuration cannot be injected, so the TCK use-case
configuration moves to
its own classpath resource. This changes how TCK consumers configure use
cases -- the
one user-visible break here, limited to the test compatibility kit.
2. No default `ComponentConfigurator` is registered;
`BasicComponentConfigurator` is
instantiated directly.
3. `maven-scm-manager-plexus` drags in `plexus-container-default`
1.0-alpha-9, putting a
second container on the wagon-scm test classpath; now excluded.
4. Requirement maps are injected immutable, so the SCM tests install a
mutable copy before
registering a provider.
Full reactor green, all 17 modules.
--
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]
