This message was deleted.

As a task should better not modify files in-place, but write input files to output files with the replacements done, there is no need for any plugin, but you can just use a simple

Copy

or usually better

Sync

task. You can configure it to replace things by tokens, be regex, by any logic in a lambda, ....

I'd love that answer but see that Open API generator. Really it's the generator that needs to be fixed... In this case I just intend to do some fix-ups after the fact. Actually that brings me to a good question though. If you believe that then what do you think of things like spotless. That reformats your code so it does it in place

I format my code, not some random plugin. But well, like always there are exceptions from the rule. Such a task like

spotless

is the end of the chain. It does this reformatting and then the build is finished. It is still bad as it then is not up-to-date but runs again, but at least on the third run it would be up-to-date. And additionally it does not operate on the output of another task, but on your manually written source files which also makes it less problematic. But if you for example have a task that compiles code from Java to Class. And then you have a task that instruments the Class files in-place, that is extremely bad. The compilation task would for example always be out-of-date and always need to re-run, and there would also risk of problems with caching and so on.

Oh I have no intent of operating on the output of another task. We are going to generate and then commit the files. So it's only the output of another task by virtue of the fact that said task is getting run by a developer by hand to maintain its configuration in a way they don't have to think about. It's just programmatic updating of the code because the current open API spec is as unstable as Charles Manson. After the code is regenerated, then hand updates might be done and at the end of the day it'll all be committed.

😱

I don't love it but It feels like it might solve all the problems we're having. Ultimately from the looks of a open API generator is supposed to create a skeleton for your project. I don't like any of those that generate things that I don't explicitly completely understand. I certainly don't understand every piece of code it's generated. I don't like them at all. Said somebody who's written one. The one I wrote though was designed so that all of those templates are written by me... Like they aren't meant to be shared to other people only within your project or yourself.

Yeah, that's why I disabled all but the production code generation. You will read it tomorrow. 🙂

Well maybe after I do that I'll figure out how to post process that to get rid of the deprecated JSR 305 jar

No, I don't know why you should remove it. It is old, yes, but it is still fine. Except if you need to have it as JPMS module or similar and for that we have the

extra-java-module-info

plugin to make it a module on the fly.

That is my intent, to have it as a JPMS module. That feels like a hack... I like that the thing exists but really it should be fixed upstream and we know that this is never getting fixed upstream so it should be removed instead. If you would like however I made a bug for them to allow you to define which nullable annotation imports you use

Not sure which place you currently talk about 😄

The Open API generator. I created a bug on that to generate code with a modern import rather than the deprecated JSR 305 jar. There are at least three other vendors of the annotations I want

The plugin uses an artifact transform to patch the jar file on-the-fly to either add an

Automatic-Module-Name

manifest entry or a

module-info.class

file, depending on what you configure for that dependency.

Yep, I'm going to call that a monkey patch and you are modifying things in the same way you just told me not to except you're doing it to a binary essentially

Yep, I'm going to call that a monkey patch and you are modifying things in the same way you just told me not to except you're doing it to a binary essentially (bearbeitet)

Don't do that, bad vampire

Yes, it is monkey patching. But no, it has absolutely nothing to do with what I said you should not do.

I don't agree entirely because modifying a jar is not all that different from modifying the source

I did not say you should not modify the source. I just said don't do it in-place and that plugin is not doing it in-place

Okay well maybe I misunderstood. You didn't seem to like the idea of me committing the files and then regenerating them periodically

Exactly what I told you shoul should do with the extra

Sync

task between generation and compilation

Anyways, thou shall not violate the open closed principal

I don't like the idea to commit any generated file. Any file that is generated by the build should be generated when building and not checked in imho.