The setup: A Spring Boot service that booted perfectly with mvn spring-boot:run, but crashed immediately when launched from IntelliJ’s Run\/Debug configuration \u2014 same code, same machine, same dependencies.<\/p>\n
\nThe error:\n Exception in thread \"main\" org.springframework.beans.factory.BeanDefinitionStoreException:\n Failed to read candidate component class: ...\n Caused by: java.lang.IllegalArgumentException: Could not find class [com.azure.cosmos.models.CompositePathSortOrder]\n Caused by: java.lang.ClassNotFoundException: com.azure.cosmos.models.CompositePathSortOrder\n<\/pre>\nSpring’s classpath scanner hit an annotation referencing a class that, according to the JVM, didn’t exist.<\/p>\n
First instinct \u2014 wrong: <\/b>This looked like a version conflict. My local Maven repo had several versions of the library in question cached side by side, so a mismatch seemed like the obvious suspect. It wasn’t. Every version was internally consistent; the class was exactly where it should be.
\nFinding the real cause: <\/b>Instead of guessing further, I asked Maven directly where this dependency actually comes from:<\/p>\n\nmvn dependency:tree -Dincludes=\n<\/pre>\n The output told the whole story in one line:<\/p>\n
\n my-app\n \\- some-transitive-library:jar:x.y.z:provided\n \\- the-missing-library:jar:x.y.z:provided\n<\/pre>\nprovided scope. That’s Maven’s way of saying: “this dependency is needed to compile against, but something else \u2014 a container, an app server, the deployment environment \u2014 supplies it at runtime. Don’t bundle it.”<\/p>\n
Why the two tools disagreed: <\/p>\n
mvn spring-boot:run treats the JVM it launches as that “runtime environment,” so it includes provided-scope dependencies on the exec classpath.\n IntelliJ’s Run Configuration does not include provided-scope dependencies by default \u2014 and that’s the correct, intentional behavior for the scope’s contract. It’s not a bug; it’s IntelliJ doing exactly what provided is supposed to mean.\n Same POM, same dependency graph, two different \u2014 both legitimate \u2014 interpretations of one Maven scope.
\nThe fix, once the cause was clear, took ten seconds: open the Run\/Debug Configuration, click Modify options, and enable:<\/p>\n\n \"Add dependencies with 'provided' scope to classpath\"\n<\/pre>\nNo POM edits. No version pinning. No cache invalidation. Rerun \u2014 boots clean.<\/p>\n
The lesson, generalized:<\/b> When a Maven-launched app and an IDE-launched app disagree on a missing class that genuinely exists in your dependency tree, don’t reach for version conflicts first. Check scope. mvn dependency:tree -Dincludes= will show you exactly which dependency brought a class in and under what scope \u2014 that single fact usually explains the whole discrepancy, and the fix is often a checkbox, not a rebuild.<\/p>\n","protected":false},"excerpt":{"rendered":"
The setup: A Spring Boot service that booted perfectly with mvn spring-boot:run, but crashed immediately when launched from IntelliJ’s Run\/Debug configuration \u2014 same code, same machine, same dependencies. The error: Exception in thread “main” org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read candidate component class: … Caused by: java.lang.IllegalArgumentException: Could not find class [com.azure.cosmos.models.CompositePathSortOrder] Caused by: java.lang.ClassNotFoundException: com.azure.cosmos.models.CompositePathSortOrder Spring’s […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,34],"tags":[],"class_list":["post-830","post","type-post","status-publish","format-standard","hentry","category-java","category-maven"],"_links":{"self":[{"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=\/wp\/v2\/posts\/830","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=830"}],"version-history":[{"count":1,"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=\/wp\/v2\/posts\/830\/revisions"}],"predecessor-version":[{"id":831,"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=\/wp\/v2\/posts\/830\/revisions\/831"}],"wp:attachment":[{"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=830"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=830"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cyberaka.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=830"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}