Should I split 1 large JAR into smaller JARs?
I'm not sure how to deploy my application. It's composed of about 50 classes and at the moment compiles into one big JAR. Is that how things are done? I was wondering if I should split the application into smaller JARs according to function, as if I have to make a fix to one part, I then just distribute that one smaller file. Is this something that takes a lot of work to modify the code to make it work, or do I just select the classes in Eclipse and create the JARs? Or should I just not bother, and send out one big JAR?
Thanks
50 classes is not really a big JAR. You could go ahead with a single JAR file. In my opinion, a JAR file should contain classes, which can be logically grouped together. If you are able to form subgroups with different purposes, you might go for splitting them into muktiple jars.
Hi There,
First of all, I must tell you that making a 'jar' file an ddeploying that only to the AS will not do...... You gotta make an 'ear' or 'war' that will consist of the 'jar' files and give the 'jar' file in the Classpath....... If you use JNDI fo Database Connection, 'xml's must be written and configured correctly.....
Secondly, a 'jar' file might contain 10 to the power Infinity class files--so, that is not a problem...... make sure that only class files r put into and not anything else like the 'java' files that might make the 'jar' big.....
I think, I answered to your queries...............
Now, if you face problems again, please be more specific in what you want in the forum.........
OK Buddy, Cheers !
You should deploy a war/ear for a web application. If your application is a desktop application or a library a jar could be enough.
You shouldn't think splitting your jar looking at its size (see <jre>/lib/rt.jar), but splitting it more in a logical way in individual subcomponents, so they can be used separately. If the splitted parts don't make sense as individual components then you should go for one big jar. And after all, 50 classes is not a big jar.
Regards,
Adrian.
