https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
j
I could separate it in a previous task in the root build dir, and getting it from there in the subproject task, but this implies calling both tasks separately because the subproject task one can't depend on the root task one
g
If that plugin doesn't add variant but writes file as task output you could do it yourself via consumable configuration in root project, assigning it some custom attributes plus adding variant based on the configuration and than consume it in subproject using resolvable configuration with same attributes and 
project(":")
dependency. See https://docs.gradle.org/current/userguide/cross_project_publications.html
👍 1
j
Looks like it is not a task, it is just a method on its extension 
ChangelogPluginExtension.get(version: String)
I can create a custom task for it
Thank you, I will try 🙂
g
Yeah, it should work. Just did something similar to fetch and write Kubernetes CRDs for Traefik (as additional variant) with another task to generate java code for them and standard java-library for primary variant. Just love when a task falls in with gradle's modelling, makes quite easy to express what needs to be done in gradle dsl. Also become huge fan of implicit dependencies recently, it simplifies consuming a result of one task in another in concise and maintainable code
j
The task should only need to output a string, but I guess I need to generate a Jar, right?
Copy code
// this can't work if the task output is an `String`
artifacts {
    add("instrumentedJars", someTask.outputFile) {
        builtBy(someTask)
    }
}
g
I hope JvmEcosystemUtilities and JvmModellingServices become public sooner than later
No, you don't need jar for that
j
a txt file should be enough then?
or even the string is valid
well I think a String can't be an output
g
Just create task with 
@get:OutputFile abstract val out: RegularFileProperty
parameter, write the txt/xml file in its task action, create separate configuration (with 
isCanBeResolved=false
and 
isCanBeConsumed=true
plus 
attributes
block to define some attributes to differentiate from other variants)
Then use 
components["main"] as AdhocComponentWithVariants
to add variant from your configuration
artifacts
block is legacy iirc
Forgot to mention, you'll need to add the output file to the configuration. I'm not sure but think that 
outgoingCofiguration.from(tasks.named("writeTask"))
should work
j
thank you for the detailed response 🙂
I was trying with artifacts and I didn't get the deprecated mention 🤔
is there any place to check the new docs?
g
Currently afk, so all off the top of my head
👍 1
Not sure that it's in current docs but heard it in this slack when cross project publication was mentioned
👍 1
j
Don't know about the 
from
part
g
I still used it to attach artifact somewhere myself so it should work. Mb it as not recommended way and not deprecated per se
j
the outgoing plus artifact (image I shared) should work as top level artifacts? or it is a totally different thing
g
That means that Configuration doesn't extend ConfigurableFileCollection(
👍 1
My bad
In my case something like this works:
Copy code
// in producer project, fetchCrd has single OutputDirectory property
val fetchCrds by tasks.registering(FetchCrdTask::class) {
 // ...
}

val crds by configurations.creating {
  isCanBeConsumed = true
  isCanBeResolved = false
  attributes {
    attribute(Category.CATEGORY_ATTRIBUTE, objects.named(Category.DOCUMENTATION))
    attribute(DocsType.DOCS_TYPE_ATTRIBUTE, objects.named("CRD"))
  }
  outgoing.artifact(fetchCrds)
}

// in consumer project
val crds by configurations.creating {
  isCanBeConsumed = false
  isCanBeResolved = true
  attributes {
    attribute(Category.CATEGORY_ATTRIBUTE, objects.named(Category.DOCUMENTATION))
    attribute(DocsType.DOCS_TYPE_ATTRIBUTE, objects.named("CRD"))
  }
}

tasks.register<Copy>("consumeCrds") {
  from(crds)
  into(layout.buildDirectory.dir("kubernetes/crds"))
}
outgoingVariants
task produces something like
Copy code
> Task :traefik-crd:outgoingVariants
--------------------------------------------------
Variant crds
--------------------------------------------------
Capabilities
    - xxxxxx.operator:traefik-crd:0.1.0-dev.3.uncommitted+c65529a (default capability)
Attributes
    - org.gradle.category = documentation
    - org.gradle.docstype = CRD

Artifacts
    - build/kubernetes/crds
dependencyInsight
(w/ Gradle 7.5-rc-4) show that it was matched on these attributes:
Copy code
> Task :xxxxxx-operator:dependencyInsight
project :traefik-crd
  Variant crds:
    | Attribute Name      | Provided      | Requested     |
    |---------------------|---------------|---------------|
    | org.gradle.category | documentation | documentation |
    | org.gradle.docstype | CRD           | CRD           |

project :traefik-crd
\--- crds
sorry for the typos, it's around 2am for me
j
Almost same here, don't worry 🙂
But it is necessary to add it as dependecy, right?
I am executing the copy task, but it does nothing
g
I guess I've mixed 
Project#artifacts
with 
archives
. It internally works with same 
Configuration#artifacts
as does 
Configuration#outgoing#artifact
Yeah, dependency is what really binds it together
j
ah okay, I am gonna try
I get it working, really thank you 😄
👍 1
g
If you use variant aware publishing (with matching attributes on both sides) you just use 
myConfiguration(project(":module"))
and it works. Same if you publish to nexus with gradle metadata and then consume it by GAV coords
j
Indeed this is what I did
party gradlephant 1
g
One thing to be aware: if you publish root project to nexus/artifactory you'll get warnings. Either skip this this variant publication with something like 
(components["java"] as AdhocComponentWithVariants).withVariantsFromConfiguration(crds) { skip() }
, turn warning about maven incompatibility off or just ignore it ,)
Same thing that you'll get with java/java-library + java-test-fixtures in one project
j
good to know, but I generally don't use the root module as something which can have sources or something so, just to configure "generic" plugins like ChangelogPlugin, Nexus plugin and so on. Even if I have only one module I use a subproject too
the subproject which is going to consume that configuration can be published, the warning can be there too?
g
no, just on producing side
j
sadly I haven't played with java test fixtures yet, Kotlin doesn't support them in Android/KMP projects 😢
I am simulating them in a poor way by having a submodule which that name so when they are supported I can just remove the build.gradle.kts in that module 😂
g
aah, I used them only with java/kotlin-jvm/groovy(spock) since I don't do android/kmp projects
I guess you could model something similar if need arise but it could be easier to create another subproject for now for fixtures/common test code
👍 1
I usually create custom source sets for codegen, Gradle's ad-hoc tasks for that is one of the major selling points for me opposing Apache Maven mojos
j
Yeah, I create them in build/generated like kapt or other plugins do
Open in Slack
PreviousNext
Powered by