Part of the problem is the non deterministic nature of llms. This skill
worked flawless couple of months ago on large, complicated projects. I
used it this week on four projects and it completely messed up. The
annotations were completely wrong after the migration.
In any case, for updates to the skill, I usually use the coding agent
and ask it to update based on the learnings.
Regards
Carsten
On 5/8/2026 10:37 PM, Konrad Windszus wrote:
Another issue is different semantics of SCR Service annotation
(https://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#_service)
and the service element in the OSGi DS Component annotation
(https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#org.osgi.service.component.annotations.Component.service--).
The former always registers implicitly all interfaces (no matter if
transitively or directly declared) while the latter only takes into account
direct ones by default.
Not sure if this requires adaptations to the Python script or just
clarification in the SKILLS.md is enough….
Konrad
On 8. May 2026, at 21:49, Konrad Windszus <[email protected]> wrote:
I just tried the scr migration skill with
https://github.com/Adobe-Consulting-Services/acs-aem-commons/tree/master/bundle
and for example
@SlingServlet(
methods = {HttpConstants.METHOD_GET},
resourceTypes = {"acs-commons/components/utilities/audit-log-search"},
selectors = {"auditlogsearch"},
extensions = {"json"})
(https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/165e4fd09f17dbb6ee919c11dabe53b96a735061/bundle/src/main/java/com/adobe/acs/commons/audit_log_search/impl/AuditLogSearchServlet.java#L51-L55)
was converted to
@Component(service = Servlet.class)
@SlingServletResourceTypes(
resourceTypes = "acs-commons/components/utilities/audit-log-search",
selectors = "auditlogsearch",
extensions = "json",
methods = "HttpConstants.METHOD_GET”
)
Seems that
https://github.com/apache/sling-whiteboard/blob/master/skills/osgi-scr-migrator/scripts/migrate_annotations.py
does not properly deal with non-literal annotation elements yet (like in
methods.
Thanks,
Konrad
On 8. May 2026, at 20:54, Konrad Windszus <[email protected]> wrote:
Great, thanks a lot for that.
I am just wondering if this statement from the README is actually correct:
“**Java 17+** - Required for compiling the migrated code (OSGi R6/R7 annotations
require Java 17+)"
https://github.com/apache/sling-whiteboard/blob/c2ad0487b498c2a30ba96f780ee3818bb421c3dc/skills/osgi-scr-migrator/README.md?plain=1#L55
IMHO OSGi R7 Metatype/DS annotations are fully compliant with Java 8 or am I
missing something?
Thanks,
Konrad
On 30. Apr 2026, at 07:30, Carsten Ziegeler <[email protected]> wrote:
I added the missing instructions to the existing parent update skill and also
added my scr migration skill
Regards
Carsten
On 4/24/2026 1:14 PM, Robert Munteanu wrote:
On Fri, 2026-04-24 at 06:33 +0200, Carsten Ziegeler wrote:
Definitely interesting.
As you might have noticed, I wrote a tool which can perform such
actions
like updating the parent pom across a large selection of repositories
using a coding agent.
Yes, I noticed the results :-)
I have also some skills flying around for the SCR annotation
migration
and parent pom updates :)
Maybe we can combine these into one. I'll have a look in the next
days.
I think that would be very useful. I definitely did not cover a lot of
repos during testing with the current skills and would be happy for any
enhancements.
Thanks,
Robert
Regards
Carsten
On 4/23/2026 5:35 PM, Robert Munteanu wrote:
On Fri, 2026-04-17 at 18:32 +0200, Robert Munteanu wrote:
Hi,
Updating the parent pom version in Sling modules is one task that
usually gets left behind. We have many modules, the work is not
that
rewarding and sometimes very tedious - for instance migrating
from
the
Felix SCR annotations to the official OSGi ones.
To make things simpler I have started an experiment in the
whiteboard
-
using agent skills [1] to upgrade the parent pom version.
I extended the experiment and created a tiny evaluation harness for
agent skills at [3] based on the Inpect framework [4].
I did some measurements of the skill and tried to answer some
questions
around efficiency and cost; captured the raw data at [5]:
1. Is the free variant gpt-oss-120b from openrouter good enough?
With skills it is good enough - sometimes better than haiku-4.5
from
Amazon Bedrock.
2. How big is the difference between haiku-4.5 and sonnet-4.5?
With skills the success rate is almost the same - haiku missed 1/15
of
the evals. But Sonnet ends up being almost 3.x more expensive.
3. How good is Claude Sonnet with or without skills?
The skills make all the difference.
Without skills Sonnet can only perform basic upgrades (100%) but it
fails in more complex cases:
- 20% success rate if the rat checks fail after upgrade
- 0% success rate if the build fails because of relocated
dependencies
(OSGi R6)
With skills Sonnet passes all 15 tests.
[1]: https://agentskills.io/
[2]: https://github.com/apache/sling-whiteboard/tree/master/skills/
[3]:
https://github.com/apache/sling-whiteboard/tree/master/skill-evals
[4]: https://inspect.aisi.org.uk/
[5]:
https://gist.github.com/rombert/c099c13013fbdf27445816c976005aba
--
Carsten Ziegeler
Adobe
[email protected]
--
Carsten Ziegeler
Adobe
[email protected]
