Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Banging my head bloody trying to reconfigure bootRepackage in Gradle #1310

Closed
bluzcat opened this issue Jul 29, 2014 · 4 comments
Closed

Banging my head bloody trying to reconfigure bootRepackage in Gradle #1310

bluzcat opened this issue Jul 29, 2014 · 4 comments
Labels
status: invalid An issue that we don't feel is valid

Comments

@bluzcat
Copy link

bluzcat commented Jul 29, 2014

Hi. I've now spent 4 days trying to accomplish what should be a trivial task with Gradle and the spring-boot plugin's bootRepackage task. I'm developing in a multi-project setup. We're using Spring Boot (love it for the most part). Gradle builds a jar file for each of my sub-projects (by default). So my layout is similar to this:

a: 
  b: build/libs/b.jar
  c: build/libs/c.jar
  d: build/libs/d.jar

Project 'b' is the project where the spring-boot plugin is used, and that's where the fat jar is created. Project b depends on c and d. The problem I'm having is that the code from the c and d projects gets included as jar files. I.e. in the fat jar, I get:

lib/b-0.0.1-SNAPSHOT.jar
lib/c-0.0.1-SNAPSHOT.jar

I don't want this as it's causing issues for certain other classes outside of my control, that are unable to find resources inside nested jar files. So I simply want to include the classes and resources directly inside the fat jar. Like this:

b/some/path/Foo.class
b/some/other/path/Bar.class
c/...

I've managed to add the classes/resources as files like the example above, but bootRepackage still includes the jar files IN ADDITION to the classes/resources. This is causing problems, and I just don't want the jar files included at all. I have tried everything I can possibly come up with. I've followed the recipes from http://docs.spring.io/spring-boot/docs/current/reference/html/build-tool-plugins-gradle-plugin.html but I just can't get bootRepackage to do what I want. I've tried using exclude() in the jar task, I've tried creating a custom jar task, I've tried modifying the configuration, I've tried excluding from the custom configuration, and I've tried adding an explicit doLast() kludge task to bootRepackage which will use the zip4j library to remove the undesired nested jars from the fat jar, but no matter what I try, bootRepackage still overwrites my fat jar file with a version that contains the nested jar files. I'm at my wit's end. This should be as simple as a couple of lines of code in the Gradle file, but it has consumed 4 days of valuable developer time.

Also, I'm getting warnings from Gradle when I try using the properties mentioned in the spring-boot/bootRepackage documentation. When trying to add something like:

springBoot {
  excludeArtifactIds = "..."
}

I'm seeing this warning message when I run the build:
Creating properties on demand (a.k.a. dynamic properties) has been deprecated and is scheduled to be removed in Gradle 2.0. Please read http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html for information on the replacement for dynamic properties.
Deprecated dynamic property: "excludeArtifactIds" on "org.springframework.boot.gradle.SpringBootPluginExtension_Decorated@6740559f", value: "lib/common-0.0.1-SNAPS...".

Any help with this issue is much appreciated! Thanks.

@bluzcat
Copy link
Author

bluzcat commented Jul 29, 2014

I'm using Spring Boot 1.1.4 in case that's important.

@philwebb
Copy link
Member

I sense the frustration here, however, "Banging my head bloody" is not a great way to start a bug report. In general, this kind of question would be better asked on stackoverflow before raising an issue here. Having said that....

Currently the repackage task does not offer any direct customizations for the kind of thing that you are looking to do. There is no way to exclude specific nested jars. Applying exclude() on the jar task won't help because repacking occurs after the original jar (that doesn't yet contain nested jars) has been created.

The good news is that Gradle is quite flexible so I think that you can achieve the result that you want by defining a custom configuration. You could for example declare a provided configuration like this:

configurations {
    provided
}

Then declare dependencies on c and d using that configuration:

dependencies {
    provided(project(":c"))
    provided(project(":d"))
    // ...
}

You'll also need to add that configuration to your main source set:

sourceSets.main.compileClasspath += configurations.provided

The repackage task only adds jars from the compile and runtime configurations so dependencies in your new provided configuration won't appear as nested jars (you obviously still need to somehow get the classes from c.jar and d.jar into b.jar).

I've created a sample project that you can take a look at and some more information about the general configuration technique can be found here.

@bluzcat
Copy link
Author

bluzcat commented Jul 30, 2014

Firstly, my apologies for the dramatic intro. I certainly didn't realize that I was actually filing a bug report. I thought this was a public forum for Spring Boot related issues. In the last few days, I've scoured the web for similar issues (including the Gradle and StackOverflow forums) without much luck. Just this afternoon, I came across this github site, and I read some other comments about the plugin, so I thought that it was the right place for questions. I'll pay more attention in the future :-)

Many thanks for your suggestion, I will certainly try it out as well as checking out the sample project. Best regards.

@O-OF-N
Copy link

O-OF-N commented Apr 2, 2015

I added the following in my jar task of all the sub projects and got my jars spared.
bootRepackage.enabled = false

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: invalid An issue that we don't feel is valid
Projects
None yet
Development

No branches or pull requests

3 participants