Introduce dev only resource directory support

[josephearl]

Description

I would like to be able to put resources or code that is used only in dev mode into a source folder that is only added to the classpath for dev mode, ie src/quarkusDev (src/quarkusDev/java, src/quarkusDev/resources etc)

At the moment I am able to add dependencies specifically for dev mode, but it seems not code or resources.

It might be nice to also have these added to the test classpath.

Implementation ideas

No response

[quarkus-bot[bot]]

/cc @glefloch, @quarkusio/devtools

[josephearl]

I'm using Gradle so that's what I care about personally - but I think this should be implemented the same across build tools

[glefloch]

Thanks for reporting this @josephearl. Have you some examples of code you would put there? @aloubyansky, @stuartwdouglas what do you think of that?

[josephearl]

Flyway migrations would be one example for resources - I’d like to have a DB populated with some useful data for devs to play around with the service, but don’t need/want these migrations for production.

Another example would be overriding certain beans with different implementations suitable for a local dev environment - there’s no need for this code to be bundled into the production application.

[geoand]

Sounds like an interesting feature!

[aloubyansky]

Can't you do this configuring custom source directories in Gradle for the quarkusDev task? And using profiles in Maven? E.g. -Dqdev that would a dependency on a module that contains the sources/resources you need? Or are you after a better user experience? Could you clarify the details? FYI @famod

[glefloch]

From a gradle point of view, I think we can easily allow that creating source set instead of a configuration for ˋquarkusDev`

[josephearl]

@aloubyansky How would you do that? I know I can define a source set like e.g.:

sourceSets {
  quarkusDev {
    compileClasspath += sourceSets.main.output
    runtimeClasspath += sourceSets.main.output
    java {
    }
  }
}

but unsure how to link that into the quarkusDev task?

I think (for Gradle) a better user experience would be great to have this feature out of the box.

[aloubyansky]

@josephearl I haven't actually experimented with it and it might not work. It was just a question. I was thinking it could potentially be done defining an extra named source set, similar to what you sketched above. Could the name of a sourceSet serve as an artifact classifier? Having that in place, could you add a dependency on project(":myapp:quarkusDev")? We have quarkusDev configuration where you could possibly add that extra dependency.

[aloubyansky]

@glefloch @josephearl did I make any sense? I was just trying to figure out what options are currently available. Otherwise, I think it'd be a good idea to look into it.

[glefloch]

@aloubyansky that could work if you register the sourceset in a custom variants. This will produce a new artifact that can be requested. I think we can look a bit more a it, by either creating a custom source set and adding to the main source set in dev mode or by looking into feature variants.

[HknLof]

Having a similar request. The use case is ... that some features need to be packaged into a different container, but in development it would be great to have quarkusDev working with all sourceSets.

This is what I've got so far. But do not know how to integrate the sourceSet into quarkusDev. Does quarkus-gradle-plugin expose any interface to add these sources to the compileClasspath?

sourceSets {
    quark {
        compileClasspath += sourceSets.main.output
        runtimeClasspath += sourceSets.main.output
    }
}

configurations {
    quarkImplementation.extendsFrom implementation

    quarkCompileOnly.extendsFrom compileOnly
    quarkRuntimeOnly.extendsFrom runtimeOnly
}

[HknLof]

Out of curiosity, what would be the best practice to add an endpoint conditionally and from a seperate jar / quarkus project?

[aloubyansky]

@HknLof please use a dedicated channel to ask these kind of questions (github or zulip). You are commenting on an issue report that is not related to your question.

[michalovjan]

I've recently encountered an issue where this feature would have been a great solution. I depend strongly on infinispan, and I have a simple cache configuration that is enough to test and run the application. Unfortunately, the only way to specify the cache configuration in application.properties is by either inlining the entire XML file or referencing the XML as a resource.

For testing, it is great because I can put the XMLs into test/resources and reference them in application.properties but for dev mode, where I would like this configuration also applied, neither option is valid. If I want to reference it as a resource, I'd have to put it into main/resources, which would end up in the production jar. The other option is inlining which would clutter the application.properties significantly.

Having dev-mode resources would solve this issue. Or have the option to use test-resources in dev-mode.

[lecogiteur]

Same issue for me. Today we can create some Quarkus profile with custom configuration for each profile. But for a Quarkus profile we can't add or remove some resources of classpath and release (today all resources must be in src/main/resources and added to prod release).

(Trick with maven profile: https://github.com/quarkusio/quarkus/discussions/39737)

+1 for this feature