https://gradle.com/ logo
Join Slack
Powered by
I'm creating a custom `MavenPublication`. I can ad...
# community-support
m
I'm creating a custom 
MavenPublication
. I can add artifacts to that publication that are created lazily by other tasks. Can I do the same for the 
.pom
file? Have a task that generates the pom file?
v
If you want a properly configured pom file, you should probably not add artifacts to the publication directly, that is seldomly a good idea. Typically you would create an ad-hoc component and configure that accordingly so that the POM you intend comes out which should then also be consistent with the generated GMM file. If you really want to manually craft the POM file, I guess the easiest would be to use the task that creates the POM file, clear its actions, and register an own 
doLast
action that writes out the POM file as you intend it to be.
👀 1
💯 1
m
use the task that creates the POM file, clear its actions, and register an own 
doLast
action that writes out the POM file as you intend it to be.
Oh so there is already a task doing so?
Actually, my requirements are more complicated. The publications themselves are the outputs of a task... Oh well
v
But after a task was executed it is too late to add new publications anyway, isn't it?
generatePomFileFor<publicationName>Publication
is the task that is created by the 
maven-publish
plugin for each publication you registered
m
> after a task was executed it is too late to add new publications anyway, isn't it? I think so but this also feels like an unnecessary limitation. 
publishToMavenLocal
is a task at the end of the day. I don't see a reason why it wouldn't be able to take its input from other tasks.
v
Because configuration phase vs. execution phase.
And you get tasks generated for publications and so on
m
Ah yes that's a good point
v
If you are at execution phase it is too late to schedule additional task to the task graph
m
But still. there could be a 
publishAll
that doesn't need to know the actual number of publications
I guess it's just too hard now to change all of this but in theory at least we don't need to know all the publications to build a valid task graph that publishes to Maven Local
I'd actually be curious to know how much people use single publication tasks vs the "allPublications" ones.
We had that discussion not too long ago with @Vladimir Sitnikov
v
The 
publishAll
would still need the tasks generated per publication for example the one to generate the POM, the one to generate the 
ivy.xml
, the one that generates the GMM, ....
m
Yup no, not always
v
Unless all this would not be done as tasks but be done as implementation detail of one task, but that would imho be not nice
m
Wait, no, it's not a pure requirement
v
🤷‍♂️
m
My use case is plugin markers.
I want to generate the publications from the Kotlin code.
I guess what I'm missing is a publishing API that is not relying on 
Publication
(some intermediate abstraction, that is just taking files)
v
I mean to remember there was some lib that allowed you to annotate a class with the plugin id that generates the plugin service file. Maybe it also has some mechanics for the plugin marker artifact. 🤷‍♂️
But I also don't remember which lib that was, my brain is probably still on vacation, just returned yesterday. 😄
m
v
Or I confused it with 
@AutoService
👀 1
A probably diiiirty way could be to have have a task or compiler plugin that determines the necessary information and then trigger the needed action using Tooling API and then get the determined information from a written file or through the tooling API directly by having a custom model you request like IDEs can do. But that would probably be quite awkward and need to run a build at configuration time which might be a quite bad idea. 😄
👀 1
m
Keeping this as a last resort ^^
v
Nah, better forget that non-sense that just spilled from my twisted brain. 😄
m
Too late, can't unsee it now!
😱 1
Open in Slack
PreviousNext
Powered by