mirror of
https://github.com/adobe/skills.git
synced 2026-09-19 08:06:09 +08:00
feat/java21-migration-skill
6 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
42bc5b0120 |
feat(aem-6.5-lts): add Java 21 migration skill
Add a new skill for migrating AEM 6.5 LTS Maven projects from Java 8/11 to Java 21. The skill uses OpenRewrite recipes for automated code transformation, Python POM manipulation scripts for changes OpenRewrite cannot handle, and agent-assisted build fixing with strict guardrails. 12-step migration workflow covering: project validation, Java version detection, initial build, OpenRewrite Java migration, POM manipulations, CloudManager config, pre-Mockito build, Mockito migration, final build, jakarta/workaround cleanup, migration reporting, and diff review with local commit. Includes: - OpenRewrite recipes for Java 8/11→21 and Mockito 1.x→5.x - Python scripts for compiler config, SCR removal, classifier migration, and FileVault groupId fixes - JSON configs for plugin, dependency, and classifier rules - Maven settings.xml and toolchains.xml for multi-JDK builds - Reference docs: prerequisites, build-fix constraints, OpenRewrite commands, POM manipulation rules, validation report - tile.json for 6.5-lts plugin (enables tessl evals) Guardrails: javax-not-jakarta enforcement, 8 unsupported package hard stops, enforcer version monotonicity, POM indentation preservation, temp workaround cleanup, change attribution. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|
|
f51cac86af |
fix(aem-workflow): correct workflow-debugging skill in workflow-debugging (#138)
* fix(aem-workflow): correct cq.workflow.job.max.procs parallelism myth in workflow-debugging (AEM 6.5 LTS) The skill instructed customers to increase cq.workflow.job.max.procs for workflow throughput. While that property is shown in Felix Console (its display name and description are defined in the WorkflowSession Factory metatype), it has no effect at runtime — no code path reads the value. Real workflow parallelism is controlled by queue.maxparallel on the "Granite Workflow Queue" (an Apache Sling Job Queue Configuration instance). The skill's own thread-pool section at SKILL.md:105 already mentions Max Parallel correctly; the four cq.workflow.job.max.procs references contradicted that and were misleading customers. - SKILL.md: 4 references to cq.workflow.job.max.procs replaced with queue.maxparallel on the Granite Workflow Queue - reference.md: parallelism row updated to point to the correct OSGi config (Apache Sling Job Queue Configuration) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(aem-workflow): correct JMX MBean ObjectName for retry/queue-info ops in workflow-debugging (AEM 6.5 LTS) The skill cited com.adobe.granite.workflow:type=Repository as the MBean hosting retryFailedWorkItems, returnSystemJobInfo, and returnWorkflowQueueInfo. That ObjectName does not exist on AEM 6.5 LTS — a JMX lookup returns 404. All three operations actually live on com.adobe.granite.workflow:type=Maintenance, the same MBean the skill already used correctly for purgeCompleted/countStaleWorkflows/ restartStaleWorkflows. The real second workflow MBean is :type=Statistics, which exposes time-series execution metrics. Updates Step 7 (Key JMX MBeans) to: - Consolidate every workflow maintenance operation under the Maintenance MBean (matches what AEM actually exposes via JMX) - Add Statistics MBean as a separate row with its read/write accessors for DataLifeTime / DataFidelityTime / DataProcessRate / DataRate plus getResults / clearRecords - Add operation parameter signatures (model, days, dryRun) where applicable Verified on AEM 6.5 LTS localhost:4505: - :type=Maintenance → HTTP 200 - :type=Statistics → HTTP 200 - :type=Repository → HTTP 404 (does not exist) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(aem-workflow): replace stale Config Status ZIP file refs with live Felix Console URLs in workflow-debugging (AEM 6.5 LTS) The skill instructed customers to "check in 039_Sling_Thread_Pools.txt" and similar numbered files from the Configuration Status ZIP for thread pools, threads, Sling Jobs, and Sling Scheduler data. The Config Status ZIP produced by AEM 6.5 LTS (/system/console/ status-Configurations.zip) does not contain those numbered files — only 000_Configurations.txt and index.json. A customer following the skill would search for files that do not exist on their AEM. Updates all 9 references to point to the live Felix Console pages that are the actual sources of this data: - 039_Sling_Thread_Pools.txt -> /system/console/status-slingthreadpools - 042_Threads.txt -> /system/console/status-Threads - 043_Threads__via_JStack_.txt -> /system/console/status-jstack-threaddump - 027_Sling_Jobs.txt -> /system/console/slingevent - 034_Sling_Scheduler.txt -> /system/console/status-slingscheduler - 003_Configurations.txt -> /system/console/configMgr Each URL verified to return HTTP 200 on AEM 6.5 LTS localhost:4505. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(aem-workflow): correct Granite Workflow Queue Max Parallel default value in workflow-debugging (AEM 6.5 LTS) The skill stated that the Granite Workflow Queue ships with queue.maxparallel = 1. The actual OOTB value on AEM 6.5 LTS is 0.5, which the Sling Job Queue interprets as "50% of available CPU cores" (fractional values in 0..1 are CPU-relative; integers >= 1 are absolute worker counts). A customer following the previous skill would plan throughput tuning against the wrong starting point. Updated in two places: - Step 3c Granite Workflow Queue config bullet list - Step 5 Configuration checklist table row Both now cite the OOTB 0.5 value with a pointer to verify the running value via the OSGi config endpoint at /system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration~workflow. Verified on AEM 6.5 LTS localhost:4505: queue.maxparallel = 0.5. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
3e71c25e36 |
Feat/skill workflow launchers 65 lts (#135)
* fix(aem-workflow): update workflow-launchers content for AEM 6.5 LTS Updates the workflow-launchers skill for AEM 6.5 LTS with validated content covering launcher configuration, condition patterns, and JCR-event-driven workflow triggering. SKILL.md now references the canonical foundation refs hosted under workflow-orchestrator instead of local duplicates. - SKILL.md: expanded launcher configuration guidance; loop-prevention guardrail clarified (WorkflowSession vs JCR Session disambiguation); IDE-LLM consumability improvements; foundation ref links re-pointed to workflow-orchestrator canonical copies - condition-patterns.md: ECMAScript (Rhino) terminology corrected; pattern coverage tightened - launcher-config-reference.md: cq:WorkflowLauncher property reference expanded; consumability improvements Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(aem-workflow): remove duplicated foundation refs from workflow-launchers (AEM 6.5 LTS) The 6 foundation reference files under workflow-launchers/references/ workflow-foundation/ duplicated the canonical copies hosted in workflow-orchestrator/references/workflow-foundation/. SKILL.md links were re-pointed to the canonical copies in the previous commit, so the local duplicates are now orphaned. Deletes: - 65-lts-guardrails.md - README.md - api-reference.md - architecture-overview.md - jcr-paths-reference.md - quick-start-guide.md Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(aem-workflow): correct loop-prevention setUserData value in workflow-launchers (AEM 6.5 LTS) The skill instructed setUserData("workflowmanager") for loop prevention. AEM's WorkflowLauncherListener does not recognize that string. The correct value is "changedByWorkflowProcess", which matches HandlerBase.WORKFLOW_SESSION_USERDATA in com.adobe.granite.workflow.core and is the default member of the OSGi config property granite.workflow.launcher.globally.exluded.event.user.data that the launcher reads at startup. - SKILL.md: setUserData("workflowmanager") -> "changedByWorkflowProcess" in the loop-prevention guardrail (2 occurrences in same line) - condition-patterns.md: setUserData("workflowmanager") -> "changedByWorkflowProcess" in the Java snippet; rewrote the comment to correctly distinguish the OSGi config-property name from the userData value Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(aem-workflow): correct OOTB launcher names, excludeList format, and condition shorthand in workflow-launchers (AEM 6.5 LTS) Audit findings verified against AEM 6.5 LTS localhost:4505 OOTB launchers under /libs/settings/workflow/launcher/config/: - SKILL.md "Common OOTB Launchers" table: dam_update_asset_create does not exist (actual: update_asset_create); dam_update_asset_modify does not exist (actual: update_asset_mod); dam_xmp_writeback trigger description corrected to PROPERTY_CHANGED (eventType=16) on nt:unstructured at /jcr:content/metadata; update_page_version_* removed (not present in /libs, /conf, or /apps on a baseline 6.5 LTS install). Table expanded with eventType, nodetype, glob, and workflow columns - SKILL.md and launcher-config-reference.md: excludeList type corrected from String[] to String (single comma-separated value); description expanded to document the two entry formats — bare JCR property names and the event-user-data:<value> prefix that excludes events tagged with a specific JCR observation userData - launcher-config-reference.md: document the singular `condition` shorthand alongside the plural `conditions` array; both forms are accepted at startup - condition-patterns.md: loop-prevention comment rewritten to explain the changedByWorkflowProcess value via the customer-visible OSGi config property granite.workflow.launcher.globally.exluded.event. user.data (visible in Felix Console) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
15563e127a |
Feat/skill workflow model design 65 lts (#122)
* fix(aem-workflow): correct workflow-model-design XML format for /conf design-time (AEM 6.5 LTS) The workflow-model-design skill incorrectly showed cq:WorkflowModel / cq:WorkflowNode / cq:WorkflowTransition (runtime /var format) under the /conf design-time path. The Workflow Model Editor expects cq:Page + jcr:content/flow/<step-component> with nt:unstructured step nodes and sling:resourceType identifiers. A developer following the previous content would deploy a model the editor cannot open and Sync cannot process. Verified against AEM 6.5 LTS localhost:4505 OOTB models at /libs/settings/workflow/models/ and source at WorkflowSessionFactory.java:94 (MODELS_RUNTIME_LOCATION = "/var/workflow/models"). - model-xml-reference.md: full rewrite to cq:Page + flow/parsys format; design-time vs runtime table; cq:template fix to /libs/cq/workflow/templates/model; rewritten pitfalls section; runtime /var shape documented for reference - step-types-catalog.md: every step snippet converted to nt:unstructured + sling:resourceType; sling:resourceType reference table added; initiatorparticipant documented; transition XML removed (Sync derives transitions from step order) - model-design-patterns.md: Pattern 5 Task Manager XML corrected to flow-layer format; Pattern 6 variables annotated as runtime-only - SKILL.md: Sync verification added to checklist; /conf vs /var distinction note; filter.xml guidance updated Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(aem-workflow): correct AND_SPLIT/AND_JOIN/END resourceTypes in workflow-model-design (AEM 6.5 LTS) The step-types-catalog incorrectly listed sling:resourceType values for AND_SPLIT, AND_JOIN, and END that do not exist as design-time components on AEM 6.5 LTS. Verified against /libs/cq/workflow/components/model/ on localhost:4505. - sling:resourceType table: AND_split -> and (the actual OOTB component is named and, not AND_split); AND_join and end rows removed (no such components exist) - AND_SPLIT example: corrected sling:resourceType to cq/workflow/components/model/and; AND_JOIN inline example removed - AND_JOIN section: replaced manual <synchronize> example with a note that AEM Sync derives AND_JOIN nodes automatically at /var - END Node section: replaced manual <workflowend> example with a note that Sync derives both START and END automatically Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
962fd1dbee |
fix(replicate-content): condense SKILL.md to pass tessl-review (#119)
* fix(replicate-content): condense SKILL.md to pass tessl-review (#117) Rewrites replicate-content/SKILL.md from 840 lines to ~150 lines and adds three reference files so the skill passes the 50% tessl-review threshold. Changes: - Description: add explicit "Use when..." clause and trigger terms (publish, unpublish, replicate, content activation, dispatcher flush, AEM publish instance) to improve specificity and completeness scores - Body: condense all seven replication methods to 3-5 lines each with explicit ✓ Verify checkpoints; remove generic Best Practices, Security Considerations, and Success Criteria sections - Split detailed walkthroughs into references/ bundle files: - references/TREE_ACTIVATION.md (dry-run steps, performance guidance) - references/PACKAGE_REPLICATION.md (full package build/replicate flow) - references/REPLICATION_API.md (Java API, ReplicationOptions, curl with error handling, service user setup) Fixes #117 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(replicate-content): address quality review findings - CRITICAL: replace invalid XML service-user mapping with correct OSGi JSON config format (.cfg.json) in REPLICATION_API.md - HIGH: add REVERSE to ReplicationActionType table (was missing) - HIGH: add replication-api to Related Skills in SKILL.md - MEDIUM: add Only Activated option to Tree Activation summary to match TREE_ACTIVATION.md reference file - MEDIUM: fix head -n1 → sed '$d' in production curl script to handle multiline JSON responses without truncation - MEDIUM: add brief Asset Replication (DAM) section to SKILL.md - LOW: add Additional Resources section with official Adobe docs links Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Abhishek Garg <abhigarg+adobe@adobe.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
|
fcba900bc5 | refactor: rename the skills directory to plugins |