Provide Document Lifecycle Participant for tracking didOpen, did*

[mickaelistria]

As we're working on the Maven extension, we'd like to keep in cache the built MavenProject model for files that are currently open, and to discard this MavenProject when files are closed.
I did look through the extension API and didn't find a way to listen to open/close. Is there a way to do that I missed, or is no solution implemented (yet)?

[angelozerr]

I did look through the extension API and didn't find a way to listen to open/close. Is there a way to do that I missed, or is no solution implemented (yet)?

It's not implemented because today we had not this usecase. If I understand correctly, you need to track didOpen and didClose (and perhaps didChange ?) of text document service.

But I wonder if why you could not track those open/close files with Eclipse API (IResource listener?)

[mickaelistria]

I don't think I need didOpen as we can lazily populate cache on 1st request to diagnostics, hover or whatever.
I don't think I need didChange because when receiving a request (onComplete, onDiagnostics...) we do look at document.getTextIndentifier().getVersion() to know whether we need to refresh the cache.
But for didClose, I didn't figure out a possible workaround.

[angelozerr]

@mickaelistria I understand that you don't need didChange or didOpen for your usecase but I would like to provide a clean API like TextDocumentLifecycleParticipant to track didOpen, didChange and didClose. Instead having a simple URI, we could set in the parameter the DOMDocument which stores the URI.

[mickaelistria]

Ok, as you wish. However, beware that implementing APIs without use-case doesn't usually lead to clean APIs ;)

[angelozerr]

Ok, as you wish. However, beware that implementing APIs without use-case doesn't usually lead to clean APIs ;)

Yes you are right :) But my fear is to have a lot of participant as soon as we need a usecase. So perhaps we could start with TextDocumentLifecycleParticipant and provide only didClose method? What do you think about that?

[mickaelistria]

That would work for me and be less work for you (and less things to change later if this needs to be refactored).

[angelozerr]

@mickaelistria please keep in mind that LSP4XML should move to Eclipse.org and package name will be renamed (soon I hope)