A modern programming language that makes developers happier.

kotlinlang

Is it possible to access classes from `buildSrc` module in regular code (not `build.gradle` files)? I’ve got some strings declared there that I would like to access in runtime

This question is probably better suited in <#C19FD9681|>.
Or as you use the Groovy DSL, not the Kotlin DSL, maybe even better the Gradle community Slack. :wink:
But besides that, your best option I think is to replace `buildSrc` by a composite build (`includeBuild` in settings script) for example named `build-src` or any other name. Or maybe even better to not pollute your production class path with too much build logic, just move the class(es) you want to share into an included build. Then you can depend on that produced artifact in the build script class path and in the production class path and thus can use it the same in both.

you can copy resources around during build time. for instance (don’t have the details right now, it is not something I do often) you can create a `shared.properties` file along side your `build.gradle` and then create a copy task to copy that file so that it becomes part of the classpath of your artifact

and your production code can get those “strings” from `Properties`

don’t hold your breath, but if I find an example I will share it

That would of course also work, then you just have to duplicate the code that reads the file and provides the values.

But the question was about sharing a class

Actually you probably don't need any copy tasks with that tactic

You can just add the file to the resources and so it will end up on the class path

<https://github.com/gradle/gradle/issues/2531|https://github.com/gradle/gradle/issues/2531>

<@UE206C71V> how do you think this issue fits in the discussion?

It is about removing the special-cased `buildSrc` project and instead make it a regular included build internally.
That does not at all help the OP.
Especially as he probably does not want that all his build logic and dependencies leak into the production class path.
And besides that, it will probably need quite some time before that issue gets resolved.

but the question he did is using `buildSrc` classes in regular code, when that issue is fixed, he could do that no?

An included build just replaces a declared binary dependency by a locally built version from the included build

So as long as he does not depend on the artifact the included build produces in his production configuration he will not be able to.
That would also be quite bad, as then all build logic would leak into the production class path as I said.
That's why even with that issue fixed, the common classes should be moved into its own module that can be depended upon from the build logic and the production logic.

<@U0152P3VB5J> I just understood

```I've got some strings declared there that I would like to access in runtime```
as if those classes only contain strings and the whole thing could be replace by properties. I might have over simplified the requirement, but if that is the case, I think using properties file and just package it together is a good solution.

I would not be a fan of having complex build logic into the application, like you said

Thankfully cascading included builds work now fine since version 4.10 or so. :slightly_smiling_face: