We are using maven for our standalone applications.currently we have two standalone application for new project and going forward it would increase. So I've deployment approach for all standalone application with dependency jars.
All application will have common jars like(spring and other open source jars), third party jars like proprietary mq,sybase and proprietary own jars and am planning to use different classpath prefix in jar plugin and came across customClasspathLayout tag in jar plugin but am not able to configure based on my above deployment structure.
For example, project 1 with below classpath entries
/jars/thirdparty/opensource/ (spring and other open source jars)
/jars/thirdparty/proprietary/ (mq and sybase and product jars)
/jars/company/ (all our company based api jars from internal nexus repository)
If required we will use application prefix before jars, I can add manual entry in jar plugin to add in manifest but i would like to configure based the source repository or some other standard approach, so that i can execute assembly plugin for profile like ( only opensource or only proprietary or only company or only application or entire dependency and application). I need to have fine control on jar location.
I though of this approach for two reasons,
I need to differentiate classpath location for different set of jars
Reduce the packaging based on need (mostly we will have application change rarely with product proprietary jars or sometimes with opensource up-gradation which could be based on stable opensource release.
Please suggest me is this possible and also welcome the feedback for different or better approach for classpath and deployment structure.
Related
I am reading Maven documentation and came across the name uber-jar.
What does an uber-jar mean and what are its features/advantages?
Über is the German word for above or over (it's actually cognate with the English over).
Hence, in this context, an uber-jar is an "over-jar", one level up from a simple JAR (a), defined as one that contains both your package and all its dependencies in one single JAR file. The name can be thought to come from the same stable as ultrageek, superman, hyperspace, and metadata, which all have similar meanings of "beyond the normal".
The advantage is that you can distribute your uber-jar and not care at all whether or not dependencies are installed at the destination, as your uber-jar actually has no dependencies.
All the dependencies of your own stuff within the uber-jar are also within that uber-jar. As are all dependencies of those dependencies. And so on.
(a) I probably shouldn't have to explain what a JAR is to a Java developer but I'll include it for completeness. It's a Java archive, basically a single file that typically contains a number of Java class files along with associated metadata and resources.
ubar jar is also known as fat jar i.e. jar with dependencies.
There are three common methods for constructing an uber jar:
Unshaded: Unpack all JAR files, then repack them into a single JAR.
Works with Java's default class loader. Tools maven-assembly-plugin
Shaded: Same as unshaded, but rename (i.e., "shade") all packages of all dependencies. Works with Java's default class loader. Avoids some (not all) dependency version clashes. Tools maven-shade-plugin
JAR of JARs: The final JAR file contains the other JAR files embedded within. Avoids dependency version clashes. All resource files are preserved. Tools: Eclipse JAR File Exporter
for more
Paxdiablo's definition is really good.
In addition, please consider delivering an uber-jar is sometimes quite useful, if you really want to distribute a software and don't want customer to download dependencies by themselves. As a draw back, if their own policy don't allow usage of some library, or if they have to bind some extra-components (slf4j, system compliant libs, arch specialiez libs, ...) this will probably increase difficulties for them.
You can perform that :
basically with maven-assembly-plugin
a bit more further with maven-shade-plugin
A cleaner solution is to provide their library separately; maven-shade-plugin has preconfigured descriptor for that. This is not more complicated to do (with maven and its plugin).
Finally, a really good solution is to use an OSGI Bundle. There is plenty of good tutorials on that :)
For further configuration, please read those topics :
Should you provide dependent libraries in client jar?
Best practices in building and deploying Clojure applications: good tutorials?
The different names are just ways of packaging java apps.
Skinny – Contains ONLY the bits you literally type into your code editor, and NOTHING else.
Thin – Contains all of the above PLUS the app’s direct dependencies of your app (db drivers, utility libraries, etc).
Hollow – The inverse of Thin – Contains only the bits needed to run your app but does NOT contain the app itself. Basically a pre-packaged “app server” to which you can later deploy your app, in the same style as traditional Java EE app servers, but with important differences.
Fat/Uber – Contains the bit you literally write yourself PLUS the direct dependencies of your app PLUS the bits needed to run your app “on its own”.
Source: Article from Dzone
Reposted from: https://stackoverflow.com/a/57592130/9470346
A self-contained, executable Java archive. In the case of WildFly Swarm uberjars, it is a single .jar file containing your application, the portions of WildFly required to support it, an internal Maven repository of dependencies, plus a shim to bootstrap it all. see this
According to uber-JAR Documentation Approaches:
There are three common methods for constructing an uber-JAR:
Unshaded Unpack all JAR files, then repack them into a single JAR.
Tools: Maven Assembly Plugin, Classworlds Uberjar
Shaded Same as unshaded, but rename (i.e., "shade") all packages of all dependencies.
Tools: Maven Shade Plugin
JAR of JARs The final JAR file contains the other JAR files embedded within.
Tools: Eclipse JAR File Exporter, One-JAR.
For Java Developers who use SpringBoot, ÜBER/FAT JAR is normally the final result of the package phase of maven (or build task if you use gradle).
Inside the Fat JAR one can find a META-INF directory inside which the MANIFEST.MF file lives with all the info regarding the Main class. More importantly, at the same level of META-INF directory you find the BOOT-INF directory inside which the directory lib lives and contains all the .jar files that are the dependencies of your application.
I am reading Maven documentation and came across the name uber-jar.
What does an uber-jar mean and what are its features/advantages?
Über is the German word for above or over (it's actually cognate with the English over).
Hence, in this context, an uber-jar is an "over-jar", one level up from a simple JAR (a), defined as one that contains both your package and all its dependencies in one single JAR file. The name can be thought to come from the same stable as ultrageek, superman, hyperspace, and metadata, which all have similar meanings of "beyond the normal".
The advantage is that you can distribute your uber-jar and not care at all whether or not dependencies are installed at the destination, as your uber-jar actually has no dependencies.
All the dependencies of your own stuff within the uber-jar are also within that uber-jar. As are all dependencies of those dependencies. And so on.
(a) I probably shouldn't have to explain what a JAR is to a Java developer but I'll include it for completeness. It's a Java archive, basically a single file that typically contains a number of Java class files along with associated metadata and resources.
ubar jar is also known as fat jar i.e. jar with dependencies.
There are three common methods for constructing an uber jar:
Unshaded: Unpack all JAR files, then repack them into a single JAR.
Works with Java's default class loader. Tools maven-assembly-plugin
Shaded: Same as unshaded, but rename (i.e., "shade") all packages of all dependencies. Works with Java's default class loader. Avoids some (not all) dependency version clashes. Tools maven-shade-plugin
JAR of JARs: The final JAR file contains the other JAR files embedded within. Avoids dependency version clashes. All resource files are preserved. Tools: Eclipse JAR File Exporter
for more
Paxdiablo's definition is really good.
In addition, please consider delivering an uber-jar is sometimes quite useful, if you really want to distribute a software and don't want customer to download dependencies by themselves. As a draw back, if their own policy don't allow usage of some library, or if they have to bind some extra-components (slf4j, system compliant libs, arch specialiez libs, ...) this will probably increase difficulties for them.
You can perform that :
basically with maven-assembly-plugin
a bit more further with maven-shade-plugin
A cleaner solution is to provide their library separately; maven-shade-plugin has preconfigured descriptor for that. This is not more complicated to do (with maven and its plugin).
Finally, a really good solution is to use an OSGI Bundle. There is plenty of good tutorials on that :)
For further configuration, please read those topics :
Should you provide dependent libraries in client jar?
Best practices in building and deploying Clojure applications: good tutorials?
The different names are just ways of packaging java apps.
Skinny – Contains ONLY the bits you literally type into your code editor, and NOTHING else.
Thin – Contains all of the above PLUS the app’s direct dependencies of your app (db drivers, utility libraries, etc).
Hollow – The inverse of Thin – Contains only the bits needed to run your app but does NOT contain the app itself. Basically a pre-packaged “app server” to which you can later deploy your app, in the same style as traditional Java EE app servers, but with important differences.
Fat/Uber – Contains the bit you literally write yourself PLUS the direct dependencies of your app PLUS the bits needed to run your app “on its own”.
Source: Article from Dzone
Reposted from: https://stackoverflow.com/a/57592130/9470346
A self-contained, executable Java archive. In the case of WildFly Swarm uberjars, it is a single .jar file containing your application, the portions of WildFly required to support it, an internal Maven repository of dependencies, plus a shim to bootstrap it all. see this
According to uber-JAR Documentation Approaches:
There are three common methods for constructing an uber-JAR:
Unshaded Unpack all JAR files, then repack them into a single JAR.
Tools: Maven Assembly Plugin, Classworlds Uberjar
Shaded Same as unshaded, but rename (i.e., "shade") all packages of all dependencies.
Tools: Maven Shade Plugin
JAR of JARs The final JAR file contains the other JAR files embedded within.
Tools: Eclipse JAR File Exporter, One-JAR.
For Java Developers who use SpringBoot, ÜBER/FAT JAR is normally the final result of the package phase of maven (or build task if you use gradle).
Inside the Fat JAR one can find a META-INF directory inside which the MANIFEST.MF file lives with all the info regarding the Main class. More importantly, at the same level of META-INF directory you find the BOOT-INF directory inside which the directory lib lives and contains all the .jar files that are the dependencies of your application.
I'm quite new to bower but not web application development. Previously, I've just downloaded the required JavaScript and CSS files from third-party libraries/frameworks and placed them into my web application's src/main/webapp/scripts (or equivalent) folder. This ensures that only the files needed by the web application are deployed.
With my default setup, the entire bower_components directory will be committed to source control and if I follow the examples for referencing a bower package, e.g.,
<script src="/bower_components/jquery/jquery.js"></script>
I'm going to end up deploying the entire bower_components directory with my web application. This seems like huge overkill (especially were I to use jQuery UI because all the themes are downloaded into bower).
Is there a best practices in using bower with a web application such that the application isn't bloated with unnecessary third-party library files? Please remember that this is also Java and Maven web application.
Seeing that you tagged maven on this question, I completely disagree with checking in 3rd party libraries, after having tasted the goodness of maven dependency management :) no matter whether it is a jar or js.
This is something that we've been trying to reconcile at my work as there doesn't seem to be a natural way to do js dependencies in maven. Specifically for bower there looks to be a good maven plugin here:
https://bitbucket.org/cofarrell/bower-maven-plugin
for which you can specify the target directory. I haven't used it yet, but I would want to have it bring in the js files to my target directory so I don't have to put it in my source. If we move forward with this, this is what I envision.
If you're interested I have more to add (since there's not a lot out there about this topic)... We are currently using maven "js" artifacts so we can leverage maven's dependency management with our 3rd party js. A plugin that we've forked to do this for us is at:
https://github.com/cameroncan/js-import-maven-plugin.
It does its job, but was built for our use case. Please submit issues if you find it is in need of genericizing. We do have to manually upload these artifacts to nexus, but that hasn't been too big of an issue.
A big advantage of using the maven dependency mechanism is the transitive dependency resolution. We have our js broken out into different modules and without maven, there will likely be collisions with the versions of our js files, resulting in a big mess in the final app that pulls all of the js dependencies in.
I just read some articles on this subject and it seems that Bower itself recommends "checking-in" the bower_components into source control:
"...you should always check installed packages into source control.”
From the articles I read, I kind of get the following:
If your project is to be consumed by others (eg: as a bower package too), then don't include bower_components in source control
If your project is to be deployed, include bower_components in source control
You can use bower-installer which is a node package to control which files to be copied to your static resources folder from the downloaded distribution package folder. Please look into below link.
https://www.npmjs.com/package/bower-installer
I followed below steps to select which files to be copied to my lib folder
1) Install bower-installer by runnnig npm install -g bower-installer command
2) Create 'bower_components' folder outside of your src folder.
3) Edit bower.json configuration file(in the 'bower_component's folder ) and specify path for each js library components.
4) Run bower-installer from terminal
I run many instances of the same web application under Tomcat and to save memory I copy some of the libraries to Tomcat's lib (tomcat\lib) and shared (tomcat\shared) folders. Libraries that go under lib can be found by both Tomcat and web applications, libraries that go under the shared-folder can only be used by web applications. My web application also need some libraries on the web application level so those libraries goes under WEB-INF\lib.
I have defined in my pom.xml that most libraries have a scope of provided so that they're not copied to WEB-INF\lib, however is there any way to define that I would like some libraries to go under a custom-defined folder; e.g. WEB-INF\lib\tomcat\shared and WEB-INF\lib\tomcat\lib, from where I could mover them manually to Tomcat's corresponding folders on the server?
That is not really the recommended way to package dependencies, as usually the web application would be deployed without furhter modification of the war file.
I think you can archieve what you want using the dependency:copy-dependencies goal, but it would require some configuration. You would have to set includeScope to provided, set the correct outputDirectory and then define the artifacts with the includeGroupIds or includeArtifactIds options.
Make a separate maven project which contains the war file and define the dependencies which should be located in the share-folder as scope: provided. Furthermore create an other separate module which has these dependencies and create an appropriate archive from it via maven-assembly-plugin...
I am writing an application that integrates Geoserver with a custom component, intended to be hosted on a single servlet engine. Both are Maven based projects, and I would like to stay in Maven land to package it all into a nice distributable. The general idea I have is to add another module to my application that packages the application itself, Geoserver and all dependencies into one nice archive.
I am aware of the maven-assembly-plugin and its capability of storing all dependencies in a target folder, but I am not sure what would be the best way to create a package that it easy to deploy. Googling for any examples has not been successful.
Extra bonus points if the module can be started via mvn jetty:run.
Have you considered packaging them into an EAR project. It will bundle a set of WARs (and jars), and allows you to specify or generate a deployment descriptor.