You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "kwin (via GitHub)" <gi...@apache.org> on 2026/10/08 10:36:59 UTC
[PR] COMMONSXML-21 Configure OSGi to improve compatibility with older runt… [commons-parent]
kwin opened a new pull request, #725:
URL: https://github.com/apache/commons-parent/pull/725
…imes
Added configuration to prevent Import-Package generation for java.*
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
https://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
Thanks for your contribution to [Apache Commons](https://commons.apache.org/)! Your help is appreciated!
Before you push a pull request, review this list:
- [ ] Read the [contribution guidelines](CONTRIBUTING.md) for this project.
- [ ] Read the [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) if you use Artificial Intelligence (AI).
- [ ] I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
- [ ] Run a successful build using the default [Maven](https://maven.apache.org/) goal with `mvn`; that's `mvn` on the command line by itself.
- [ ] Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
- [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
- [ ] Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.
--
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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] COMMONSXML-21 Configure OSGi to improve compatibility with older runt… [commons-parent]
Posted by "kwin (via GitHub)" <gi...@apache.org>.
kwin commented on PR #725:
URL: https://github.com/apache/commons-parent/pull/725#issuecomment-6058431907
Please look at https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-execution.environment
> However, a bundle always loads classes in java.* packages via parent delegation. See [Parent Delegation](https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.parentdelegation). Therefore, a bundle is not required to import a java.* package to have visibility to the classes in the package, if the package is present in the current runtime. It only needs to import a java.* package to have the resolution process ensure the package is available from the execution environment. This can avoid a NoClassDefFoundError during execution of the bundle due to a missing java.* package required by the bundle.
The only drawback is that potentially the bundle will fail at runtime instead of at resolution time when executed in a trimmed down JRE not exposing all relevant packages.
We are talking about Felix 6 (https://mvnrepository.com/artifact/org.apache.felix/org.apache.felix.framework/6.0.5), released in 2021 not yet supporting this properly (https://issues.apache.org/jira/browse/FELIX-5843).
--
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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] COMMONSXML-21 Configure OSGi to improve compatibility with older runt… [commons-parent]
Posted by "garydgregory (via GitHub)" <gi...@apache.org>.
garydgregory commented on PR #725:
URL: https://github.com/apache/commons-parent/pull/725#issuecomment-6058353933
How old are we talking about here? I'm not sure this is a good idea. Please explain the pros and cons.
--
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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] COMMONSXML-21 Configure OSGi to improve compatibility with older runt… [commons-parent]
Posted by "garydgregory (via GitHub)" <gi...@apache.org>.
garydgregory commented on PR #725:
URL: https://github.com/apache/commons-parent/pull/725#issuecomment-6058689194
So the cons are, for _all_ of Apache Commons:
- modern OSGi users lose useful dependency metadata
- we now get failures to move from OSGi failures in _resolution_ to JVM failures in _execution_, for example getting a `NoClassDefFoundError` for `java.sql`
- we lose early detection of missing Java packages across Commons to accommodate an old (unsupported?) OSGi framework.
Dealing with an old version of one OSGi vendor is not enough to justify the loss IMO.
To be fair, the risk is likely small for "normal" JDK/JRE deployments, but still clutters things up for all of Commons.
Let's see what other folks have to say either way.
--
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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org