https://gradle.com/ logo
Join Slack
Powered by
Following up on my question from yesterday, no ide...
# plugin-development
s
Following up on my question from yesterday, no idea what exactly I changed to cause this but Gradle is now complaining about these generated sources -
Copy code
A problem was found with the configuration of task ':sourcesJar' (type 'Jar').
  - Gradle detected a problem with the following location: '/tmp/junit16008784648879827421/build/generated/sources/xjc/main/simple'.
    
    Reason: Task ':sourcesJar' uses this output of task ':xjcSimple' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
    
    Possible solutions:
      1. Declare task ':xjcSimple' as an input of ':sourcesJar'.
      2. Declare an explicit dependency on ':xjcSimple' from ':sourcesJar' using Task#dependsOn.
      3. Declare an explicit dependency on ':xjcSimple' from ':sourcesJar' using Task#mustRunAfter.
    
    Please refer to <https://docs.gradle.org/8.0/userguide/validation_problems.html#implicit_dependency> for more details about this problem.
I add this generation task (itself) as a path in the main source-set's java sources:
Copy code
final SourceSetContainer sourceSets = project.getExtensions().getByType( SourceSetContainer.class );
final SourceSet mainSourceSet = sourceSets.getByName( MAIN_SOURCE_SET_NAME );
mainSourceSet.getJava().srcDir( task );
What's super strange is that executing 
gradlew sourcesJar
works perfectly fine. I only see this error when calling 
gradlew publishToMavneLocal
(have not tried remote publishing yet)
(this is a unit test using TestKit, but the same happens "for real")
v
Is this some manual sources jar task, or the one you get from 
withSourcesJar()
?
s
Yes, 
withSourcesJar()
. Sorry, should have mentioned that
v
Hm, strange, usually this should work then properly I'd say if you configured the code generation task as srcDir like you said you do. 😕
s
Copy code
java {
	withJavadocJar()
	withSourcesJar()
}

publishing {
	publications {
		// main publication
		publishedArtifacts {
			from components.java
		}
		...
	}
	...
}
v
Looks fine so far
s
What's even more strange... In older versions of this plugin I simply added the tasks output to the srcDir and it used to work
Now it fails with both
I changed some of the plugin code from Groovy to Java. That would not affect it right?
Another change is that the path is now set by convention rather than explicitly. Maybe that mucks things up
I did verify that switching back from 
#convention()
to 
#set()
there made no difference however
v
The problem might be, that you do the 
srcDir
call in the configuration action of 
xjcTask
. So this configuration is only done if the task is actually configured and only when it is configured. You should probably move this outside the configuration lambda, so 
mainSourceSet.getJava().srcDir(xjcTaskRef)
after the 
register
call.
s
I tried that too
😞
But you are right that that makes more sense
v
How can the problem be reproduced in that project you shared?
s
Run the test org.hibernate.build.gradle.xjc.jakarta.SimpleIntegrationTests#testPublishing
Thanks so much for looking and helping. Not a simple problem
A related question... does TestKit trigger task dependencies? If I change that test to simply call 
publishToMavenLocal
none of the other tasks are triggered
Instead I need to manually call each individual task. Maybe that's a clue
Oh wait, just realized I had not pushed the loacl work with that test - sec
v
does TestKit trigger task dependencies
Sure, it is like calling Gradle from commandline or through IDE. It is just another tooling API using client. So if the depending tasks are not triggered, it seems something is not right
s
Great, then that's probably a partial clue
Running just the equivalent of 
gradlew publishToMavenLocal
in that test nothing is executed and I just get UP_TO_DATE
I feel like it is related to the publishing config though
If I just call 
gradlew sourcesJar
the jar is generated fine, including the generated sources
I should be using sourceSets.main.java and not sourceSets.main.allJava right?
Never quite understood the diff
Ok, I got around that. It was a number of small things in combo. Moving adding the generated sources to the source-set outside the config lambda helped. Using 
#set()
instead of 
#convention()
helped
Specifying a custom maven-local dir is not working via TestKit, so need to play with that some more
v
I should be using sourceSets.main.java and not sourceSets.main.allJava right?
yes
Never quite understood the diff
Let me quote the docs: `allJava`All Java source files for this source set. This includes, for example, source which is directly compiled, and source which is indirectly compiled through joint compilation. `java`The Java source which is to be compiled by the Java compiler into the class output directory. 
java
is more for configuring the Java source directory set. 
allJava
is for getting all Java sources, for example also those compiled by the Groovy joint compilation from the Groovy source directory set.
Specifying a custom maven-local dir is not working via TestKit
Maybe it needs to be done slightly different. 🤷‍♂️
Or it only works without 
withDebug
as that runs the test in-process instead of starting a new process
s
This simply does nothing, the real maven-local (~/.m2) is written to
Copy code
.withEnvironment( Collections.singletonMap( "maven.repo.local", "\"" + mavenLocalPath.getAbsolutePath() + "\"" ) )
v
You can also use a dedicated local directory to publish to instead of the broken-by-design maven-local
withEnvironment
sets an environment variable, I don't think that is correct here?
s
Yes I am trying to. I am using 
@TempDir
Yes, that one does not work at all
But neither does this, though differently:
Copy code
final String mavenLocalPathProp = "-Dmaven.repo.local=\"" + mavenLocalPath.getAbsolutePath() + "\"";

.withArguments( "publishToMavenLocal", mavenLocalPathProp, ... )
With that last one, nothing is written to either that temp dir or ~/.m2
So I tend to think that one is "correct"
v
Yes, system property is correct for that
s
With writing directly to ~/.m2 I was able to check the output though and it is correct
v
But actually what I meant was not to use 
mavenLocal
but just a manually declared directory-based local repository
s
Oh, for the publishing repo
v
exactly
s
Yeah I can play with that. Good idea
👌 1
Worked like a champ. Thank you so much for helping (yet again) @Vampire!
👌 1
4 Views
Open in Slack
PreviousNext
Powered by