This message was deleted.

I think the simplest solution to your problem would be to split your transform into two: One that extracts and the second one that selects the files from the extracted directory. BTW, I am not sure if it is a good idea to mark this extract/select transform cacheable, since it will be doing mostly IO anyway.

Do you actually need the extracted directory somewhere except as intermediate step? I guess no, then it might be better to either extract to a temporary directory instead of

outputs.dir

and then copy from that temporary directory to the

outputs.file

return value. Or alternatively do not extract at all, but directly just pull the embedded jars out using a

JarInputStream

or similar, directly just writing the intended output files unless

findSpecificJars

need to look inside the files to find the correct ones.

@wolfs That’s interesting idea — and probably will solve another case of mine in the future. But how to properly play with attributes now? As for now I have https://gradle-community.slack.com/archives/CAHSN3LDN/p1692288331275559 About caching — isn’t it fine to cache the unarchive operation? It takes a bit of time and resources to extract ~1GB zip archive. @Vampire Actually I need the whole directory also for other purposes. IJ SDK brings not only jars used for development, but also bundles JBR used for running guest IDE — so I have to keep everything as it is.

Then maybe do as Stefan suggested and split it in two transformations. You will have two transformations registered. E.g. one that transforms zipped->extracted and one that transforms extracted->individual-jars. If you then request somewhere extracted, you get the extracted directory, if you request somewhere individual-jars, you will get the individual jars. The transformer logic will then automatically chain those transformations to get the intended end-result.

Awesome, works as intended! Thank you both! PS. it’s not cacheable anymore. 🙂

Of course

As for now, we have a problem that, when debugging, IDE leads to compiled&instrumented classes instead of attached sources — because of some mismatches. Maybe that will help us somehow.

Iirc you will have a problem when navigating to sources though, as the sources will either be not found or give the non-instrumented ones without way to adapt the sources too.