Hi, I need help to know how to build a non executable jar.
I wrote a library that wraps spring security. It has spring boot dependecies, too.
I want this library should be used in other project as dependencies.
Then I need to know how to build a jar in the same exact way of any other dependency like apache libraries, for examples.
Is it possible? I’m trying to use artifactory, too, but the assemble plugin builds up library as:
and projects that use this dependency cannot “see” classes.
Thanx in advance
Which Spring Boot dependencies does your library have? Specifically?
I gather by: „projects that use this dependency cannot “see” classes“ you’re saying your library exposes its API as regular method calls in a JVM? It’s not a RESTful API, for example?
If so, then it sounds like you want a jar that is not a Spring BootJar.
Can a custom-built, non-Spring Boot artifact be both an executable application and also expose a regular Java API? It’s probably not hard to do that using regular, non-Spring Boot Java archiving tools. Have you looked into Gradle’s own jar configuration?
If I understand Spring Boot correctly though, then in order to have a Spring BootJar and have that same jar also do double duty as a regular, non-RESTful, regular Java method-called library, it seems like you would be forcing Spring Boot into a use case its designers probably hadn’t foreseen.
The Spring Boot docs should help.
These are my dependencies:
compile group: 'io.jsonwebtoken', name: 'jjwt', version: '0.9.1'
my library exposes some RESTfull API developed as a stardard beahviour. Then my target is to let every specific webapp to “change” those behaviour rewriting some classes that are on library.
Then, yeah, I think I don’t need a bootJar, but I need my library use spring boot dependencies like I showed to you.
Do you mean I cannot use spring boot dependencies to build a jar like this?
Thanks for getting back, rcandeli.
My first reply was based on me thinking you didn’t have a RESTful API. But now I know you do have a RESTful API. So that changes the advice I would offer. Somewhat.
My understanding is that things in Spring Boot’s
BOOT-INF/classes are not exposed as part of your application’s API.
In a Spring Boot executable that packages a RESTful API, what consumers are allowed to do and the resources they are allowed to consume, are only those behaviors and resources that the RESTful API makes available through the various HTTP methods. No?
So even though I’m not getting what you mean by: „let every specific webapp to “change” those behaviour rewriting some classes that are on library“, my advice — now that I know you do have a RESTful API — changes to either:
- somehow expose that „rewriting some classes“ use case as an operation on your RESTful API
- somehow package your finger-security API as something other than a standard Spring Boot executable
But of course, you know your own requirements better than anyone. So you’re bound to think of even better options. Which I hope you share if you do. It sounds like a really neat project.
Did the Spring Boot docs shed any light on anything for you, by the way?
TL;DR: TIL that your basic idea is doable, @rcandeli. Kinda-sorta. I presume that by now you’re probably already ahead of me on that.
Having just discovered Spring’s Getting Started · Creating a Multi Module Project code earlier today, I modified it to do a simple proof of concept. I uploaded it here.
The consuming web app in the POC is a Spring Boot executable jar. The library, however, is not.
But the library does have some Spring Boot dependencies. Specifically, stuff from spring-boot-starter. It uses the Spring Boot BOM. Specifically, through Spring’s dependency-management-plugin.
The POC is very simple, in that:
- There is only one Behavior implementation class
- The Behavior class that is passed to the library is hard-coded into the
changeBehavior endpoint of the consuming web app.
- The chosen Behavior simply prints to
- There are no automated tests
The experiment does bear out that your basic idea of a client Spring Boot executable web app having access to classes exported by a plain Java library that contains Spring Boot dependencies, is doable.
On the other hand, the guide I linked to above seems to bear out my original speculation that Spring Boot doesn’t support having an executable jar do double duty as a regular Java library.