dkpro/dkpro-meta

Collect metadata about DKPro Core and put it to use, e.g. to automatically generate documentation or wrappers for integration with other tools and frameworks.

dkpro-meta's Issues

Multi-value parameters not supported in tool wrappers

Multi-value parameters are not properly interpreted in the tool wrappers.

Apparently, Galaxy encodes multiple values by separating the values with __cn__, e.g.

... -patterns, +*.txt__cn__-lala.txt, ...

Version is "." for models built using 'install-model-stub'

Version is . for models built using install-model-stub. The 'install-model-stub' doesn't have metaDataVersion and upstreamVersion, but only simply version.

Avoid models being associated with trainer components

Avoid models being associated with trainer components

Update dependencies (0.2.0)

Update Groovy dependencies and plugins

Upgrade dependencies (0.4.0)

Component languages not properly sorted

Component languages not properly sorted when sort() is applied.

Handle change in DKPro Core package names

The automatic linking between models and components needs to account for the recent changes to the DKPro Core package names.

Write CAS in binary format, not in XMI

The XMI writer always creates two files (xmi + type system). Would be nicer if it created just one. Binary CAS gives us that and creates smaller files.

Recognize "depparser" as a separate tool name

Recognize "depparser" as a separate tool name, but still conflate it under the "Parser" heading.

UDPipe PosTagger miscategorized as morphological analyzer

UDPipe PosTagger is miscategorized as morphological analyzer because it also creates morphological features. However, we should probably consider it rather as a POS Tagger (hence the component name ends in PosTagger) or rename the component...

Models build with "install-model-stub" not detected

Models build with "install-model-stub" not detected as models.

Handle "lemma" as well as "lemmatizer" as tool names

Handle "lemma" as well as "lemmatizer" as tool names - although "lemma" should be preferred from now on for new components/models.

Allow running from IDE

Set the basedir property to allow running the code from the IDE.

Allow processing multiple files

The idea is to set the multiple flag on the input parameter of the engine, then in the tool XML file write all the input file names to a temporary file, and that temporary file is then passed as a parameter to the tool wrapper groovy script. The Groovy script would then read this temporary file and pass all the file names to PARAM_PATTERNS. The resulting files would then need to be discovered.

• need to check if the input files that galaxy provides are simple file names (such that we can use PARAM_SOURCE_LOCATION) or absolute files
• need to check if we can write the results all to some directory using PARAM_TARGET_LOCATION

Source and target parameters for I/O components should be suppressed

Source and target parameters for I/O components should be suppressed such that the Galaxy user cannot override them and access arbitrary files on the Galaxy host.

Likewise, PARAM_OVERWRITE should be suppressed to avoid users overwriting files on the Galaxy host.

Parser model attaches to StanfordDependencyConverter

Presently some parser models, e.g. de.tudarmstadt.ukp.dkpro.core.stanfordnlp-model-parser-de-pcfg wrongly attach to the StanfordDependencyConverter component.