Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose Java Classpath #48

Open
ecmel opened this issue Jul 25, 2016 · 3 comments
Open

Expose Java Classpath #48

ecmel opened this issue Jul 25, 2016 · 3 comments

Comments

@ecmel
Copy link

ecmel commented Jul 25, 2016

Exposing Java classpath for the current workspace to the Java Script side can be very useful for other extensions. (https://code.visualstudio.com/docs/extensionAPI/vscode-api#_extensions)

akaroml pushed a commit to fbricon/eclipse.jdt.ls that referenced this issue Aug 30, 2017
* New debug adapter

Signed-off-by: Jinbo Wang <jinbwan@microsoft.com>

* refactor debug adapter

* Remove non-unicode chars in code

* Display error code in user message

* Refactor AdapterUtils

* fix review comments

* Remove the unnecessary cwd option from launch arguments

* Refactor the utility method name

* fix setVariable and evaluate error message

* Add explict id for ErrorCode enum class
@fbricon
Copy link
Contributor

fbricon commented Oct 10, 2017

We probably need to expose classpath per scope, i.e. compile vs test for Maven, but also runtime/provided.

For Gradle projects, scope is a more "open" notion, not only are the scopes named differently (compile, compileTest) but it's open to customization. We need a way to extract those informations from Buildship's APIs, ideally. @oehme, @donat any pointers?

@fbricon
Copy link
Contributor

fbricon commented Oct 10, 2017

Note: with Java 9's modulepath, we have an extra level of project dependencies

@donat
Copy link

donat commented Oct 13, 2017

@fbricon Actually, we're in the process of adding support separating scopes in the Eclipse runtime classpath. See the related issue and my feature branch. Basically, the idea is that the Gradle eclipse plugin produces extra classpath attributes describing dependency scopes:

Here's an example .classpath file:

<classpath>
    <classpathentry output="bin/main" kind="src" path="src/main/java">
        <attributes>
            <attribute name="gradle_scope" value="main"/>
            <attribute name="gradle_used_by_scope" value="main"/>
        </attributes>
    </classpathentry>
    <classpathentry output="bin/test" kind="src" path="src/test/java">
        <attributes>
            <attribute name="gradle_scope" value="test"/>
            <attribute name="gradle_used_by_scope" value="main,test"/>
        </attributes>
    </classpathentry>
    <classpathentry kind="con" path="org.eclipse.buildship.core.gradleclasspathcontainer"/>
    <classpathentry path="bin/default" kind="output"/>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8/"/>
    <classpathentry sourcepath="/Users/donat/.gradle/caches/modules-2/files-2.1/junit/junit/4.12/a6c32b40bf3d76eca54e3c601e5d1470c86fcdfa/junit-4.12-sources.jar" kind="lib" path="/Users/donat/.gradle/caches/modules-2/files-2.1/junit/junit/4.12/2973d150c0dc1fefe998f834810d68f278ea58ec/junit-4.12.jar">
        <attributes>
            <attribute name="gradle_used_by_scope" value="test"/>
        </attributes>
    </classpathentry>
</classpath>

The scope information is based on the source set names (main, test, integTest, etc). By using the scope information, Buildship can figure out which output folders and dependencies should be filtered from the runtime classpath.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants