I'm using the shadow plugin in gradle build process to package an uber jar for my executable. However, this involves datanucleus which is OSGi structured. When I use shadowJar task in gradle, the plugin.xml is lost. Does the gradle shadow plugin has a way to deal with this type of dependencies? I have been searching around but haven't found anything useful other than manually merging things or moving away from shadow plugin.
Related
I have a need to convert the maven project to gradle project. All is going fine, but there is one problem that I faced, in the current project we are using dependency management throw parent pom of maven and in gradle as long as I researched there is no possibility to do so. I was thinking to convert somehow parent pom to maven bom and use in build.gradle because I know that gradle can use maven boms.
Do anyone have better ideas how to accoplish that ?
Or may be someone also had this kind of problem, can suggest best ways to do it ?
Regards
You could use my gradle-maven-transform plugin to transform your pom.xmls into gradle scripts.
You can use the DependencyAggregator to find versions which are common across all projects and generate a root build.gradle containing the common versions.
Each project script can then reference a version variable from the root project instead of hard coding
You might choose to use nebula dependency recomnender plugin to manage common versions. The maven-transform plugin can generate scripts to support this style of declaration too
Whilst you are evaluating the gradle build you "apply" the generated gradle scripts in your gradle build. During this time both maven and gradle builds will work in parallel. Once your happy with the gradle build you copy paste the generated scripts into your build.gradle files and ditch maven for ever! Yay!
My project inherits it's compile dependencies from parent and I have no control over it - can't change them to provided. Additionally, I have added another dependency 'a:b:1.0.0' to my project's pom. I want to include only 'a:b:1.0.0' with it's own dependencies (recursively ) to my uber jar.
Seems like neither assembly nor shade plugin doesn't support such case.
How this could be done ?
Thanks
Shading recursively has some significant disadvantages. Especially, the problem of duplicate files from multiple dependencies being overwritten with only a single version of the file. This can cause some pretty annoying problems to troubleshoot at runtime. You'd be better off using something like spring boot to build a standalone jar where instead of shading files into a single hierarchy, will embed dependent libraries into itself as a subdirectory and include on the classpath for you.
http://docs.spring.io/spring-boot/docs/current/maven-plugin/repackage-mojo.html
When using some 3rd party libraries, I add a dependency to my module's build.gradle file.
compile 'com.android.support:appcompat-v7:24.1.1'
Or I add a plugin
apply plugin: 'com.neenbedankt.android-apt'
Some other times, the library requires adding a dependency to my app's build.gradle file.
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
What is the difference between these dependencies and plugins?
Why can't they all be set in a single build.gradle file?
All suggestions are appreciated, I'm having trouble searching for info on this
Three things. Gradle plugin, module dependency, a build dependency which is placed on the classpath of the build tool.
A plugin is how Gradle knows what tasks to use. There are many plugins. For more info, see Gradle - Plugin Documentation
A dependency is a library that is compiled with your code. The following line makes your module depend on the Android AppCompat V7 library. For the most part, you search Maven or Jcenter for these.
compile 'com.android.support:appcompat-v7:24.1.1'
The classpath setting is needed for Gradle, not your app. For example, this allows this includes the Gradle Build Tools for Android into the classpath, and allows Gradle to build apps.
classpath 'com.android.tools.build:gradle:2.1.2'
Why can't they all be in one build.gradle file?
They probably can be. It is simply more modular to not.
I got this answer from a colleague, and this helped me understand. "A gradle plugin is like the tools you use to build the app. The dependencies are the libraries included in the app. A gradle plugin is usually the tasks - like ktlint, etc."
I didn't understand this myself so here is what i found. My answer is based on gradle build tool.
Plugins:
Add additional tasks, repositories, new DSL elements, configuration for classpaths/build/run or dependency management for subsequent development. Plugins are developed for a larger scope of development like java, kotlin or spring-boot.
Dependencies:
modules/libraries for tasks like http, serialization or database are dependencies stored remotely at repositories or locally that are needed at runTime, test or build are resolved by gradle in a configured fashion.
Sources:
Spring boot gradle plugin: https://github.com/spring-projects/spring-boot/tree/master/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin
Gradle documentation on plugins/dependencies: https://docs.gradle.org/current/userguide/plugins.html
https://docs.gradle.org/current/userguide/core_dependency_management.html
Remote repositories:
https://mvnrepository.com/
In simple words:
Plugins are used to add some additonal features to the software/tools(like Gradle). Gradle will use the added plugins at the time of building the App.
Dependecies are used to add some addtional code to your source code, so a dependency will make some extra code (like Classes in Java) in the form of library available for your source code.
Does anyone know how to make a uber/fat/shade sources-jar (and javadoc-jar) using Gradle?
The generated Jar should not only contain the sources of the current project but also the sources of it's dependencies. I have been looking at, among others, a vanilla way and a way using the Shadow Plugin. Both work great at creating a normal uber/fat/shade jar, but none of them seems to support a way to create a sources-jar.
Use Shadow Plugin. In Maven it is called shade plugin. Does same thing. It produces an executable uber jar!
I have a Maven artifact with a couple of dependencies. I want to publish the module built into a jar as normal, but I also want to publish a jar with its dependencies inside it using the maven shade plugin. This uber jar has a different classifier.
This all works fine, except if someone pulls in the uber jar using its classifier, they still get all the dependencies of the original, which they don't need.
How can I exclude certain dependencies based on the classifier? I have tried using profiles but I can't work out how to activate a profile based on the classifier of the artifact.
I know I could have the uber jar as a whole new artifact doing the exclusion itself, but that's a bit messy, I was hoping there was a better solution?
Try optional dependency. You have to declare all of your dependencies in the uber jar artifact's optional value to true.
Also, instead of using classifier, you might want to create another artifact. You can adapt this from mockito. See mockito-core vs mockito-all.