Artifact dependencies: good practice having jar files with domain events shared? - jar

I have a couple of components (as jar files) that share another artifact (always jar) that contains only domain event classes (pojos) for an Akka project. Having this sort of artifact is it generally a good or bad practice?

Related

Is moving jar files from WEB-INF/lib and WEB-INF/lib-provided to <TOMCAT>/lib a good idea?

I have a Spring Boot MVC Application which I intend to deploy as WAR file in Tomcat8. I noticed, the WAR contains all dependencies on WEB-INF/lib and WEB-INF/lib-provided folders. I verified that moving all contents of these dependencies folders to <TOMCATDIR>/lib removes the necessity of having those jars in the WEB-INF/lib* folders, so I moved them all. The application is working as expected.
Suppose, I have many WARs that need to be deployed on the same server and most of them have similar dependencies. Having all the JARs in individual applications' library folders seems like a waste of space to me.
My question is, is it a good idea to move all the JARs from individual applications' library to the Tomcat's library? Will it cause me any problems in future? If it will, what sorts of problem am I likely to come across?

How can I build a hierarchical JAR file for a library with SBT?

I am working at a library needing some dependencies.
For ease of deployment, I want to create a JAR file containing everything, including the dependencies.
I have tried sbt-assembly - this works, but it may be inadvisable due to legal reasons, so I'm looking for a solution where the resulting JAR file has the original JAR files inside, and where the classpath entry in MANIFEST.MF is set up such that client classes may just add this "nested JAR file" into their classpaths.
Is something like this even possible? sbt-one-jar nearly does, what I want, but only for executables - my product will result in a library, so this is not a perfect fit.
As I've used SBT so far, an SBT plugin would be easiest to use, as it is rather too much work to convert everyting to maven or gradle or ... now.
After thinking a bit more about how class lookup works, we dediced to abandon this experiment.
Basically classes are loaded by ClassLoader instances, and the standard class loaders for applications use a fixed strategy of how to find classes in JAR files or directories.
It seems that to allow a library to be located in a hierarchical JAR file, we must also provide the user of this library (i.e. the library client) with a special classloader so that our client may load all needed classes from the hierarchical JAR.
This is too much work to be worth it - the whole idea of a hierarchical JAR was enteratained only to simplify deployment, and having to juggle own classloaders would nullify this simplification.
In short - possible, but probably not worth the effort.

Defference between spring security JAR files?

I am integrating security to my web MVC application and couldn't get idea what I have to do (What JARS required for it), so after some googling i found this link
Now I have download spring security 2.0.4 from spring security web site. In spring-security-2.0.4\dist folder there is some JAR files. There is some file with minimum changes e.g
spring-security-xxx-2.0.4.jar
spring-security-xxx-2.0.4-sources.jar
Please some body explain to me what is the difference between them. And which one is better from two of them to choose.
Note My existing MVC application is on spring 2.5.
I know its a very newbie question but I am learning security. Thanks
Just to clarify, this isn't really a security related question but rather a general code packaging question.
Jar files are actually just zip files and therefore can contain anything.
By convention a jar name that ends with -sources contains source code i.e. the actual .java files.
Jar files without the -sources contain the compiled java byte-code i.e. all the .class files. Essentially the files that you get when you run the .java files from the corresponding -sources jar through javac.
You only need the compiled .class files at runtime. That is why the two are split.
The -sources jar is useful at development time so that you can inspect the code that you are calling. This is especially useful if you are using 3rd party code that isn't well documented.

Received a main jar file with other jar files that need to be in the classpath. Whats the best way to include this main jar in my maven project?

So i received a java api from a client and the main code is in main.jar. But the instructions he gave me require me to add these other jars (a.jar, b.jar, etc..) into the classpath whenever I want to use main.jar. These other supporting jars are things like Xerces, jakarta-oro, and a few other publicly available libraries. The problem is i don't know what versions they are, so i'm not sure if there would be issues if i just update the pom.xml file in my app to depend on main.jar and also have dependencies to these other jars as well with the latest versions of them.
Whats the best strategy for using main.jar in my maven application? I'm planning on adding main.jar to our internal maven repository, but what should i do about the xerces, jakarta-oro, and other jars when i dont know what versions they are?
Thanks
If you are lucky the file /META-INF/MANIFEST.MF inside a.jar, b.jar etc. contains an entry "Implementation-Version" or some other useful information which tell you what version they are. If not, you can download the latest release(s) from the project web site and check if they have the same file size as your bundled dependencies.
You may also come to the idea to bundle the dependencies with the main.jar in one big jar, but this may become funny, when you have the dependencies twice in your classpath at some point in the future...
What about just asking the client what version numbers this dependencies have?
If you don't have any information about these third-party libraries, just add them to src/resources/META-INF/lib and commit to SVN. That's the best way, if we're talking about black box approach.

Handling multiple artifacts from single maven project

I have a maven project that produces many artifacts. Of course it is kind of against maven best practice (one pom one artifact), but it is Adobe Flex project that produces many *swf modules and it is really makes no sence to create a separate project for each module.
For me it would be very convinient to handle all swf modules as a single zip archive eg. zip archive would be my artifact.
So I am looking for the way to pack and unpack my zip artifact with maven.
If you have any ideas, please share then with me.
Best regards,
Max
Answer: Maven Assembly Plugin
http://maven.apache.org/plugins/maven-assembly-plugin/ and Maven Dependency Plugin http://maven.apache.org/plugins/maven-dependency-plugin/

Resources