annotation processor does not run correctly before running the test.

Java Debugger extension version:v0.46.0

NoSuchBeanDefinitionException is raised and the test fails to run.

To work around this, the results of the gradle run are added to classPaths.
Is there a better way to specify classPaths, as the control of classPaths becomes more complicated when we have subprojects.

settings.json:

  "java.test.defaultConfig": "custom",
  "java.test.config": [
    {
      "preLaunchTask": "compileJava",
      "name": "custom",
      "classPaths": [
        "${workspaceFolder}/build/classes"
      ]
    }
  ]

tasks.json:

{
  "tasks": [
    {
      "label": "compileJava",
      "type": "shell",
      "command": "gradlew compileJava",
      "options": {
        "cwd": "${workspaceFolder}"
      }
    }
  ]
}

I tried copy to bin by gradle.
It is working in the environment at hand.
I am forcing a copy to the bin directory, but does that seem to be a problem?

settings.json:

  "java.test.defaultConfig": "custom",
  "java.test.config": [
    {
      "preLaunchTask": "compileJava",
      "name": "custom",
  //    "classPaths": [
  //     "${workspaceFolder}/build/classes"
  //    ]
    }
  ]

tasks.json:

{
  "tasks": [
    {
      "label": "compileJava",
      "type": "shell",
      "command": "gradlew copyToBin",
      "options": {
        "cwd": "${workspaceFolder}"
      }
    }
  ]
}

build.gradle:

task copyToBin(type: Copy) {
  dependsOn compileJava
  from 'build/classes/java/main'
  into 'bin/main'
}

The problem sounds like that the compiled output from language server and gradle command line are different.

Is it possible to share a sample project?

I am trying it out on this project.

https://github.com/uk-taniyama/spring-doma

Turning "preCheckTask" on and off can be controlled in the Makefile.

We are actually working on the annotation processor support for the Gradle project: eclipse-jdtls/eclipse.jdt.ls#2319

And I can see the generated sources:

But after I imported the project, I saw some other errors:

Anything I missed?

We are actually working on the annotation processor support for the Gradle project: eclipse-jdtls/eclipse.jdt.ls#2319

Can i use this one?

Anything I missed?

".sql" files are stored under resources.
In gradle, i control the ability to reference under resources.

ext.domaResourcesDir = "${buildDir}/tmp/doma-resources"

task extractDomaResources(type: Copy, dependsOn: processResources)  {
  from processResources.destinationDir
  include 'doma.compile.config'
  include 'META-INF/**/*.sql'
  include 'META-INF/**/*.script'
  into domaResourcesDir
}

task copyDomaResources(type: Copy, dependsOn: extractDomaResources)  {
  from domaResourcesDir
  into compileJava.destinationDir
}

It would simply solve the problem if the "gradle build" was executed.

Can I use this one?

It will be available in the pre-release version once it's merged. I directly launched with that PR to test the sample project.

I manually copied the META-INF folder into bin/default and triggers a full build, then I could see the code generation works well:

There are a few test cases fail, but I guess that are related with some environment issues?

Anyway, I'll let you know once the upstream change is merged.

It will be available in the pre-release version once it's merged. I directly launched with that PR to test the sample project.
I manually copied the META-INF folder into bin/default and triggers a full build, then I could see the code generation works well:

Is there any good way to make this place automatic?

Would copying it with preLaunchTask solve the problem?
It would be faster than the current "gradle build" call.

There are a few test cases fail, but I guess that are related with some environment issues?

sorry. this is my problem.

DaoTestBase.java jdbc url is "mem", but not setup db in test.

    // url = "jdbc:h2:mem:db;MODE=PostgreSQL;DB_CLOSE_DELAY=-1";
    url = "jdbc:h2:file:./work/db/db;MODE=MySQL";

Is there any good way to make this place automatic?

It should be only needed for once I think, because the incremental build should not remove them. But you may need to do it again if the content is changed.

As you may have noticed that the extension compiles the class file into bin folder instead of the build folder (which is the target folder when running gradle build from command line). Many problems are caused by this, and I think the META-INF folder in your project is another example. We will consider fixing this in the future.

For the annotation processor, looks like the PR mentioned above is very promising.

Is there any good way to make this place automatic?

It should be only needed for once I think, because the incremental build should not remove them. But you may need to do it again if the content is changed.

I don't really want to do it manually because I often forget......

| For the annotation processor, looks like the PR mentioned above is very promising.

Looking forward to it.

then i try adding classPaths and see if it works:

  "java.test.config": [
    {
      "classPaths": [
        "${workspaceFolder}/src/main/resources/"
      ],
      "env": {
        "SPRING_PROFILES_ACTIVE": "test"
      },
      "workingDirectory": "${workspaceFolder}"
    }
  ],

then i try adding classPaths and see if it works

Maybe not. That setting is only used when launching the tests. But code generation from annotation processors happens during the complation phase. Looks like those .sql files are required the generate the source code. otherwise, the classes under dao will not be generated from my observation.

What's the workflow when you running them in other IDEs?

| What's the workflow when you running them in other IDEs?

Just call gradle in Android Studio (IntelliJ IDEA).

16:07:03: Task execution finished ':test --tests "com.example.dao.MstEmployeeDaoTest.testSelectOne"'.

I see. Because IDEA delegate the test execution to Gradle. And we are considering introducing that feature as well: #1045

Thank you for your response.
I look forward to seeing the finished product.

Is there any good way to make this place automatic?

It should be only needed for once I think, because the incremental build should not remove them. But you may need to do it again if the content is changed.

I don't really want to do it manually because I often forget......

| For the annotation processor, looks like the PR mentioned above is very promising.

Looking forward to it.

then i try adding classPaths and see if it works:
  "java.test.config": [
    {
      "classPaths": [
        "${workspaceFolder}/src/main/resources/"
      ],
      "env": {
        "SPRING_PROFILES_ACTIVE": "test"
      },
      "workingDirectory": "${workspaceFolder}"
    }
  ],

Thank you SO much for this configuration fix! We are having a similar issue where our test/resources/application.yml sets up our H2 in-memory database instead of the mysql setup in our main/resources/application.yml. The vscode gradle plugin and running in our terminal uses the correct application.yml but the test plugin does not....until we added the below config.

 "classPaths": [
         "${workspaceFolder}/src/test/resources/"
      ],

If you're trying to set the active profile, we did that in the tests with @ActiveProfiles("test"). Thank you!!

The Gradle Test Delegation (both run and debug) has supported now.

To use this feature, you need to install the latest Test Runner for Java and Gradle for Java extension.

To delegate the tests to Gradle, you can set the default testing profile in Testing explorer:

If you do not want to change the default testing profile, you can trigger an one-time execution via:

Navigation Menu

Repository navigation

annotation processor does not run correctly before running the test. #1508

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

annotation processor does not run correctly before running the test. #1508

Description

Activity

uk-taniyama commented on Nov 21, 2022

jdneo commented on Nov 22, 2022

uk-taniyama commented on Nov 22, 2022

jdneo commented on Nov 23, 2022

uk-taniyama commented on Nov 23, 2022

jdneo commented on Nov 23, 2022

uk-taniyama commented on Nov 23, 2022

jdneo commented on Nov 23, 2022

uk-taniyama commented on Nov 23, 2022

jdneo commented on Nov 23, 2022

uk-taniyama commented on Nov 23, 2022

jdneo commented on Nov 23, 2022

uk-taniyama commented on Nov 23, 2022

lmgillaspie commented on Jan 12, 2023

jdneo commented on Aug 5, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions