adding Cloud SDK like this for CF:
compile "com.sap.cloud.s4hana:s4hana-all:${cloudSDKVersion}"
compile ("com.sap.cloud.s4hana.cloudplatform:scp-cf:${cloudSDKVersion}")
leads to duplicate jars in spring boot jar which is deployed to CF.
examples:
core-2.3.1.jar
connectivity-2.3.1.jar
This leads to :
ClassNotFoundExceptions during runtime
prevents cf push commands with error:
Comparing local files to remote cache...
Aborting push: File BOOT-INF/lib/core-2.3.1.jar has been modified since the start of push. Validate the correct state of the file and try again.
FAILED
gradle skips the component name when building the boot package.
After some googling around this was the solution:
https://github.com/spring-projects/spring-boot/issues/10778
bootJar {
rootSpec.filesMatching('**/*.jar', { jar ->
String groupId = jar.file.parentFile.parentFile.parentFile.parentFile.name
jar.name = "$groupId-${jar.name}"
})
}
Related
(for reference I am using: IntelliJ as my IDE, Kotlin as the language, and Gradle Kotlin for build)
The package is successfully published to the GitLab Project's Package Registry, it is listed as a Maven. I can download and access the .pom/.jar/.module file in the GitLab Package Registry, additionally the link to the gitlab repo .pom file (as in the error message below) when clicked will download the .pom for the package (this has me super confused). However when I want to use it as a dependency in a different project it cannot be resolved. I am using an Access Token for authentication of this project. This is the error I am getting when I attempt to build / sync my gradle project:
Execution failed for task ':compileKotlin'.
> Error while evaluating property 'filteredArgumentsMap' of task ':compileKotlin'
> Could not resolve all files for configuration ':compileClasspath'.
> Could not find <group>:<projectName>:<version>.
Searched in the following locations:
- https://repo.maven.apache.org/maven2/com/example/<projectName>/<version>/<projectName>-<version>.pom
- https://gitlab.com/api/v4/projects/<packageID>/packages/maven/com/example/<projectName>/<version>/<projectName>-<version>.pom
Required by:
project :
Possible solution:
- Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html
(The group, projectName and version are all filled in with the those things for the project)
I did read the documentation provided as a possible solution as well as a large number of other sources with potential fixes or ways of setting it up, however I cannot seem to find how to solve or correctly import and use my maven repo. Other sources that I have already checked out / tried to use are:
https://www.jetbrains.com/help/space/publish-artifacts-from-a-gradle-project.html#publish-maven-artifacts-using-the-gradle-command-line-tool
https://gitlab-docs.creationline.com/ee/user/packages/maven_repository/
This is what I have in my gradle.build.kts of the package which is attempting to import / use the dependency (again of course packageName, group, version etc are filled in)
val gitLabAccessToken: String by project
repositories {
mavenCentral()
maven {
url = uri("https://gitlab.com/api/v4/projects/<projectID>/packages/maven")
name = "GitLab"
credentials(HttpHeaderCredentials::class) {
name = "Deploy Token"
value = gitLabAccessToken
}
authentication {
create<HttpHeaderAuthentication>("header")
}
}
}
I'm certain I am missing something silly and small, if there is anything more that is needed to get this working so that I can import and use it I will be happy to provide.
I knew it was something stupid, thank you #aSemy, It was that I had missed the dash between Deploy and Token (Deploy Token -> Deploy-Token) and that fixed it. I cannot believe I wasted hours over a dash.
The Solution to this Problem is adding the dash between Deploy and Token.
User #aSemy noticed this when I did not.
I have the problem that migrateDb using Flyway in a Gradle project sometimes causes
Unable to obtain inputstream for resource: META-INF/db/mysql/V1__script.sql
This error doesn't occur all the time but only sometimes but if it happens it's quite persistent and also a clean/rebuild of the project doesn't solve it.
The SQL script that is mentioned is contained within a JAR file that is referenced from the project as part of a multi module project.
My researched only brought me to https://github.com/flyway/flyway/issues/702 but this didn't lead me to the right way.
I'm also very confused that flyway is able to find the file during the classpath search but is then not able to get the input stream.
If you should need any further info please ask.
Further debugging: It seems that the error seems to happen as soon as a new file is added to the DB JAR. After rebuild and migrateDb the error occurs. If I remove the script again the error still occurs although the script is not in the generated JAR anymore. So I guess the classpath for searching for scripts and retrieving input stream is different. Does anybody know what differences there might be?
Complete stack trace:
Caused by: org.flywaydb.core.api.FlywayException: Unable to obtain inputstream for resource: META-INF/db/mysql/V1__script.sql
at org.flywaydb.core.internal.util.scanner.classpath.ClassPathResource.loadAsString(ClassPathResource.java:84)
at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.scanForMigrations(SqlMigrationResolver.java:139)
at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.resolveMigrations(SqlMigrationResolver.java:99)
at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.resolveMigrations(SqlMigrationResolver.java:49)
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.collectMigrations(CompositeMigrationResolver.java:122)
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.doFindAvailableMigrations(CompositeMigrationResolver.java:104)
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.resolveMigrations(CompositeMigrationResolver.java:90)
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.resolveMigrations(CompositeMigrationResolver.java:43)
at org.flywaydb.core.internal.info.MigrationInfoServiceImpl.refresh(MigrationInfoServiceImpl.java:114)
at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:164)
at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:157)
at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:75)
at org.flywaydb.core.internal.command.DbValidate.validate(DbValidate.java:157)
at org.flywaydb.core.Flyway.doValidate(Flyway.java:1280)
at org.flywaydb.core.Flyway.access$100(Flyway.java:71)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:1176)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:1168)
at org.flywaydb.core.Flyway.execute(Flyway.java:1650)
at org.flywaydb.core.Flyway.migrate(Flyway.java:1168)
at org.flywaydb.gradle.task.FlywayMigrateTask.run(FlywayMigrateTask.java:28)
at org.flywaydb.gradle.task.AbstractFlywayTask.runTask(AbstractFlywayTask.java:382)
Gradle Task:
// task that migrates the database
task migrateDb(type: org.flywaydb.gradle.task.FlywayMigrateTask) {
// parse hibernate config
def hibernateConfig = parseHibernateConfigByStageParameter()
// set config
url = hibernateConfig.url
driver = hibernateConfig.driver
user = hibernateConfig.username
password = hibernateConfig.password
locations = [ "classpath:${flywayDbPath}/${hibernateConfig.dbType}" ]
table = 'schema_version'
outOfOrder = true
ignoreMissingMigrations = true
}
Gradle dependency:
// dependencies
dependencies {
[...]
runtime project(':core:db:mysql')
[...]
}
During further testing I noticed that the error seems to be because of the Gradle Daemon. Adding --no-daemon to the migrateDb call works fine and doesn't trigger the error.
That's fine for me for now.
It turns out that I was deploying and old .war, which was built with some .sql files that were not around anymore.
Then I fixed this by running gradlew clean build
I am in the process of migrating an existing app from Spring-Data-Neo4j 3.x to 4.1 using neo4j-ogm 2.0.4.
After overcoming some obstacles, it is now running fine when launched directly from IDE.
However it doesn't find any DomainEntities when I run it via a Spring Boot runnable jar:
(ClassPathScanner.java:132) Classpath elements:
(ClassPathScanner.java:134) D:\Programme\Project\myProject.jar
(DomainInfo.java:108) Starting Post-processing phase
(DomainInfo.java:74) Building annotation class map
(DomainInfo.java:87) Building interface class map for 0 classes
(DomainInfo.java:136) Checking for #Transient classes....
(DomainInfo.java:155) Registering converters and deregistering transient fields and methods....
(DomainInfo.java:159) Post-processing complete
(DomainInfo.java:69) 0 classes loaded in 40179 milliseconds
The executable jar is built using the Spring Boot Gradle Plugin which allows to make a jar executable:
springBoot {
executable = true
}
I've attached to the app via remote debugging when the jar starts and found that org.neo4j.ogm.scanner.ClassPathScanner#scan only contains my jar as classPathElement. According to the code, this should now be scanned as a zip/jar file. When classPathElement.isFile() is executed however, this evaluates to false and the jar is skipped.
Why is that the case? Is an executable jar not a file?
What steps can I take to get this running? I could probably use some other deployment mechanism, but I found this fairly simple and well working.
I did some additional investigation and it turned out that this was not related to the runnable jar at all. This was actually caused by having a space in the path to the jar file.
I think that is a perfectly valid case and am not sure why this doesn't work. In my case it was ok though to simply rename the respective folder and remove the space.
I have a Spring Boot Gradle project setup in Spring Tools Suite (3.7.2 RELEASE) with the following source folders:
- src/integration-test/java
- src/integration-test/resources
- src/main/java
- src/main/resources
- src/test/java
- src/test/resources`
Whenever I run the application or unit tests from within STS, I see that STS is using the resources found under src/integration-test/resources.
I see a duplicate resource warning in STS for files which exist in all 3 resource source folders. For example, I have an application.properties in all 3 source folders and I see following:
The resource is a duplicate of src/integration-test/resources/application.properties and was not copied to the output folder
If I run the application as a JAR or unit tests/integration tests from the command line (via gradle build), everything seems to use the correct resources. This makes me believe it is a problem with how STS/Eclipse is handling gradle.
Does anybody know of how I can configure STS to use the correct resource source folders when using gradle?
I think my problem may be related to (or the same as?) Spring Boot incorrectly loads test configuration when running from eclipse+gradle, https://issuetracker.springsource.com/browse/STS-3882, https://issues.gradle.org/browse/GRADLE-1777
I also tried the solution found here, but that seems to only fix Maven builds:
Spring Tool Suite finds spring-boot integration test configuration and does not start main application
I think my problem may be related to...
Yes, it is related but in my opinion not the same. That problem is caused by the runtime classpath being incorrect. This problem is an error coming from the eclipse project builder so it is a compile-time issue.
The problems are closely related though. Depending on your point of view, you could say they are the same (incorrect mixing of test and compile-time classpaths).
Here, specifically, the problem is that the eclipse builder tries to copy all the resources it finds in source folders to the project's single output folder. Each source folder has a 'application.properties'. The builder warns that it could not copy some of them because one would overwrite the other.
I think there may be a solution for this problem. But it is a solution that really should come from Gradle + ( BuildShip | STS Gradle Tooling) than from you.
It is possible in Eclipse to configure each source-folder individually to target a specific outputfolder. Maven + M2E are doing this correcty, but Gradle + (BuildsShip | STS Gradle Tooling) combdos do not.
For example this is what maven puts into the eclipse .classpath file when it configures a test resources folder:
<classpathentry excluding="**" kind="src" output="target/test-classes" path="src/test/resources">
<attributes>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
Notice how it explicitly sets the output folder for that entry (to something different from the project's default output folder).
You may be able to address the problem yourself by modifying the .classpath for a gradle project in a similar way. Either by doing it manually or from your build.gradle.
I'm not sure this is worth it however as you will then likely still get hit by the runtime classpath issue (since these folders will still be added to your runtime classpath, your runtime classpath will end-up with two appication.properties resources, one which will 'shadow' the other. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=482315)
I would say, the right thing to do is add a comment to the issue I linked, and hope they fix it soon as there is only so much you can do yourself by hacking the build.gradle file to modify the .classpath (this can not solve the runtime classpath issue, but in order to solve the runtime classpath issue, they would have to configure source folders to target individual output folder similar to what m2e does).
I would add this as a comment to #Kris's answer but it's too long.
I have solved the runtime classpath issue by adding the code below to my build.gradle file. The code generates an Eclipse launch configuration for the Spring Boot application class and includes only the runtime classpath (i.e. no test JARs).
My project uses the Gradle 'eclipse' plugin to generate the Eclipse project files (which I then import into Eclipse). Running the eclipseClasspath Gradle target will generate the launch file in the project's root directory.
def mainClassName = "com.example.MyApplication"
task eclipseApplicationLaunch {
group "IDE"
description "Generate an Eclipse launch configuration file for the Spring Boot application class"
}
eclipseApplicationLaunch << {
def writer = new FileWriter("${mainClassName.substring(mainClassName.lastIndexOf(".")+1)}.launch")
def xml = new groovy.xml.MarkupBuilder(writer)
xml.doubleQuotes = true
xml.launchConfiguration(type: "org.eclipse.jdt.launching.localJavaApplication") {
listAttribute(key:"org.eclipse.debug.core.MAPPED_RESOURCE_PATHS") {
listEntry(value:"/${project.name}/src/main/java/${mainClassName.replace(".","/")}.java")
}
listAttribute(key:"org.eclipse.debug.core.MAPPED_RESOURCE_TYPES") {
listEntry(value:"1")
}
listAttribute(key:"org.eclipse.jdt.launching.CLASSPATH") {
listEntry(value:"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\r\n<runtimeClasspathEntry containerPath=\"org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8/\" javaProject=\"${project.name}\" path=\"1\" type=\"4\"/>\r\n")
listEntry(value:"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\r\n<runtimeClasspathEntry path=\"3\" projectName=\"${project.name}\" type=\"1\"/>\r\n")
configurations.runtime.resolvedConfiguration.resolvedArtifacts.each { artifact ->
def filePath = artifact.file.canonicalPath.replace("\\","/")
listEntry(value:"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\r\n<runtimeClasspathEntry externalArchive=\"${filePath}\" path=\"3\" type=\"2\"/>\r\n")
}
}
booleanAttribute(key:"org.eclipse.jdt.launching.DEFAULT_CLASSPATH", value:"false")
stringAttribute(key:"org.eclipse.jdt.launching.MAIN_TYPE", value:"${mainClassName}")
stringAttribute(key:"org.eclipse.jdt.launching.PROGRAM_ARGUMENTS", value:"--spring.profiles.active=local --spring.config.location=conf/")
stringAttribute(key:"org.eclipse.jdt.launching.PROJECT_ATTR", value:"${project.name}")
stringAttribute(key:"org.eclipse.jdt.launching.VM_ARGUMENTS", value:"-Djava.net.preferIPv4Stack=true")
}
writer.close()
}
eclipseClasspath.dependsOn eclipseApplicationLaunch
I haven't modified the Eclipse .classpath file as per Kris' suggestion. Instead, I have added #Profile("test") to my test application class and #ActiveProfiles("test") to my test classes.
I have a simple use case of building an OSGi bundle using Gradle build tool. The build is successful if there are java files present in the build path, but it fails otherwise.
I am using 'osgi' plugin inside the gradle script and trying to build without any java files. The build always fails with following error:
Could not copy MANIFEST.MF to
I am sure there must be some way to do it in Gradle but not able to fine. Any idea what can be done to resolve this depending on your experience.
I ran into this today as well, and #Peter's fix didn't work for me (I hadn't applied the java plugin in the first place...). However, after hours of Googling I did find this thread, which helped me find the problem.
Basically, it seems that the error occurs (as Peter stated) when no class files are found in the jar - my guess is because the plugin then cannot scan the classes for package names on which to base all the Import and Export information.
My solution was to add the following to the manifest specification:
classesDir = theSourceSet.output.classesDir
classpath = theSourceSet.runtimeClasspath
In my actual build code, I loop over all source sets to create jar tasks for them, so then it looks like this:
sourceSets.each { ss ->
assemble.dependsOn task("jar${ss.name.capitalize()}", type: Jar, dependsOn: ss.getCompileTaskName('Java')) {
from ss.output
into 'classes'
manifest = osgiManifest {
classesDir = ss.output.classesDir
classpath = ss.runtimeClasspath
// Other properties, like name and symbolicName, also set based on
// the name of the source set
}
baseName = ss.name
}
}
Running with --stacktrace indicates that the osgi plugin doesn't deal correctly with the case where both the osgi and the java plugins are applied, but no Java code is present. Removing the java plugin should solve the problem.
I had the same issue also when java code was present.
Adding these two lines to the osgiManifest closure fixed the problem:
classesDir = sourceSets.main.output.classesDir
classpath = sourceSets.main.runtimeClasspath
-- erik