Skip to content

Generate alternatives#101

Merged
eladrion merged 18 commits into
Workflomics:feat_workflow_alternative_generationfrom
aaronstrachardt:generate-alternatives
Jul 3, 2026
Merged

Generate alternatives#101
eladrion merged 18 commits into
Workflomics:feat_workflow_alternative_generationfrom
aaronstrachardt:generate-alternatives

Conversation

@aaronstrachardt

Copy link
Copy Markdown

Pull Request Overview

This PR adds the backend logic for the "generate alternatives" prototype component. It basically introduces a new /alternatives/parse endpoint, a CWLParser class, and some helper logic to process the workflows.

Related Issue

No related issue yet.

Changes Introduced

  • Added snakeyaml dependency for lightweight CWL parsing.
  • Added CWLParser class to extract tools and connections from the CWL file.
  • Created new endpoint POST /alternatives/parse for the file uploads.
  • Added logic for lazy-loading and inverting the edam_labels.json to map URIs to readable labels.
  • Added basic error handling for the new endpoint (returning proper 400/500 status codes).
  • Introduced unit and integration tests for all new features.

How Has This Been Tested?

The code has been tested with the added unit tests (e.g., CwlParserTest, EdamLabelsTest). I also tested the whole flow manually on my local machine by connecting it to the corresponding frontend branch.

Checklist

  • I have referenced a related issue.
  • I have followed the project’s style guidelines.
  • My changes include tests, if applicable.
  • All tests pass locally.
  • I have added myself to the CITATION.cff file, if not already present.

@aaronstrachardt aaronstrachardt marked this pull request as draft June 29, 2026 09:38
@aaronstrachardt aaronstrachardt marked this pull request as ready for review June 29, 2026 09:38
@aaronstrachardt

Copy link
Copy Markdown
Author

@eladrion Here is the PR for restape. It seems that I don't have any rights to assign you as a reviewer, so I just tagged you.

@eladrion eladrion self-requested a review June 29, 2026 09:53

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aaronstrachardt: Is there a reason why you did not use the class TaxonomyElem for this purpose? It is not yet used but could fit here.

Comment thread src/main/java/nl/esciencecenter/controller/dto/GraphEdge.java
Comment thread src/main/java/nl/esciencecenter/controller/dto/GraphNode.java
Comment thread src/main/java/nl/esciencecenter/controller/dto/ParseResponse.java

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aaronstrachardt The SnakeYAML approach does work in principle and it was applied for some time in APE. But perhaps the specific CWL parser as used in APE could make things easier. I'm not completely sure but perhaps you could reuse the implementation from APE.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eladrion You're right that sharing one CWL parser would be cleaner and it wouldn't add a new dependency.

I checked APE's CWLParser class. The problem is that it only parses a single CommandLineTool, so I cannot reuse it as it is. Reusing it would be possible, but only with an extension to handle workflows.

I think I will stick with the current implementation and add the unified parser as future work. Does that sound okay to you?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is okay for now and I can test it as is.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aaronstrachardt Fitting approach and would probably work for a prototype. But we should look whether this could be stored in the database instead in a separate table. Nothing you should think about for your plans. Just an Issue I have to add after merging.

@eladrion

Copy link
Copy Markdown
Contributor

@aaronstrachardt: your branch is out-of-date with the Restape main branch. Can you rebase your branch and force-push? I cannot rebase since it is a private repo. And I'm not sure whether merging the last changes in main will be possible from my side.

Lombok annotation processing failed on JDK 21+ causing compilation
errors. Replaced @Getter, @Setter, @DaTa, @slf4j, @NoArgsConstructor,
@AllArgsConstructor, and @requiredargsconstructor with explicit
constructors, getters, setters, and SLF4J logger declarations.

# Conflicts:
#	src/main/java/nl/esciencecenter/controller/dto/WorkflowsZip.java
Adds GraphNode, GraphEdge, ApeTaxTuple, and ParseResponse DTOs used
by the /alternatives/parse endpoint. All fields have explicit getters
for Jackson serialization.
Loads the EDAM OWL ontology asynchronously at startup and builds an
inverted URI-to-label map for O(1) lookup. Falls back to the short-form
URI fragment while loading. Used to resolve format URIs in CWL
inputs/outputs to human-readable EDAM class names.
Parses a CWL v1.2 Workflow document using snakeyaml and produces a
graph-optimised ParseResponse: tool nodes, input/output data nodes,
directed data-flow edges, and EDAM I/O tuples for APE synthesis
constraints. EDAM format URIs are resolved via an injected label
resolver function.
Accepts a CWL v1.2 workflow as multipart/form-data, delegates to
CwlParser with EDAM label resolution, and returns a ParseResponse
with nodes, edges, and I/O EDAM tuples for the frontend graph view.
Reverts a051be8. Lombok 1.18.30 works correctly with Java 17; the
annotation-processing issues only affect JDK 21+. Project is now
pinned to java.version=17 via spring-boot-starter-parent.
Remove EDAMTaxonomyService (OWL API, async loading, AtomicReference fallback).
Bundle pre-built edam_labels.json (3471 entries, 227 KB) as classpath resource.
EdamLabels loads it synchronously at startup via Jackson — no network access,
no startup delay, no fallback labels.
Replace bundled edam_labels.json with live OWL fetch via EdamLabels.
ensureLoaded() blocks synchronously on first call (double-checked lock),
subsequent calls return immediately. Add GET /alternatives/warm so the
frontend can trigger loading on page mount before the first upload.
EDAM loading is triggered implicitly by the first /parse call.
A dedicated warm endpoint adds no value without a frontend consumer.
EdamLabels now reads the pre-generated edam_labels.json classpath resource
instead of fetching and indexing the EDAM OWL ontology at runtime. This makes
label resolution O(1), removes the runtime network dependency, and matches the
documented design. The required resource was previously untracked.
@aaronstrachardt aaronstrachardt force-pushed the generate-alternatives branch from a02a615 to 53640f4 Compare June 29, 2026 14:05
@aaronstrachardt

Copy link
Copy Markdown
Author

Hi @eladrion, I have rebased my branch against upstream/main. Everything should be good now, please let me know if you see any further issues :)

@eladrion

Copy link
Copy Markdown
Contributor

Hi @aaronstrachardt, rebasing resolved the sync issue. Thanks. Apart from that, I left you some comments above which still seem to be correctly referring to the files.

…e.java and ParseResponse.java and replace GraphNode's string type with a enum, as suggested in review.
@aaronstrachardt

Copy link
Copy Markdown
Author

Hi @eladrion, I implemented the suggested changes

  • reused TaxonomyElem and removed ApeTaxTuple
  • added the Lombok annotations (@Getter / @AllArgsConstructor) to GraphNode, GraphEdge and ParseResponse, like the other DTO's
  • replaced the String type in GraphNode with a NodeType enum (input / tool / output)

@eladrion

eladrion commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Hi @aaronstrachardt,

the docker image generation will not work here as the PR source is a non-group repository (and private). I created a branch feat_workflow_alternative_generation in this repo. Can you change the Base in your PR configuration to this feature branch? Also, please add your info to the citation.cff.

@eladrion

eladrion commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

I see, your repo is public. But still, your PR is better located to the feature branch.

@eladrion eladrion changed the base branch from main to feat_workflow_alternative_generation July 3, 2026 07:27
@eladrion

eladrion commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Nevermind, could do it myself

@eladrion

eladrion commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

I will merge to the feature branch for now

@eladrion eladrion merged commit 7b883d0 into Workflomics:feat_workflow_alternative_generation Jul 3, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants