github / github/copilot-cli

Better Java/JVM ecosystem awareness — framework conventions, LSP config, and build tool detection

Aberta
#1,349 3 comentários 0 reações 0 responsáveis Ver no GitHub
area:configuration area:enterprise area:tools
Linguagem predominante
Shell
Estrelas
11.2k
Forks
1.9k
Merge médio
14h 16min
PRs com merge (30d)
6

Descrição

## Describe the feature or problem you'd like to solve

Copilot CLI's documentation and intelligence is heavily TypeScript/JavaScript-oriented. The README's LSP section only shows TypeScript examples, with no guidance for Java — one of the most widely used enterprise languages. JVM developers using frameworks like Micronaut, Spring Boot, or Quarkus need the CLI to understand framework-specific conventions to be genuinely useful as an agentic coding assistant.

As a Java architect working with Micronaut microservices and Gradle multi-module builds, I'd like Copilot CLI to have first-class awareness of JVM project structures and framework conventions.

## Proposed solution

### 1. Java LSP configuration example in README
The `lsp-config.json` section only shows TypeScript. Add a Java example using jdtls (Eclipse JDT Language Server), which is the standard Java LS used by VS Code and other editors:
```json
{
"lspServers": {
"java": {
"command": "jdtls",
"args": ["-data", "/tmp/jdtls-workspace"],
"fileExtensions": {
".java": "java"
}
}
}
}
```

### 2. Build tool detection
Auto-detect the project's build system and use the correct wrapper/tool:
- `./gradlew` / `gradlew.bat` → Gradle wrapper (preferred over system `gradle`)
- `mvnw` / `mvnw.cmd` → Maven wrapper (preferred over system `mvn`)
- `build.gradle.kts` / `build.gradle` → Gradle project
- `pom.xml` → Maven project

Currently, the agent may run `gradle` or `mvn` directly instead of the project-local wrappers, which can use the wrong version or miss project-specific configuration.

### 3. Framework convention awareness
JVM frameworks are heavily convention and annotation-driven. The CLI should understand:

**Micronaut:**
- `@Singleton`, `@Controller`, `@Client`, `@Factory` — DI and HTTP patterns
- `application.yml` / `application-{env}.yml` — environment-specific config
- `@MicronautTest` — test lifecycle

**Spring Boot:**
- `@RestController`, `@Service`, `@Repository`, `@Configuration` — layered architecture
- `application.properties` / `application-{profile}.yml` — profile-based config
- `@SpringBootTest`, `@WebMvcTest` — slice testing

**Common JVM patterns:**
- `src/main/java` / `src/test/java` — standard Maven/Gradle layout
- `src/main/resources` — config and static resources
- Package naming conventions mapping to directory structure

### 4. Multi-module project navigation
Enterprise Java projects are almost always multi-module. The CLI should:
- Parse `settings.gradle.kts` / `settings.gradle` / parent `pom.xml` to understand module boundaries
- Run module-scoped commands: `./gradlew :module-name:test` instead of `./gradlew test`
- Navigate between API and implementation modules

## Example prompts or workflows

1. **"Add a new REST endpoint for /api/v1/rewards with request validation"** → generates correct Micronaut/Spring-specific controller code with framework annotations, not generic Java
2. **"Run the tests for the linking-service module"** → executes `./gradlew :linking-service:test` (not `gradle test` or `./gradlew test`)
3. **"Show me all the HTTP clients in this project"** → finds `@Client` annotated interfaces (Micronaut) or `RestTemplate`/`WebClient` usages (Spring)
4. **"Add a new configuration property for the retry timeout"** → adds to the correct `application.yml` with framework-appropriate syntax
5. **"Create an integration test for the account service"** → uses `@MicronautTest` or `@SpringBootTest` depending on the framework detected

## Additional context

- Java consistently ranks in the top 3 languages on GitHub and is the dominant language in enterprise development
- The JVM ecosystem (Java, Kotlin, Scala) shares build tools (Gradle, Maven) and project conventions
- VS Code Copilot Chat already has some Java awareness via the Java extension pack — parity in the CLI would benefit the large population of terminal-first Java developers
- Kotlin DSL (`build.gradle.kts`) is now the default for new Gradle projects and should be understood alongside Groovy DSL

Guia de contribuição

Abrir o guia de contribuição

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.