 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2005jar assembling tool ...?
Hello all, Every time I want to deploy a jar being whether a Swing app or Java API inside Oracle I make the jar contain all dependencies like e.g. xerces.jar this avoids the need to configure class path at client side etc. This works nicely but my jars get quite inflated ... is there any tool for finding and assembling jars including from dependencies ONLY the needed classes and not the whole dependency jars ... A clear example is Log4J, in order to include the latest version -even if you only use the very basic functionality- you have to burden with all the e.g. jmx, viewer and lf5 packages ... I think a tool like this should be able to: - examine your jar parse it to get exactly all dependencies - examine recursively all dependencies for dependencies -of course- leaving out those that come with the JRE. - Build a new jar containing only what's needed ... If this kind of tool does not exist would you agree it should have a good market? :-) Thanks in advance, Best Regards, Giovanni > Hello all, > [quoted text clipped - 23 lines] > Best Regards, > Giovanni Oracle JDeveloper does this. Hello Malte, "Malte" <You_can_spam_me_here@nmalte.dk> wrote in message > Oracle JDeveloper does this. I precisely use JDeveloper, it does not do this. JDeveloper has the option to build a fat jar including all dependencies but it does NOT wipe out unused parts (packages and classes) of the dependencies list ... You always get with JDeveloper a very fat jar ... this quickly becomes unmanageable when you have many dependencies and you do not want to hack into the dependencies (removing it manually on your own) also because then you would need to do it each time any of the dependencies gets updated or you just want to get the new functionality ... Best Regards, Giovanni > Every time I want to deploy a jar being whether a Swing app > or Java API inside Oracle I make the jar contain all dependencies Isn't there a legal aspect of this? I would think at least some licenses prohibit such rebundling? Hello Jacob, "Jacob" <jacob@yahoo.com> wrote in message > Isn't there a legal aspect of this? > I would think at least some licenses prohibit such rebundling? Probably for *some* of the existing open src jars yes likely not for all of the existing open src ... besides I always build jars as components which I reuse for myself then you really want to have this functionality ... I wonder if Eclipse has this or any plugin??? Another one is AnT probably has an option for this ... I will research a bit ... Regards, Giovanni > Hello all, > [quoted text clipped - 5 lines] > dependencies ONLY the needed classes and not the whole > dependency jars ... You don't need to do this to avoid setting a classpath, just set the classpath in the manifest. As somebody else mentioned, if any of your jars are proprietary third-party libraries (JDBC drivers for example), this would almost certainly be a breach of the licence. However, if you still want to do this, I think some obfuscators have options to strip out all unused classes. Dan.  SignatureDaniel Dyer http://www.footballpredictions.net Hello Daniel, > You don't need to do this to avoid setting a classpath, just set the > classpath in the manifest. As somebody else mentioned, if any of your > jars are proprietary third-party libraries (JDBC drivers for example), > this would almost certainly be a breach of the licence. Deploying Java libraries inside Oracle (Java Stored Procedures) is a totally different story ... there is no CLASSPATH in there. > However, if you still want to do this, I think some obfuscators have > options to strip out all unused classes. I am reviewing this option ... is there any you can refer? Thanks in advance, Best Regards, Giovanni >Hello all, > [quoted text clipped - 25 lines] > > Hi Giovanni, There are probably many tools that will allow you to do this, but from my experience it could end up being more of a hassle than you imagine. Say for example that you bundle log4j with your jar. If a bug is found in log4j, then the only way to update your app is to re-package it. Whereas if you keep your jars separate, you only need to update the log4j lib. Basically, when it comes down to it, packaging things separately is done for a reason. There is nothing to stop you bundling everything, but it will come back to bite you one day. > - examine your jar parse it to get exactly all dependencies > - examine recursively all dependencies for dependencies > -of course- leaving out those that come with the JRE. > - Build a new jar containing only what's needed ... Actually, due to dynamic invocation, the task is impossible. An obfuscator does its job correctly only when supplying lengthy lists of what *not* to obfuscate (and you always miss some which makes obfuscation really expensive to support :-) For 3rd-party classes you wouldn't even know. > I think a tool like this should be able to: > [quoted text clipped - 9 lines] > Best Regards, > Giovanni Proguard is a free tool (obfuscator) that can do that. But due to dynamic invocation, I would suggest the following process: - Build a jar file of your code - use Proguard to optimise bytecode and remove unecessary classes (make sure to include dynamically called classes in the configuration) - assemble all the needed jars to you final fat jar Running a dependency/walk-through tool on third party libs is dangerous (you can never garanty all of the really needed classes are preserved) and often illegal Now it's all up to you :) JSC -- Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.