From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Actually my project1 is depend on project2 jar packages but I'm not able to declare the dependencies for that because the are not submodule of each other

Model project2 as a proper module (sub project) such that it's dependencies can be cleanly consumed.

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

Regarding the problem, it is not a Gradle problem, but a ForgeGradle problem, so you should ask in a more approriate forum if you have problems. But just compare your version with the example in the template, you deleted one line too much.

In the root project it is working and it is not empty, but in a subproject it is empty

I have found which is causing the issue, but I don't understand why, and the difference is the subproject is applying the Kotlin JVM plugin

And it has to be applied after my plugin, if I apply my plugin at bottom, the issue is gone, no sense

The issue is not happening with `java` plugin

I am not sure how Kotlin JVM plugin can be breaking it

it’s likely resolving your provider / valueSource at a different time (or in a different order).  Takes a bit of tweaking to get the resiliency right to avoid ordering problems.

But I don't know why Kotlin is broken it like that, I am depending on Assemble task and looks like Kotlin is creating in a weird thing or I am not configuring my task in a lazy way

```project.tasks.named(ASSEMBLE_TASK_NAME).configure {
    it.dependsOn(semverPrintTask)
}```

I tried without the `configure`, same issue

```project.tasks.named(ASSEMBLE_TASK_NAME) {
    it.dependsOn(semverPrintTask)
}```

I was aplying base plugin before so I was no getting a crash, but the property was empty. After removing the base plugin from my plugin to use assemble configured by Kotlin I get a crash based on order in the plugins block...

usually indicates something is happening during configuration (where code is susceptible to ordering issues( instead of being lazy and done during execution (after all plugins applied, plugins evaluated).  Check where your configuration is set, ensure it’s only resolved lazily.

Is it possible to track it with a scan? I am unable to see where I am failing

the only thing I see I am using in configuration phase is the ValueSource but I think it is normal

Possibly.  I often end up adding debug statements to help understand call order.

Is it possible the Kotlin plugin is doing something in a not lazy way if I am unable to reproduce the issue with java plugin and it is only happening with Kotlin one?

could be, question is how is that tickling your code?  is the Kotlin plugin reading something you are providing earlier than expected?

that is the weird thing, I am setting the version which is calculated inside the ValueSource using my plugin extension property, but that property is not fetched by Kotlin plugin

but even calling my semverPrint task which has nothing to do with Kotlin, it still prints incorrect values

what is an example of an incorrect value?

Checked with Android plugin, no issue too

```&gt; Task :semverPrint
semver for semver-plugin-playground: c0.1.0.0+30b28c6+DIRTY

&gt; Task :library-one-a:semverPrint
semver for library-one-a: a2.5.4.4+DIRTY```

after changing Android or Java plugin to Kotlin, and keeping it after my plugin, I get:

```&gt; Task :library-one-a:semverPrint
semver for library-one-a: a0.1.0.0+30b28c6+DIRTY```

the reason it is not printing it is coming back to 0.1.0 is it is getting the plugin extension property as empty

both, Java and Android are working correctly in any order

how does it get that plugin extension property?

it is configured there (`projectTagPrefix`)

and it is used inside `ValueSource.obtain` method

ok.  thanks for sharing that.  perhaps try to `set`the property.  `convention` is the default value, usually only used in say an extension constructor, not when passing a value around.  There are some corner cases where properties without a set value behave differently.

`set`will also uncover cases where properties that are supposed to be set aren’t set - Gradle will chirp about those.

what does `semverExtension.tagPrefix` look like?

```public val tagPrefix: Property&lt;String&gt; = objects.property&lt;String&gt;().convention(DefaultTagPrefix)```

and in the consumer library:

```semver {
    tagPrefix.set("a")
}```

how is the semver extension created?  Specifically, is it the same instance in the plugin as in the build file (`semver { tagPrefix … }`)

after changing everything to set it still fails

yea.  let’s check where / how the extension is created.

```extensions.create&lt;SemverExtension&gt;(extensionName)```

that will return the same instance, have many cases of doing exactly that.   hmmm.

After wrapping my entire plugin with
```target.pluginManager.withPlugin("org.jetbrains.kotlin.jvm") {
    ...
}```
the problem is fixed, but I am applying my plugin in the order where it should not be working

not sure if this implies the problem is caused by my plugin or I am in the same point

it seems like the ValueSource is being resolved before your configuration has taken effect.  That may happen if  a plugin accessed `project.version` , as that would happen well before your configuration stanza is executed.  For other version management plugins, they force the order, as in calling `project.version = scm.version` *after* the configuration stanza.

easy way to test that - add a println statement in the ValueSource, and another one immediately before `semver {}` configuration block.  I’ll find an example of forcing the order, standby…

```scmVersion {
    tag {
        prefix = 'my-project-name'
    }
}

project.version = scmVersion.version```
&gt;&gt; Order of definition does matter! First, you need to apply the plugin, then configure it using `scmVersion` extension and only then current version can be set for whole project via `scmVersion.version`.
&gt;&gt; 
&gt; 
&gt; 

<https://axion-release-plugin.readthedocs.io/en/latest/configuration/basic_usage/#applying-plugin>

mmm my plugin is which is applying the version indeed, this would force the user to apply it manually, right?

I guess there is no way to avoid that and do in my plugin

yes.  if you are allowing the user to configure it (that semver config stanza) then they have to force the order.  If you can configure it all internally you can control the order.

chicken and egg - can’t read the version until we have the configuration on how to read/structure the version.

only way around that is to eliminate the configurability, but presumably you have a need for that.

I can fix the issue by configuring it via project properties instead of extension properties, not beautiful, but I avoid the boilerplate of setting the version

yep.  those would be available in the plugin (providers.gradleProperty), avoiding this timing issue.

I guess why Kotlin is calling the version in a different way that Java or Android does, because they are not having this issue

not sure if Kotlin is calling `project.version`  or `project.version.toString()`

if is this last one, probably that can be the issue because the `project.version.toString()` should be only called inside tasks

I will investigate it, any way, really thank you for your help :slightly_smiling_face:

exactly.  that’s where these timing issues become insidious - everything looks to be working great, until it doesn’t.
Somewhere in the Kotlin plugin it is likely calling the `.toString()`, often indirectly (e.g. printing out the version).  Sometimes running in --info or --debug changes the behaviour, as the simple act of printing out the version resolves it perhaps sooner than intended.

&gt; &gt; because the `project.version.toString()` should be only called inside tasks
Who defines that?
I mean, it would be nice if it were the case, but I don't remember this being any rule written somewhere.

Certainly no rule for that.  project.version is dated, from original model where it was assumed to be static (or externally defined).  Challenging to make it dynamic…

I think I have read it in some place today when I was trying to fix this issue but I am not being able to find it from mobile 

&gt; where it was assumed to be static (or externally defined).
That's not fully true.
If that were the case it would have been a `String` field.
It was always meant to be dynamically calculated, by having an `Object` field where the call to `toString()` determines the version to be used.

Knowing that anybody can set anything there that can be configured lazily, calling to string outside of a task is risky 

Sure it is.
But some plugins (hopefully non still existing) even just casted the value to a `String` because they did not consider that it actually can be anything.
That the value of `version` is changed frequentely is indeed not a too well supported case.

The overhead of reading/parsing a (presumably small) file is likely insignificant and may not be worth optimizing for.  If you do wish to avoid reading this on every build, the best bet is to use Gradle’s configuration cache.

I mean it went from this

```loop all android variants
	...
	tasks.register("appAutomateUpload$variant") {
		def props = .... read prefs from file
		username = props["username"]
		password = props["password"]
	}```
(as you can see props are read lazily)

with task body being in buildSrc, to creating a plugin which will be moved out to a separate repo

now it feels like a downgrade

and in my experience config cache is so not ready and broken often (even new kotlin breaks it)

agreed re: cc - it’s great when it works, but…

have you looked at ProviderFactory.fileContents? `providers.fileContents(file)` that allows for lazy reading of a file.

I noticed deploy plugins take in files mostly, or have this dual api

```play {
    serviceAccountCredentials.set(file("your-key.json"))
}```

ill like into that, have no clue about it

btw stupid question, wont this actually do the job?

```appAutomateUpload {
	def props = ...read profs from file
    username = props["username"]
    password = props["password"]
}```
just moving the reading into the extension? not sure when are those resolved tbh

that will be done at configuration time, which usually isn’t desirable.  You’ll also need to check that the file isn’t read/parsed more than once (for optimal performance).

yea so I can only pass the file handle — but then the layout of the properties file needs to be documented since its hardcoded internally in the plugin now

your plugin can provide a Provider&lt;Map&lt;String,String&gt;&gt; that handles reading the file, parsing it into a map (lazily - only when resolved, and only once).

```provider {
def props = ...read profs from file
props
}  // assuming props is a Map&lt;String,String&gt;```

but what would it return, the map? then the expected map keys need to be documented

guess only making it type safe is safe and self documenting, and will probably blow up groovy :smile:

it return a provider to a map, yes.  When resolved it’s used as in your examples `props["username"]`.
Yea, type safety and groovy ugh…

```appAutomateUpload {
    credentials {
    	def props = ...read profs from file
    	Credentials(props["username"], props["password"])
    }
}```
something like this?

be sure not to resolve the provider until in the execution phase - inside the tasks that need the props, generally.

whats a provider in gradle speak, just a plain lambda to defer stuff?

no, that isn’t right.  If it’s a credentials object you are after, create a Provider&lt;Credentials&gt; and a receiver property Property&lt;Credentials&gt; on the extensions.
A <https://docs.gradle.org/current/javadoc/org/gradle/api/provider/Provider.html|Provider> is a specific interface in the Gradle API; more context available <https://docs.gradle.org/current/userguide/custom_gradle_types.html|here>.

im a bit lost. Credentials is my type or gradle type

Something like this (Kotlin):
Extension:
```public abstract class AppAutomateUploadExtension {
    @get:Input
    public abstract val credentials : Property&lt;Credentials&gt;
}```
```        val credProvider = providers.provider {
            val props = readFile(...)
            return Credentials(props["username"], props["password"])
        }```
…Credentials can be your type, if that exists and is what you are modelling.

interesting but isnt that the same as I did?

appAutomateUpload {
    credentials  = {
    	def props = ...read profs from file
    	Credentials(props[“username”], props[“password”])
    }
}

or since for some reason I cannot use my own lambdas, I need to use the `Provider`, hence I need the `providers.provider` factory?

Not the same.  It’s a Property/Provider, which is the key difference.  That represents a supplier/factory for getting the credentials _at a later time_.  That is then passed to where the credentials are needed (presumably a task), which then resolves the provider via `.get`.

oh, I see, the Groovy assignment of the lambda thing.  similar, as long as credentials is a lambda type, and resolved later.

yea but I still want to be idiomatic, so Provider is the way to go right?

Yes.  All the values on your extension should be Property objects (or List/Set/MapProperty as needed), as should all the attributes on your tasks.

you should only call `.get()` on a property/provider inside the execution phase, usually in a task action.

yes Ill only resolve those in execution phase. Now I’m just figuring out if my api or the `providers.provider` factory is nicer

the Providers API also offers mapping via `.map()`.  Say you have a Provider&lt;Map&lt;String,String&gt;&gt; and want to pass one specific map entry into a task - you can go `prop.map { this["username"] }` to turn that into a Provider&lt;String&gt;.  also available are conventions (defaults) for properties via `.convention()`.

for example `project.layout.projectDir.file("myFile.properties").map { // process file }`

yea, interesting that I never heard of this yet. usually its just file handles

if you use `providers`, then
```tasks.register("myTask") {
    val credentials = project.providers.credentials(PasswordCredentials::class, name)
    doLast {
        val credentials = credentials.get()
        println("${credentials.username}:${credentials.password}")
    }
}```
lets you provide it via any of
```# gradle.properties
myTaskUsername = foo
myTaskPassword = bar```
or
```./gradlew myTask -PmyTaskUsername=foo -PmyTaskPassword=bar```
or
```env ORG_GRADLE_PROJECT_myTaskUsername=foo ORG_GRADLE_PROJECT_myTaskPassword=bar ./gradlew myTask```
without requiring credentials if the task isn't run

I moved that logic vom the apply method of the plugin to the extension, which seems to work fine

It is quite annoying that the Shadow plugin used a method named `component` here while it does not mutate the component at all but instead messes with the publication. Note that doing that means that the POM and GMM files are out of sync.

So indeed you should rely on the `java` component, properly configured to publish the `shadow` jar as its main artifact.

it's annoyed me for years. Finally decided to try to configure it properly after I found a very random mention of "shadowRuntimeElements" in the changelog for Shadow 6.0! The shadow docs still only discuss the older method, though. Very frustrating.

Generally that would indicate a timing problem

ah yes, if that gets applied in `plugin{}` version has not yet been set

Not sure I believe tht "just broke", but :shrug::skin-tone-3:

The better way is to have your task use Property and use a convention

The convention would be the project's version

`projevtVersion.set(project.provider { project.version.toString() })`

or `.convention` instead of `.set`, as mentioned, but that doesn't change how to postpone the provider

yes that works, but providers have certain implications

its similar to a lambda versus method ref

`myTask.getProjectVersion().convention(project.getVersion())`

though actually, why do you even set it out of curiosity? a task always has access to the project

ohhhh, and I just realized `it.projectVersion.set(...)` implies it is already a Property I guess

&gt; Not sure I believe tht "just broke",
Haha, fair enough. I swear it's true though :slightly_smiling_face:

&gt;  why do you even set it out of curiosity? a task always has access to the project
That's a good question. I used to simply reference it for quite a while, no problem. And then gradle started giving me deprecation warnings about how I shouldn't access it directly. This was a while ago so I don't remember exactly.

You're task's representation is a String so my exact convention call woud not work.  you'd need to map it

but regardless, its all about delaying that

Or you could change the task to `Property&lt;JavaVersion&gt;`

Depends on your needs/wishes/deepest-desires

&gt; `projevtVersion.set(project.provider { project.version.toString() })`
Oh, that's looks cool. I can create a provider out of anything? And it will only get resolved when the task runs? Perfect. I think that will solve my immediate problem. The question remains though why I had to turn group and version into properties in the first place. I might revert that change and see what gradle has to say.

I mean do what you want, but you are just creating a completely new unnecessary object with that approach here

And they are Properties (they have been for a LONG time btw) just for this timing issue

What are properties? Version? It just says Object in the source code.

Think of it like this...

1. `plugins {}` applies your plugin (because that happens very early)
2. your plugin accesses the projects version
3. your script sets the version

And what is this convention thing. I have no idea what that is. Googling now...

I know what a provider is, I think. But project.version just say object in the api

If project.version was a provider, I would have simply written
```it.projectVersion.set(project.version)```
but I can't...

Actually, I was wrong... version is a String

I think you just primed my brain to think Property :smile:

Well, it's probably whatever you assign to it in your script. Which is normally a string, but could be anything.

no, i broke point into even before setting it

So what does this do...
```it.projectVersion.convention(project.version.toString())```


That will not work, you still try to access toString eagerly

you actually will have to do what <@U019L3NM4PK> suggested

though, i still say (externally anyay) I am not sure why you set that

just access it when you need it during task exection

unless you allow setting it on the task itself, which seems strange

I will try to access group and version directly in the task. If gradle doesn't complain, all good. If it does, I'll use the lambda. Regardless, I learnt something today, so cheers to you both.

Well to be clear (we're engineers, we like clear right...) - a Provider != lambda

Just look at some of the APIs between Property and Provider and I think it will make sense

no, but it accepts a lambda, or a Callable...
```&lt;T&gt; Provider&lt;T&gt; provider(Callable&lt;T&gt; var1);```


right but Callable can be a lambda, method ref or anon class

technically correct...the best kind :slightly_smiling_face:

Not sure about the tecnhincally, but definitely correct :wink:

&gt; and use a convention
Using `convention(...)` or `set(...)` / `value(...)` both is fine.
It has different semantics.
If later someone does `set(x)` and then `set(null)`, with a `convention(...)` it is effective again, with `set(...)` or `value(...)` it would now be unset.

&gt; though actually, why do you even set it out of curiosity? a task always has access to the project
Accessing the `project` during task execution is deprecated as it is incompatible with configuration cache.
Besides that it can easily be a task input by having a dedicated property.
If you do it like OP wrote, then it is delayed until the task is configured.
If you do it with a provider it is delayed until the property is queried, so potentially just at task execution time, so exactly what is needed here.

&gt; Or you could change the task to `Property&lt;JavaVersion&gt;`
`JavaVersion` to set the project version? o_O

&gt; Actually, I was wrong... version is a String
... no

No?  I set a break point valuate getVersion() and it returns me a String

You can set it to anything and thus dynamically calculate a version a bit delayed by doing it in `toString()` of it

Early way of "delayed" calculation before `Property` existed

Yeah, sorry, "someone" set it to a "String"

For example to `"undefined"` which is its default value

Or if you set it via `gradle.properties` which I usually do if I don't need dynamic calculation, then it indeed was you.

no, i always do it in my script though not for any particular reason :slightly_smiling_face:

I often set it in `gradle.properties` and then in the code set `version`  to a more capable object, that in its `toString` just returns the version but has additional methods like getting the main release version or determining whether it is a snapshot version, ...

I usually do it in `gradle.properties` so that it is set as early as possible for any early consumers and this way it is also reliably set for all projects in the build and an automatic release process also has it easier to increase the version.

&gt; Accessing the `project` during task execution is deprecated as it is incompatible with configuration cache.
Thanks for the input. I knew I changed it for a reason.

&gt;  If you do it like OP wrote, then it is delayed until the task is configured
Which was working fine for me until recently. I can shuffle things around and register tasks in `afterEvaluate` but I think the better solution is to delay the reading of group and version until the latest possible.

Mine gets calculated in a plugin which I apply first, so what you said it perfct

So basically ignore everything I said and listen to Vampire which is general good advice on here anyway :wink:

&gt;  I usually do it in `gradle.properties`
That's yet another file that defines the build. I even grumble at having to split my GAV up by putting the project 'name' in settings.gradle. Yes, I used to use maven, and the trio were always sitting nicely together at the top of the pom. (I'm sure there are good reasons for the way it works now).

&gt; and register tasks in `afterEvaluate` 
Please don't.
Any `afterEvaluate` you use should make your heart bleed.
It is usually just symptom treatment.
The provider is exactly what you want.
It maybe as just accidentally that it worked before.
&gt; but I think the better solution is to delay the reading of group and version until the latest possible.
Exactly

&gt;  and register tasks in `afterEvaluate`
&gt;&gt; Please don't
Noted. I will use my new `provider(Callable)` powers to solve all my problems.

&gt; I even grumble at having to split my GAV up by putting the project 'name' in settings.gradle.
Well, you don't have to split them.
You can define your full GAV in the publishing configuration.
Using the project group, project version and project name are just the conventions.
But Gradle is very flexible and if you want the trio to be together, you are free to do so.

It might prove problematic if you want to use composite builds, though, I'm not fully sure

&gt; Yes, I used to use maven, and the trio were always sitting nicely together at the top of the pom. (I'm sure there are good reasons for the way it works now).
Did you enjoy duplicating versions everywhere throughout a multi-project build too? :wink:

&gt;  You can define your full GAV in the publishing configuration
Right, ok. That trips me out a little. I've always thought of the three as intrinsic to the build. But gradle doesn't care until publishing the jar I suppose. But you do require a settings.gradle don't you?

By now you require a `settings.gradle`, yes.
But you don't need to set a name in it.
The default is the directory name, so it usually makes sense to have a name defined in there.
But you don't have to.

And `group` indeed is only relevant for publishing.
If you don't want to publish or developing an end product,
setting the `group` actually is pointless.
(Unless some plugin you use thinks it needs it)

Even `version` could be left out if you don't want to publish and are ok with the built artifacts not to have a version in their name for example.

great. All good information to have. Thanks <@URQ797WRW>.

It doesn’t look like there is a Finchley.M5 version on Maven Central: <https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-dependencies>

Its likely to do with a bad respository URL:
```URI does not specify a valid host name: https:/repository/maven-public/com/amazonaws/aws-java-sdk-bom/1.11.125/aws-java-sdk-bom-1.11.125.pom```

I believe that version exists (<https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-dependencies/Finchley.M5>) anyway, I it looks like the repository is not responding

likely due to the bad repo URIs somewhere in your config.
```RI does not specify a valid host name: https:/repository/maven-public/com/amazonaws/aws-java-sdk-bom/1.11.125/aws-java-sdk-bom-1.11.125.pom```

Or to say it clearly, add the missing slash. :slightly_smiling_face:

Gradle Version
```------------------------------------------------------------
Gradle 7.4.2
------------------------------------------------------------

Build time:   2022-03-31 15:25:29 UTC
Revision:     540473b8118064efcc264694cbcaa4b677f61041

Kotlin:       1.5.31
Groovy:       3.0.9
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          11.0.14.1 (SAP SE 11.0.14.1+1-LTS-sapmachine)
OS:           Mac OS X 12.4 x86_64```

`gradle.properties`
```org.gradle.vfs.watch=false
# org.gradle.jvmargs=-Xmx2G "-XX:MaxMetaspaceSize=256m" -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8```
even bumping max heap to 2Gi didn’t’ help

what is “a lot of files”?  Perhaps there’s a symlink being following creating a cycle?

a lot of files = ~300k
yes, symlinks are involved but as far as I can tell for now, no cycles

if I run exactly the same build with 6.9.2, it works

interesting.  how is the delete being performed?  are the files an input to a task?

I had some performance issues with the delete in the past and wrote a custom task that uses java.nio instead of Gradle built-ins

interesting.  if you comment out the actual deleting - does it still run out of memory?

changed the delete task implemention to noop -&gt; no crash

hmmm.  perhaps there is a leak in som e of the NIO stuff, it can be finicky.  Some of those streams require being closed.

after looking at the task defintion again:
the base folder (starting point of the walk) is defined as @InputDirectory DirectoryProperty baseFolder;

How much Gradle magic does this annotation conjure up? :smile:

Much magic there.  It will fingerprint the contents of the directory, looking for changes.  If this is a cleanup task - where you are explicitly running it, for example - and optimizations such as skipping unnecessary tasks aren’t important - you can change this to @Input (or @Internal) to avoid the per-file-fingerprinting.

yep, that’s it.
Changed to `@Input` and all is well again

if you're deleting it, presumably you want <https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/Destroys.html|@Destroys>?

every day you learn something new :slightly_smiling_face:

A statically typed language :troll:
(do you have it when using the Kotlin DSL?)

ha ... so now we have to migrate to `.gradle.kts` ?

IDEA still has some problems with `projects` in kts, although this is in a pretty rare case that most people will not encounter: <https://youtrack.jetbrains.com/issue/KTIJ-19585>

but definitely don't *expect* any code completion in groovy. at best the IDE only has an approximate understanding of their contents

I can confirm that from Kotlin DSL I have code completion

possible that those plugins call your version object (`project.version.toString()`) multiple times, incurring latency?

I was thinking about that, but why it was working with the previous implementation with no issues :thinking_face:

perhaps check whether it’s called multiple times (and what the length of a call looks like) - if it is called multiple times likely want to memoize that, returned cached result after the first call.

the first difference it was an string and know it is a custom object built with the value source

that means that every version.toString() call will execute the value source.

yep, I will try that, thank you :slightly_smiling_face:

may perhaps be wrong on ValueSource being called multiple times (Providers are) - it looks like it only calls obtain() once, according to the docs.

```    private fun Project.configureLazyVersion() {
        version = LazyVersion(VersionValueSource.register(this))

        // Some third party plugin breaks lazy configuration by calling `project.version`
        // too early based on plugins order, applying the calculated version in
        // `afterEvaluate` fix it
        afterEvaluate { it.version = LazyVersion(VersionValueSource.register(this)) }
    }```