We are using Spring Boot 3.2.5 in numerous services. We recently upgraded from version 2.x.

Our builds depend on a number of artifacts produced in house that are still using the javax packages, so I'm exploring multiple strategies to get those converted. The obvious one of changing the source code and releasing new versions has non-technical problems that will prevent that from happening anytime soon.

I then looked at using the Eclipse Transformer plugin in the build of a service to dynamically transform a dependency and use the transformed classes instead of the original classes from the dependency. Although the Eclipse Transformer is simple to use from the command line, and it's pretty simple for a build of a library to produce a transformed artifact, it would seem that it would be just as simple for a build of a service that uses a library that is produced with the javax packages to dynamically transform that artifact at build time, but it was not simple at all, and I found later that this strategy results in a new problem.

My transformation solution uses the antrun plugin to extract the transformed jars into "target/classes" before the compile phase. That strategy gets through all the associated compile errors. However, when it got to the "package" phase, using the spring-boot-maven-plugin's "repackage" goal, it fails with the following error:

Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:3.2.5:repackage (default) on project SalesWirelessAccountSetupMs: Execution default of goal org.springframework.boot:spring-boot-maven-plugin:3.2.5:repackage failed: Source must refer to an existing file, got C:\...\target\classes -> [Help 1]

I've never seen this error before, and I can't find any documentation about it. I looked in the source code, and I found this:

    protected Packager(File source) {
        Assert.notNull(source, "Source file must not be null");
            Assert.isTrue(source.exists() && source.isFile(),
                    () -> "Source must refer to an existing file, got " + source.getAbsolutePath());
        this.source = source.getAbsoluteFile();
    }

I think the key here is not the "exists" check, but the "isFile" check. "target/classes" is a directory, not a file. Even so, what is the point of this check and why is it happening in my build?

Comment From: wilkinsona

The repackage goal of the plugin expects an existing jar file as an input and produces a repackaged uber jar as an output. Beyond this, I could only speculate as it isn't clear to me what you've done or how you've configured things such that the source is now target/classes rather than a jar file.

If you require any further help with using the Eclipse Transformer Plugin while also meeting the requirements of the repackage goal, please ask on Stack Overflow using the spring-boot tag. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

Comment From: davidmichaelkarr

Yes, I did that already: https://stackoverflow.com/questions/79066771/putting-transformed-classes-into-target-classes-get-source-must-refer-to-an-ex .

Comment From: wilkinsona

Please don't cross-post without making it clear that you've done so. There's more information in your Stack Overflow question and someone may also have been trying to help you there without us knowing. Both risk wasted time and effort that would have been better spent elsewhere.