I have a struts project. It has many jars in its APP-INF/lib directory and the packaged ear size is huge. I also have another spring boot project and it has one utility class.
My target is to use that utility from the struts project.
The problem here is, if I include this spring-boot jar in the pom.xml, it includes the spring boot jar with all its dependency which are already present in the struts project. This makes the ear more huge. The jars are copied twice in a way. Basically the project becomes like this:
struts-project
--APP-INF/libs/
----**.jar (many jars)
----spring-boot-project.jar
--------BOOT-CONF/libs/
-------------**.jar (again many jars, most of them already in one level above directory)
My end goal is to use the utility, for which I have 2 ways (what I have in mind, more ways possible)
Include the spring boot jar, but find a way to reduce packaged ear size.
Create a rest api in the spirng boot project just to use the jar. But if the service is down anyhow, it will have huge impact on main application - so don't want to use this way also.
Please suggest more ways to achieve my end goal. Or any improvement/suggestion in the above approaches.
In order to use utility / commons classes in many project you should create separate project for utility.
Utility project should not use any dependency or very little in other case you should redesign it.
Related
I have multiple application deployed in mule esb. All these application have same set of jars so I am trying to create a shared library . If I place all the jars in %mule_home%/lib/user then it works fine, but I am trying to put these jars into my custom folders.for example %mule_home%/lib/user/hibernate then I am not able to deploy my applications.
Ok let's say that if you where using maven you didn't had this issue, as everything was packaged with your deploy without issues.
Anyway if this is still the way you want to go it's normal that he will not pick up on subfloder, they are not on the path.
One way you have is to create an unique jar containing all your jars and that put it in lib/users.
There is probally also another way, even if I didn't tested it and I would also not encourage.
You could go play with the mule wrapper.conf and add folders to the classpath, as you can see around the line 118 of the file:
But again I do recommend you to use maven for painless (more or less) dependency management.
Mule allows libraries seperation by using the domains. The application domain can be configured in mule-deploy.properties. For example:
domain=hibernate-apps
Place all your libs the needed libs into the domain folder. Has been tested with Mule 3.8.5.
I have a number of internal projects that are essentially client-side web assets that I'd like to distribute to colleagues as webjars via our repository manager. So far the development process has been:
Build an example webapp that includes the web assets I'd like to distribute and test.
Create a separate project with copies of the assets located in src/main/resources/META-INF/resources rather than src/main/webapp; set <packaging> to jar rather than war in pom.xml. Build and deploy the jar artifact to the repository manager.
Create a third project as a testbed to verify that everything works correctly when the jar file from (2) is included as a project dependency.
I'd like to combine (1) and (2) so that I can test and release from a single project. I'll need to get Maven to selectively move the distributable assets to the right locations. Seems like I'd also need a way to switch <packaging> as well. Any suggestions on how to do this or better alternatives?
Unfortunately I don't think there is a good way to deal with this when using WAR-based webapps because WAR files aren't like JAR files. If you were using a non-WAR-based web framework (Play Framework, Dropwizard, etc) then you could definitely keep JAR packaging and have both the static assets and the testing app in a single JAR.
As I know it's rule to locate servlets in webapplication module. So after packaging we'll have war archive.
But later I need servlets to use like library. So as we cannot use war file as library i need the jar.
The question: is it normall to refactor webmodule so that move servlets to other project(module) to package to jar archive and use it in webapp as dependency while compiling ?
It's pretty rare to have general purpose, reusable servlets (except if you're developing a framework). But if you have one, putting it in a jar to make it reusable by several webapps is the way to go.
It's not normal (or, indeed, recommended) to package servlets in a jar or to use them as "libraries". What you are supposed to do is extract and isolate any business-logic that is "common" and should be usable by others than the servlet. Those classes can then be packed in a jar that is included in the webapp war as well as any other clients/modules you have that need them.
I have a large OSGI package that I want to package and release as a single jar file. I'm trying to figure out what the best approach is for packaging multiple jars into a single large jar.
So far the best option I've seen appears to be one-jar project. However, the framework we are using pulls in jar files from a 'plugins' directory and one-jar appears to want/require all jar files to be stored only in the lib directory. There may be an easy way around this, I haven't looked fully into the architecture enough to know as I'm still trying to decide what approach is best.
any suggestions for other approaches to package the multiple OSGI bundles into one jar and/or how I would go about making it work in one-jar is appreciated.
Thanks
An alternative solution could be to run your bundles using PojoSR instead of running them in an OSGi framework. PojoSR in a nutshell implements the service layer of OSGi without the module layer. One of the side effects of that is that you can easily package your application as an executable JAR file. When you run that JAR it also does not need to create a bundle cache on disk.
For more information on PojoSR, go to:
http://code.google.com/p/pojosr/
http://luminis-technologies.com/?p=358
http://www.infoq.com/news/2011/10/pojosr
Using the Apache Felix Maven Bundle Plugin, I believe the option might accomplish what you are looking for. http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
Apache Sling's maven-launchpad-plugin generates a runnable jar (and optionally a war file and a Karaf descriptor) from a list of bundles, see http://sling.apache.org/site/maven-launchpad-plugin.html
The Sling installer can be used to load additional bundles from the filesystem or other sources, see http://sling.apache.org/site/jcr-installer-jcrjcrinstall-and-osgiinstaller.html
The tutorials said I needed to import the Spring.jar and commons-logging.jar files in order to get going. They were using Spring 2.5.6.
The 3.0.5 version I'm using doesn't contain the spring.jar file. What is it referred to now instead?
Much will depends on what parts of Spring you actually need. Spring contains a lot of modules in it and they are not bundled together anymore. This Maven repository lists all released spring artifacts. Look for ones that start with spring- and navigate inside to see if they are released in 3.0.5. If they don't - you don't need them. And files named pom.xml inside those directories may give you an idea on what external libraries you will need.
The Spring JAR files are in the dist directory of the download. Since you're working through tutorials I wouldn't get wrapped up in the exact required JAR files; just put them all in your classpath. It's not like you're going from tutorials straight into production.
As of Spring 2.5 a lot of files were split out into their own JAR files (such as spring-web.jar and spring-webmvc.jar). I don't know that there's a mapping somewhere of old -> new JAR files so if you really want to get the exact JAR files needed with no extras you can download an old copy of Spring and look in the JAR file yourself, then find the new JAR files with those classes.
Incidentally, Spring 3.0.5 doesn't come with the required dependencies. Spring 3.0.2 was the last one to package those up... Look for the download titled "spring-framework-3.0.2.RELEASE-dependencies.zip". I'm sure someone is going to comment, "use Maven!" but not everyone uses Maven or Ivy.