You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Meta issue tracking potential improvements for Java code generation in Schema Salad.
Make usable project for "The Common Workflow Language" specifications.
The auto-generated code for CWL doesn't include the version - something needs to be parameterized better.
Generate actual packages for CWL 1.0, CWL 1.1 - publish to Github & mvn central.
A ton of typing stuff could/should be better.
Can array fields return something more specific than List<Object>, I tried a naive thing (List<T> for Loader<T>) but it broke down on inheritance. Interface on Process defines List<InputParameter> without parameterization prevents Workflow from return List<WorkflowInputParameter>? Would parameterizing all the abstract types be good enough? Process<I extends InputParameter>Workflow<WorkflowInputParameter> but for all the specialization? Can non-abstract parameters be specialized in subtypes in schema salad - because I guess that would breakdown this...?
Generate UnionOf2, UnionOf3, etc... as needed. Re-enable OneOrListOf types disabled in Random assorted cleanups for Java codegen #304. This way everything is uniformly handled. Probably makes sense to wait on the improved collection types mentioned at the top of this list first though - otherwise Object is probably more straight-forward.
JavaDoc Tasks
Add schema docs to JavaDocs wholesale.
Refactor makedoc to be callable from codegen with same parameters.
Generate docs and relocate into JavaDocs in generated project.
Trim down styling needed to be compatible with JavaDocs.
Throw more schema documentation from specification into the JavaDocs on fields, classes, etc...
Improve styling and such of schema doc quotes.
Render schema doc Markdown into JavaDoc compatible HTML before embedding them into JavaDocs
Add schema docs to enumerated types, anonymous enum types.
Link namespace references in JavaDocs to packaged schema docs.
Other Java Plumbing Tasks
fetchText is broken - so test case for that and implementation.
Cache schemae like the Python code.
Implement serialization/writing (Iterate on Java codegen #299 implemented reading and validation, but hasn't touched writing yet even though the interface is called Savable).
Re-do all loading as Jackson mapping somehow. https://www.baeldung.com/jackson-annotations. My recollection of Java land is that it is gross that these aren't just POJOs and even grosser that there is parsing logic in the constructors. The Impl classes should be usable on their own (maybe start with just adding a default constructor) - still we probably want to tie into Jackson - to make them really de-coupled from parsing and usable in APIs, etc...
Pluggable YAML reading (add interface, allow setting from LoadingContext).
Better project structure - utils should probably be unchanging stuff we could someday package up, loaders in their own module.
The text was updated successfully, but these errors were encountered:
Meta issue tracking potential improvements for Java code generation in Schema Salad.
Make usable project for "The Common Workflow Language" specifications.
A ton of typing stuff could/should be better.
List<Object>
, I tried a naive thing (List<T>
forLoader<T>
) but it broke down on inheritance. Interface on Process definesList<InputParameter>
without parameterization prevents Workflow from returnList<WorkflowInputParameter>
? Would parameterizing all the abstract types be good enough?Process<I extends InputParameter>
Workflow<WorkflowInputParameter>
but for all the specialization? Can non-abstract parameters be specialized in subtypes in schema salad - because I guess that would breakdown this...?JavaDoc Tasks
Other Java Plumbing Tasks
Savable
).The text was updated successfully, but these errors were encountered: