I came across this pom.xml file of a sample spring boot project. I was surprised to see dependency section for client side javascript libraries like bootstrap and jquery inside it.
I would like to know what are these dependencies, what do they offer and is there any advantage of using them in a Spring Boot application?
This is a special project called WebJars.
It aims to package most popular JavaScript libraries into JAR files that could be used in the Java projects as a Maven/Gradle/etc dependencies.
Some of its benefits are:
you don't need to import all the JS libraries into your version control system (Git, for example)
you can easily manage JS libraries and its versions by updating and rolling them back, like you do with other Maven dependencies
other benefits (like resolving transitive dependencies) are listed on the official site
See also: Utilizing WebJars in Spring Boot
This allows a dependency management for js libraries/frameworks over maven. That's all.
Alternately, you could do this as well with bower or node.js
Related
I've just encountered an issue regarding licensing with spring-boot-starter-aop.
spring-boot-starter-aop comes with a non-optional compile transitive dependency to aspectjweaver.
aspectjweaver though is licensed under EPL 1.0 which as far as I understand requires any project using it to have its source code made public. Since we're developing a commercial product we cannot make the code public.
Does that mean that Spring AOP can only be used for open source projects? Or is this a problem only if I add the dependency through Spring Boot Starter. Is there any other way to use Spring AOP without aspectjweaver?
Moreover, other Spring Boot Starters have a dependency on spring-boot-starter-aop like spring-boot-starter-data-jpa (for some reason). But in this case I was able to exclude just the aspectjweaver dependency so there would be no licensing infringements and apparently the project still works as intended.
EPL does not prevent you from building closed proprietary software using EPL licensed libraries.
You don't need to worry - there are thousands of closed source projects built on the top of Spring AOP.
I've been looking for the answer to this for a few days and have turned up empty.
I'm devving a Confluence plugin that integrates with a 3rd party app. This 3rd party app has a nice REST API and they even provide a Java SDK (yay!). Except.....the Java SDK has bundled a version of Jersey (1.18) that conflicts with Confluence's forked version of Jersey (1.8-atlassian_15). The SDK was not released as a Maven jar (or at least there's no pom.xml included). There ARE other pom.xml in the jar's META-INF for the dependencies it uses, but the SDK itself is just released as a jar download by the vendor.
So as I've done in the past, I mvn install:install-file the sucker with my own groupId and artifactId, thinking it'd be fine. Intellij recognized the library, everything compiled nicely, and then I tried my test call to the REST API. This is when it threw an error that made it evident that there's a conflict between the versions.
SOOOO. Is there anyway to get around this? Can I "sandbox" the SDK jar in a way the executes code in its own deal without being exposed to the nasties of Confluence's builtin version of libraries the SDK uses? I have a feeling that even after the Jersey dependency is resolved (if that's even possible) there will be other issues....The SDK also bundles the specific version of Jackson, Swagger, etc. with it.
I attempted to decompile the jar and include the decompiled code in my project, but that just had all of issues I'd rather not deal with ever again.
I have reached out the SDK devs to see if they could release a more maven-friendly release, but I'm not hopeful this will be done at all, and even it is, their release cycle is much different than my own requirements (read: I need a solution now). This is my last-ditch effort before rewriting the REST client from scratch.
Can I "sandbox" the SDK jar in a way the executes code in its own deal without being exposed to the nasties of Confluence's builtin version of libraries the SDK uses?
Sure you can. Often-used way to do this is to use Maven shade plugin that transforms an existing jar to a shaded jar, using another package hierarchy and getting rid of the package naming conflict. See also the documentation about relocating packages. I suggest you use that - that's what I've done in cases like this (though I haven't done confluence plugin development, but it should be the same thing as with other platforms).
i have a question about maven transitive dependency.
i have a project A and dependency the project b and spring 2.x but the project b dependency spring 3.x
you known the spring framework splited several modules.
so the problem as below.
if i exclusive the spring3.x dependency in project A i'm afraid the project can running because the project b need spring3.x api and project A dependency B
if i remove the spring2.x in project A ,i'm afraid the project A can't running too,maybe some old api be removed at spring3.x
anybody have some solutions for this scenario
This is not a maven or spring issue - its more related to the design of your software. You need to make a decision which spring version you are going with. Usually upgrading spring is not the biggest mess, sometimes you need to change the set of dependencies as they move stuff around - but Google is quite helpful with this - or findjar.com.
I assume both A and B run in the same process (or classloader)? You are not deploying them separately? So you need to decide which spring version to use. If you can't change dependencies in project B use their spring version. If you can: take the newer one and upgrade spring in project B.
Maven sadly does not include a magic jar mechanism. If you need different versions of the same jar around something like OSGi might help - but thats a looooong shot. And a complicated one as well. And usually not necessary. Maven (as you have noticed) helps you to manage the dependencies. Which one to use is your choice to make.
We're currently developing a Grails plugin that is meant to be a shared library of goodies for several different applications. This plug-in does the management around GORM and caching and, as such, it includes both the hibernate plug-in and the cache and cache-ehcache plugins. Hibernate and cache-ehcache plug-ins both want to import the ehcache-core jar dependency, but with different versions. The version of ehcache-core that I want is the one in the cache-ehcache plug-in so I've configured my BuildConfig.groovy like so:
compile(':hibernate:3.6.10.10', { excludes 'ehcache-core' })
compile ':cache:1.1.8'
compile ":cache-ehcache:1.0.4"
When running tests in this plug-in everything works just fine. However, once I include this plug-in in one of my real applications the excludes directive seems to be ignored and the transitive dependency on the hibernate plug-in starts pulling in ehcache-core. Having two versions of ehcache-core breaks many different aspects.
I've checked the grails dependency-report for my applications and it shows the chain of dependencies from my app -> my utility plugin -> hibernate plugin -> ehcache-core intact. The same dependency report run on the plug-in itself just points to the hibernate plug-in and then stops with no dependency on ehcache-core.
Anyone out there have any ideas as to why the dependency exclusion works while running the plug-in, but not while running the application that depends on the plug-in?
This is due to the change to the Maven/Aether dependency manager library. It's somewhat less buggy than Ivy and significantly faster, but is missing a lot of features that many of us are used to. One easy fix is to switch back to the Ivy resolver. You would only need to do that for the plugings when publishing, but not necessarily when using them since you need a defailed .pom file with exclusions listed so the consuming dependency manager knows what to ignore. If you use Aether the .pom files only include dependencies.
EDIT: I was focusing on the correctness of the pom files, and or course exclusions like this should work (although it'd be better to have correct poms and not have to force every user to fix this on their end.)
The issue might be that your group or name are different (e.g, "cache" vs. "ehcache"), and then they cant evict/exclude another. Or the jar might be coming from a different dependency and they exclusions are not global. There may be a way to set a global exclusion, but I don't know of one and there's nothing in the docs.
I'm trying to figure out how to make my WARs lighter by putting JasperReports, Apache POI and other heavy libs directly to JBoss AS by using JBoss Modules.
Now, Jasper uses many many libraries to generate PDF or XLS files as you can see here. Our templates are pretty old and we are stuck with old jasper version 3.7.1 which of course uses older versions of libraries such as commons which are already present on JBoss AS 7.1.1 modules.
How can I make one "big" module which will contain all jars used by Jasper and keep other parts of application using newer modules?
Putting all jars into separate directories seems so much work without guaranteed success, can we put everything into one module without creating package alike directories?
We started with JBoss modules recently and wrote a small plugin for Maven that generates module folders with module.xmls based on XML descriptors. The plugin is called smartics-jboss-modules-maven-plugin and you'll find additional information about it at the project's blog.
We just started to work with it, but it already makes the process of synchronization between the POM and the module.xml (plus directory structure) for our projects very easy.
The downside of this approach is that you have to learn an additional XML descriptor and have to configure an additional Maven plugin.
If you want to give it a try, the plugin is licensed under Apache License 2.0.
The creation of JBoss modules for external libraries can be automated through maven as explained in another answer here on SO. The author has posted a GitHub project too. This can lessen the pain in managing lots of transitive dependencies.