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

Use a maven sample for the maven stack #15216

Open
tolusha opened this issue Nov 18, 2019 · 6 comments
Open

Use a maven sample for the maven stack #15216

tolusha opened this issue Nov 18, 2019 · 6 comments
Labels
area/devfile-registry 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. severity/P2 Has a minor but important impact to the usage or development of the system.

Comments

@tolusha
Copy link
Contributor

tolusha commented Nov 18, 2019

Is your enhancement related to a problem? Please describe.

We use the java sample [1] with a Grandle build-system by default for the java-maven stack [2].
It confuses and leads to such quesitons [3]

[1] https://github.com/che-samples/console-java-simple
[2] https://github.com/eclipse/che-devfile-registry/blob/master/devfiles/java-maven/devfile.yaml
[3] https://stackoverflow.com/questions/58863192/eclipse-che-workspace-wont-recognize-new-maven-dependencies

Describe the solution you'd like

Use a sample with maven build-system for the java-maven stack.

@tolusha tolusha added kind/enhancement A feature request - must adhere to the feature request template. team/languages area/devfile-registry labels Nov 18, 2019
@ibuziuk ibuziuk added the severity/P2 Has a minor but important impact to the usage or development of the system. label Nov 18, 2019
@tsmaeder
Copy link
Contributor

I don't mind the sample, but we need a way to force VS Code Java to use maven. Find out if we can use a preference in the devfile for this. Otherwise, remove the gradle support from the sample. Make sure console-simple is not used in our gradle stack

@tsmaeder tsmaeder mentioned this issue Dec 18, 2019
28 tasks
@tsmaeder tsmaeder mentioned this issue Jan 8, 2020
35 tasks
@tsmaeder tsmaeder mentioned this issue Jan 23, 2020
36 tasks
@tsmaeder tsmaeder mentioned this issue Feb 18, 2020
34 tasks
@JPinkney
Copy link
Contributor

JPinkney commented Mar 5, 2020

I wonder if we could just separate the maven and gradle parts into two different branches in the console-java-simple repo?

I've gone with this idea in:
https://github.com/JPinkney/console-java-simple/tree/gradle-java1.11
https://github.com/JPinkney/console-java-simple/tree/maven-java1.11

and then the corresponding update in the devfile registry:
https://github.com/JPinkney/che-devfile-registry/tree/seperate-maven-gradle

The only reason I'm advocating this way is that I personally always use this stack as a go-to if I'm ever doing something simple with java and it serves as a super easy starter template. Plus its rarely touched so the maintenance is almost non-existent

@tsmaeder
Copy link
Contributor

tsmaeder commented Mar 6, 2020

I would advocate against using branches: branches are for different development paths of the same thing. A maven and a console sample would warrant a different repo, IMO. Think of it this way: what would master contain? Maven or Gradle?

@JPinkney
Copy link
Contributor

JPinkney commented Mar 6, 2020

My idea was to be similiar to the che-sidecars where master would just be a readme that points to the maven/gradle branches but I know thats not ideal. But there's also a few other ways:

  1. Have console-java-maven and console-java-gradle repos
  2. Pick a different gradle stack and delete build.gradle from console-java-simple
  3. Pick a different maven stack and delete pom.xml from console-java-simple
  4. See if setting java.import.gradle.enabled: false in the devfile forces the language server to use maven. IMO it's probably confusing for the user to see both pom.xml and build.gradle in the same project

@tsmaeder Which one do you think we should go with?

@tsmaeder
Copy link
Contributor

tsmaeder commented Mar 9, 2020

I would go with 1. Repos are cheap, right?

@che-bot
Copy link
Contributor

che-bot commented Jan 4, 2021

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 Jan 4, 2021
@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 Jan 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/devfile-registry 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. severity/P2 Has a minor but important impact to the usage or development of the system.
Projects
None yet
Development

No branches or pull requests

7 participants