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

Force Maven Devfiles to use Maven #16066

Open
tsmaeder opened this issue Feb 18, 2020 · 9 comments
Open

Force Maven Devfiles to use Maven #16066

tsmaeder opened this issue Feb 18, 2020 · 9 comments
Labels
area/languages Issues related to Language extensions or plugins integration. kind/enhancement A feature request - must adhere to the feature request template. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. status/info-needed More information is needed before the issue can move into the “analyzing” state for engineering.

Comments

@tsmaeder
Copy link
Contributor

Right now, our Maven devfile uses an example that also has a build.gradle. This will, in fact not be imported as a Maven project in jdt.ls, but as a Gradle project (Gradle has precedence).
There is preference in VS Code Java (something like "gradle.importer.enabled") that we can turn to false in the devfile in order to force use of Maven.

@tsmaeder tsmaeder added kind/enhancement A feature request - must adhere to the feature request template. area/languages Issues related to Language extensions or plugins integration. labels Feb 18, 2020
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Feb 18, 2020
@benoitf
Copy link
Contributor

benoitf commented Feb 18, 2020

IMHO issue is that both maven and gradle examples are using the same github project.
so maybe we could have two projects/repositories: one with pom.xml and the other one with build.gradle

To me it's strange to turn false something while for a maven example I don't expect to see any gradle stuff in the project tree.

@tsmaeder
Copy link
Contributor Author

@benoitf there is a separate issue for "use maven project for maven devfile". But it would still make sense to force use of maven with a maven stack.

@benoitf
Copy link
Contributor

benoitf commented Feb 18, 2020

@tsmaeder yes makes sense on general purpose but the description of the issue is specifically about the example used in maven stack and then for the specific maven example it should not include any gradle file.

@l0rd
Copy link
Contributor

l0rd commented Feb 19, 2020

I agree with @benoitf that to solve the specific issue (maven sample) we should split the sample in 2: one dedicated to maven and the other to gradle. And if there is already an issue about that (this one?) I don't understand what this issues is about ("force use of maven with maven stack"?)

@l0rd l0rd added status/info-needed More information is needed before the issue can move into the “analyzing” state for engineering. and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Feb 19, 2020
@tsmaeder
Copy link
Contributor Author

If we have a project that has both maven and gradle configs (which is quite common), jdt.ls will pick gradle. This might not be the right thing to do. If we have a stack that is made for maven, we should always force usage of maven in the tooling (because that's what will be used in the dev container).

@l0rd
Copy link
Contributor

l0rd commented Feb 19, 2020

@tsmaeder ok so your proposal is to update the java-maven devfile in the registry to include the jdt ls option gradle.importer.enabled=false. I am ok with that as well and that would solve the original issue of #16051.

@tsmaeder
Copy link
Contributor Author

Well, for small values of "fix". Since gradle support is totally broken for new workspaces right now. We'll get a new release of VS Code Java later today where the issue is fixed and should update to that.

@l0rd
Copy link
Contributor

l0rd commented Feb 19, 2020

@tsmaeder yes but the original issue is about using maven not gradle. And the difference is important since it's part of the happy path test that's used in all our PR checks.

@che-bot
Copy link
Contributor

che-bot commented Aug 21, 2020

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 21, 2020
@ericwill ericwill added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Aug 21, 2020
@ericwill ericwill added this to the Backlog - Plugins milestone Aug 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/languages Issues related to Language extensions or plugins integration. kind/enhancement A feature request - must adhere to the feature request template. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. status/info-needed More information is needed before the issue can move into the “analyzing” state for engineering.
Projects
None yet
Development

No branches or pull requests

5 participants