Invalid URL annotation generated with binary component

[jeffmaury]

[kind/bug]

What versions of software are you using?

• Operating System: Win10
• Output of odo version:

odo v1.0.0-beta5 (4d1d5071)     
                                
Server: https://172.18.84.5:8443
Kubernetes: v1.11.0+d4cacc0

How did you run odo exactly?

odo create java:8 bincomp --binary target\springboot-rest2-1.0.0-SNAPSHOT.jar --project bin --app binapp

Actual behavior

The generated annotation is:

app.openshift.io/vcs-uri: 'file:///target/springboot-rest2-1.0.0-SNAPSHOT.jar'

Expected behavior

Should be:

app.openshift.io/vcs-uri: 'file:target/springboot-rest2-1.0.0-SNAPSHOT.jar'

That would allow tooling (VSCode, IntelliJ) to use this annotation to import a component from the deployment.

Any logs, error output, etc?

[mohammedzee1000]

/kind bug
/priority high

[amitkrout]

The generated annotation is:
app.openshift.io/vcs-uri: 'file:///target/springboot-rest2-1.0.0-SNAPSHOT.jar'

@jeffmaury Where/how you got this annotation ?

[mohammedzee1000]

/state in-analysis

[amitkrout]

Got it, It just follow the local path protocol of file:/// on windows platform because the binary source being used is a local one.

[girishramnani]

@jeffmaury do you mean file:// vs file:/// because the later means its absolute path?

[jeffmaury]

I mean no / at all because it's a relative URL

[veillard]

ACK, it all depends on the context of the relative reference. if it's in a generated file and assuming the resource being pointed at is in the target subdirectory of where that file is placed then
target/springboot-rest2-1.0.0-SNAPSHOT.jar

but it really depends on the context of where that file containing that URI reference is located
See Section 4.1 of rfc 3986
https://www.ietf.org/rfc/rfc3986.txt

Problems: relative references are not defined for the file:// scheme , sucks isn't it :-)
the common usage is to convert file path with \ to / on Windows, try to avoid drive prefix as this finishes to screw things up !

[mik-dass]

@kadel @jeffmaury @girishramnani Should this issue also include the local components?

[kadel]

@jeffmaury

That would allow tooling (VSCode, IntelliJ) to use this annotation to import a component from the deployment.

Do you really need this annotation for local components? The information in this annotation doesn't provide enough information to do import no?
What is the use-case for importing a component from the deployment?

To be honest I would like to get rid of this annotation for binary and local components completely.
it is called vcs-uri but we store a local path in it.

@mik-dass It would be good to investigate if we even need this annotation for local and binary components. It doesn't make much sense to store a path that is on the local system on the cluster. odo should read this path from .odo/config.yaml.
For git component, it makes sense to store it in annotations as it can be useful for other tools like developer console.

If we can get rid of app.openshift.io/vcs-uri annotations I propose the following:

• make sure that app.openshift.io/vcs-uri is not read by odo anywhere
• stop adding app.openshift.io/vcs-uri annotation to local and binary components
• use app.openshift.io/vcs-uri annotation only for git component (we should be already doing it)

[mik-dass]

@mik-dass It would be good to investigate if we even need this annotation for local and binary components. It doesn't make much sense to store a path that is on the local system on the cluster. odo should read this path from .odo/config.yaml.
For git component, it makes sense to store it in annotations as it can be useful for other tools like developer console.

After some searching I found that the annotations app.openshift.io/vcs-uri is mostly used in testing, storing and displaying the path to the user. With some modification, I guess we can make the display tasks to use the local config/ context and use this only for git components as the path is anyways relative. @kadel @girishramnani