[NAE-2302] Check for process plugin dependencies on deploy

[SamuelPalaj]

Description

• added parsing of pluginDependencies from action to Importer.java
• added pluginDependencies attribute to PetriNet.java

Implements NAE-2302

Test Configuration

Name	Tested on
OS	windows 10
Runtime	java 21
Dependency Manager	Maven 3.9.9
Framework version	Spring Boot 3.4.4
Run parameters
Other configuration

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes have been checked, personally or remotely, with @...
• I have commented my code, particularly in hard-to-understand areas
• I have resolved all conflicts with the target branch of the PR
• I have updated and synced my code with the target branch
• I have added tests that prove my fix is effective or that my feature works
• New and existing tests pass locally with my changes:
  • Lint test
  • Unit tests
  • Integration tests
• I have checked my contribution with code analysis tools:
  • SonarCloud
  • Snyk
• I have made corresponding changes to the documentation:
  • Developer documentation
  • User Guides
  • Migration Guides

Summary by CodeRabbit

• New Features
  • Added automatic plugin dependency detection and tracking to identify all plugins referenced in workflow definitions, enabling better plugin management and dependency resolution throughout the system.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The changes introduce plugin dependency extraction from PetriNet action definitions during the import process. A regex pattern identifies plugin references within action definitions, collects unique plugin names, and stores them in the PetriNet domain object.

Changes

Cohort / File(s)	Summary
Plugin dependency extraction in Importer application-engine/src/main/java/com/netgrif/application/engine/importer/service/Importer.java	Added regex constants (PLUGIN_STRING_REGEX and PLUGIN_STRING_PATTERN) and new protected method extractPluginDependencies() to scan action definitions and collect unique plugin identifiers into a Set. Integration points added to invoke extraction after actions evaluation during PetriNet creation.
Plugin dependencies field in PetriNet domain nae-object-library/src/main/java/com/netgrif/application/engine/objects/petrinet/domain/PetriNet.java	Added new public field pluginDependencies of type Set with Lombok-generated accessors. Initialized as empty HashSet in no-arg constructor and properly copied in copy constructor.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Review regex pattern for correctness and coverage of plugin reference formats
• Verify extractPluginDependencies() logic handles edge cases (null/empty actions)
• Confirm both invocation points in Importer are appropriate and complete
• Check PetriNet field initialization and copy constructor implementation

Suggested labels

improvement, Medium

Pre-merge checks

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main changes: extracting plugin dependencies from process actions and storing them in PetriNet for deployment verification.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0ba6fe9 and 3feadb1.

📒 Files selected for processing (2)

• application-engine/src/main/java/com/netgrif/application/engine/importer/service/Importer.java (4 hunks)
• nae-object-library/src/main/java/com/netgrif/application/engine/objects/petrinet/domain/PetriNet.java (3 hunks)

🧰 Additional context used

🧠 Learnings (2)

📚 Learning: 2025-07-29T17:19:18.300Z

Learnt from: tuplle
Repo: netgrif/application-engine PR: 331
File: application-engine/src/main/java/com/netgrif/application/engine/elastic/service/ElasticPetriNetService.java:45-46
Timestamp: 2025-07-29T17:19:18.300Z
Learning: In ElasticPetriNetService class, petriNetService is properly initialized using Lazy setter injection rather than constructor injection. This pattern with Lazy Autowired setter methods is commonly used in Spring to resolve circular dependencies and is a valid alternative to constructor injection.

Applied to files:

• nae-object-library/src/main/java/com/netgrif/application/engine/objects/petrinet/domain/PetriNet.java

📚 Learning: 2025-07-31T23:40:46.499Z

Learnt from: tuplle
Repo: netgrif/application-engine PR: 334
File: application-engine/src/main/java/com/netgrif/application/engine/petrinet/service/PetriNetService.java:204-214
Timestamp: 2025-07-31T23:40:46.499Z
Learning: In the PetriNetService.importPetriNet method, existingNet.getVersion() cannot be null because all existing nets in the system were deployed through processes that ensure every net always has a version assigned.

Applied to files:

• nae-object-library/src/main/java/com/netgrif/application/engine/objects/petrinet/domain/PetriNet.java

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Test

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Plugin dependency field looks good; consider defensive copy in copy constructor

The new pluginDependencies field and its initialization in the default constructor are fine and align with the new Importer behavior.

In the copy constructor, though, this.pluginDependencies = petriNet.getPluginDependencies(); reuses the same mutable Set instance, which can lead to surprising shared mutations between the original and the copy, and it does not guard against a null value.

Consider defensively copying and null‑guarding here:

-        this.pluginDependencies = petriNet.getPluginDependencies();
+        Set<String> sourcePlugins = petriNet.getPluginDependencies();
+        this.pluginDependencies = sourcePlugins != null
+                ? new HashSet<>(sourcePlugins)
+                : new HashSet<>();

This keeps the field non‑null and avoids accidental cross‑net coupling via a shared set.

Also applies to: 164-165, 200-200

🤖 Prompt for AI Agents

In
nae-object-library/src/main/java/com/netgrif/application/engine/objects/petrinet/domain/PetriNet.java
around lines 137-139 (and also update similar assignments at 164-165 and 200),
the copy constructor assigns the pluginDependencies reference directly from the
source object, risking shared mutable state and possible NPE; change these
assignments to create a defensive copy and null-guard the source (e.g., if
source.getPluginDependencies() is null, assign a new empty Set, otherwise assign
a new Set constructed from the source) so the copy has its own non-null
collection instance.

[Retoocs]

No need for @Transactional. This annotations have been removed in another task on the pull request.

There is no database interaction in the method