Introduction

The message "Unable to find main class bootRepackage" usually means a build tool task was mistaken for an application main class. bootRepackage was an old Spring Boot build task in the Gradle plugin, not a Java class that should be launched with java or configured as the application's mainClass.

bootRepackage is a task, not an entry point

In older Spring Boot Gradle setups, bootRepackage was responsible for repackaging the built archive into an executable fat jar. That makes it part of the build lifecycle, not part of the application runtime.

So this is the wrong mental model:

• "bootRepackage is what my app runs"

The correct model is:

• "bootRepackage is something Gradle runs during packaging"

Your actual application still needs a real Java main class such as:

1import org.springframework.boot.SpringApplication;
2import org.springframework.boot.autoconfigure.SpringBootApplication;
3
4@SpringBootApplication
5public class DemoApplication {
6    public static void main(String[] args) {
7        SpringApplication.run(DemoApplication.class, args);
8    }
9}

That class is the executable entry point. bootRepackage is not.

How this error usually happens

The error often appears when one of these is true:

• an IDE run configuration uses bootRepackage as the main class name
• a script tries to run java bootRepackage
• build configuration confuses plugin tasks with application settings

In all of those cases, Java looks for a class literally named bootRepackage and fails because no such main class exists.

Run the right thing for the job

If you want to run the application during development, use the application entry point or the Spring Boot run task:

./gradlew bootRun

If you want to build the executable jar, use the packaging task:

./gradlew build

Or in older plugin versions, bootRepackage may be invoked as part of the build flow.

The key is to separate:

• running the app
• building the archive
• repackaging the jar

Those are related, but they are not the same command.

Spring Boot plugin versions changed over time

This topic is also version-sensitive. In newer Spring Boot Gradle plugins, bootJar replaced older packaging conventions such as bootRepackage. So if you are reading old blog posts or Stack Overflow answers, be careful about plugin-version drift.

For modern Boot versions, you are more likely to see:

• 'bootRun'
• 'bootJar'

and not bootRepackage at all.

Check the build file and IDE configuration

When diagnosing the issue, inspect:

• the Gradle plugin version
• any mainClass or application plugin settings
• IDE run configurations
• scripts or CI jobs that launch the app

If any of those treat bootRepackage as a Java class name, that is almost certainly the problem.

Common Pitfalls

• Treating a Spring Boot Gradle task as if it were the application's main class.
• Copying old Gradle examples into a newer Spring Boot project without checking plugin version changes.
• Running java directly against a task name instead of a jar or main class.
• Misconfiguring the IDE run configuration to use bootRepackage as the entry point.
• Mixing "build the jar" commands with "run the app" commands.

Summary

• 'bootRepackage was an old Spring Boot build task, not a Java main class.'
• The application still needs a real public static void main entry point.
• Use bootRun to run the app and packaging tasks such as build or bootJar to build artifacts.
• Check IDE and script configuration for any place that incorrectly treats bootRepackage as a class name.
• Be careful with old Spring Boot plugin examples because the task names changed over time.