microcks import truncates Windows absolute paths when parsing :primary suffix

[hazelmayank]

Describe the bug

microcks import supports an optional :true / :false suffix to mark whether an imported artifact is the main artifact. However, the current parser at cmd/import.go:126 uses strings.Split(f, ":"), which also splits Windows-absolute paths on the drive-letter colon. A path such as:

C:\Temp\api.yaml

is therefore truncated to just C, and the remainder is treated as the boolean suffix — which then fails to parse, falls back to mainArtifact = true, and the upload step opens C (which does not exist).

---

Expected behavior

Windows-absolute paths should be preserved as full file paths.

C:\Temp\api.yaml should be parsed as:

path         = C:\Temp\api.yaml
mainArtifact = true

C:\Temp\api.yaml:false should be parsed as:

path         = C:\Temp\api.yaml
mainArtifact = false

The existing documented suffix behavior should continue to work for relative paths:

./api.yaml         -> path = ./api.yaml, mainArtifact = true
./api.yaml:true    -> path = ./api.yaml, mainArtifact = true
./api.yaml:false   -> path = ./api.yaml, mainArtifact = false

In short: the parser should be able to tell the drive-letter colon apart from the suffix-separator colon.

---

Actual behavior

The current parser splits on every colon and only ever inspects parts[1].

A Windows path like C:\Temp\api.yaml is parsed as:

parts        = ["C", "\Temp\api.yaml"]
path         = "C"
mainArtifact = true   (strconv.ParseBool fails on "\Temp\api.yaml", default is true)

A Windows path with an explicit suffix like C:\Temp\api.yaml:false is parsed as:

parts        = ["C", "\Temp\api.yaml", "false"]
path         = "C"
mainArtifact = true   (only parts[1] is read; the trailing "false" is never seen)

In both cases the subsequent upload fails with open C: no such file or directory, with no hint that the parser silently truncated the path.

---

How to Reproduce?

1. On Windows, place an OpenAPI file at C:\Temp\api.yaml.
2. Build the CLI: make build-local.
3. Run:

   ./build/dist/microcks.exe import C:\Temp\api.yaml --microcksURL http://localhost:8585

4. Observe the failure: open C: no such file or directory (sometimes preceded by Cannot parse '\Temp\api.yaml' as Bool, default to true).

The same shape of bug is reproducible on Linux/macOS by passing a path that contains a colon, e.g. path:with:colon.yaml.

---

Microcks version or git rev

No response

---

Install method (docker-compose, helm chart, operator, docker-desktop extension,...)

No response

---

Additional information

Root cause. cmd/import.go:125-131 parses each comma-separated entry by:

if strings.Contains(f, ":") {
    pathAndMainArtifact := strings.Split(f, ":")
    f = pathAndMainArtifact[0]
    mainArtifact, err = strconv.ParseBool(pathAndMainArtifact[1])
    ...
}

[hazelmayank]

Opened a PR with a parser helper and table-driven tests for Windows path handling in microcks import.