...
| Topic | Summary | Participants | Proposed duration | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Limitations of API regions | Although the package visibility is restricted what about
Seems that this concept is not really complete and it requires some workarounds. I can share some insights what I needed to do to use Ehcache (private AEM region) from several customer bundles in AEMaaCS:
| ||||||||||||||||||
| Move Integration Tests to Sling 12 | Several module-specific Integration tests are still running with a very old provisioning-model based sling version, not compatible with Java 17. We need to switch to Sling 12 and feature model, integrated in a single POM to run side-by-side as ITs. Affected repos:
PoC from Konrad Windszus : https://github.com/apache/sling-org-apache-sling-models-impl/pull/46 | ||||||||||||||||||
| Servlet Spec 5.0 and beyond | https://jakarta.ee/specifications/servlet/, currently Sling is at Servlet Spec 3.1.0 with old namespace only Compare with
Existing tooling to help with migration: https://github.com/eclipse/transformer We will very likely need both build-time and run-time tooling. The Eclipse Transform project already providers build-time tooling (bnd and maven), the run-time tooling will need to be created based on it. | Julian Sedding | |||||||||||||||||
| Real OSGi Unit testing | I have been working on a utility that makes it reasonably simple to implement unit tests and to execute them in-process and in a real OSGi framework. The utility is implemented as a set of Junit5 extensions, which can be applied to a test method using a simple annotation. The utility
If there is interest, I would like to present this utility, where it might find a good home (in Sling, bnd, Felix, else where?) and discuss where we could leverage it for testing Sling modules. We could explore if this could help with the transition of Sling 12 integration tests (see above), or if it is not suitable.
| ||||||||||||||||||
| More frequent and periodical Sling Starter releases | The Sling Starter is the simplest way users can try out Sling. We do not release often so our users often get an outdated application to run on top of. We have always said that this is a demo app and not meant to build on, but in practice people copy/paste the Sling Starter and start adjusting it. If we were to support the Starter as an application base we would offer a much simpler story for building on Sling. This would require though that we release the Sling Starter with reasonable cadence ( 3 months? ). https://lists.apache.org/thread/gnxhhorhq27fv0o3qkhrv384pldcy2nn | Robert Munteanu | 60-120 minutes | ||||||||||||||||
| Reducing noise on the dev lits | Our dev list is very high-volume but mostly due to automated notifications coming from GitHub (bots included), Jira, and Jenkins (to a lesser extent). Typically we would recommend people to join the dev list and create filters but I think email has been getting less attention these days, and the volume is intimidating. I would recommend moving most or all of the automated notifications to the commits@sling list instead where activity can be tracked. On a related note, I think PRs from non-committers should be treated separarely and highlighted as they require committer participation for review and merge.
| Robert Munteanu | 15-30 minutes | ||||||||||||||||
| Move to GitHub Actions | Jenkins is not really stable and GH actions are easier to maintain and less lines to code compared to Jenkins libraries. Also the initial capacity bottleneck seems to have been resolved nowadays. There are some examples worth looking at: https://github.com/apache/maven-gh-actions-shared/. There is also the potential to reduce overhead for ASF releases with release actions. The ASF policy needs to be considered though: https://infra.apache.org/github-actions-policy.html. A new repo has been created for this in https://github.com/apache/sling-tooling-github.
| ||||||||||||||||||
| Move to GH Issues | Jira registration is restricted, requires additional overhead. Devs are more familiar with GH nowadays. However for Sling it is more tricky to find the right repo, reconsidering https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=255073567#HackathoninBerlinSeptember2023-16)SwitchtoGitHubissues? Infra has some tooling that allows moving Jira to GitHub issues, with the mentioned caveat of finding the proper repository - | ||||||||||||||||||
| Tidy up the Sling-mini native compilation scripts | Give the sling-mini native compilation scripts a home, initially in the Sling Whiteboard. | A. J. David Bosschaert | |||||||||||||||||
| Improve documentation for AI | Example for wrong content: ChatGPT says OSGi events should be preferred over ResourceChangeListener Another question: If we make changes like deprecating an API, how long will it take until LLM models that are publicly available will reflect that change in their answers? | Georg Henzler |
...