I am currently refactoring a large Java application. I have split up one of the central (Eclipse) projects into about 30 individual "components", however they are still heavily inter-dependent. In order to get a better idea of what depends on what I am looking for some way to graph the compile time dependencies.
All tools I have found so far are capable of graphing package or class dependencies or the dependencies between Eclipse plugins, however what I have in mind should just take a look at the classpath settings for each Eclipse project and build a coarser grained graph from that.
Later I will then go deeper, however right now this would just mean I would not be able to see the forest for all of the trees.
Check out JBoss Tattletale. It might not do all you ask but it's worth checking out. It's still relatively new though.
The tool will provide you with reports that can help you
Identify dependencies between JAR files
Find missing classes from the classpath
Spot if a class is located in multiple JAR files
Spot if the same JAR file is located in multiple locations
With a list of what each JAR file requires and provides
Verify the SerialVersionUID of a class
Find similar JAR files that have different version numbers
Find JAR files without a version number
Locate a class in a JAR file
Get the OSGi status of your project
Remove black listed API usage
Structure101 is capable of visualizing class and method JAR level dependencies in Jboss 5.
See the screenshot below or view it larger.
One tool that I believe would do what you want is Understand. It's not free, but you can download a free trial edition before investing any money into it.
Take a look at Dependency Finder
I am not sure if there is a(n Eclipse) classpath analysis tool.
May be Understand mentioned by MattK can help.
The closest I would pick amongst all the static code analysis tool referenced here would be JarAnalyzer (no graph though), able to detect "Physical dependencies" amongst jars.
Sounds like a use case for Degraph. It analyzes a bunch of class files and jar's, and visualizes the dependencies.
What makes it suitable for your usecase (I think) is the possibility to define arbitrary groups of classes to be bundled together. So you can reproduce your jar structure, seeing dependencies, especially cyclic dependencies.
You can unfold the groups to see their contained classes or collapse them to simplify the view.
For a quick impression what is possible, take a look at the Degraph Examples.
Example for Log4j:
JDeps is already included in the JDK, and shows JAR dependencies. For example:
jdeps -R -cp "my\jar\dir\*;my\other\jar\dir\*" my\classes\dir
Check out Class Dependency Analyzer (CDA): http://www.dependency-analyzer.org/
I have found it very useful for tidying up jars.
for the record (and for improving this knowledge base), I found Shrimp very helpful:
http://www.thechiselgroup.org/shrimp
Also, for easy dependency-checking, Byecycle is worth a try, but seems not to be updated anymore:
Byecycle
Both tools also offer Eclipse integration.
Related
One of contractors at my current project has a weird habit to deploy fixes to the production as jars and not to push fixed code to the project's git repo. There are tens of maven projects which packs to a jars
Is there any practical way to detect and plot all discrepancies between compiled jars from production and code from a repo? Currently I can decompile a jar with IDEA and compare result with code. Decompiled code is not identical to original by design so it takes ages and possibly leads to errors.
To detect changed classes, I would compile the code in the codebase and make a class by class binary comparison between the class files you just created and the ones in production. This can be easily automated.
But the real solution is of course: Your company should have a rule that only builds from the build server (Jenkins, Bamboo, whatever) that draw from the official git repo can go to production. No exceptions.
The technical solution to your problem is called Reproducible_builds.
But i donot think that you need a technical solution for the "blaming-game" but an organisational solution like overwrite the production build with your own jar compilation and refuse to pay the contractor if the problem re-appears
I was working on a project with a seriously large amount of classes that I want to compile to a jar. I know about entry-points and the manifest.txt and all the needed items inside my jar, my classes are all compiled and have the .class file and everything, but the problem is I will have to add all the class files to the final jar in compilation through a single line in Command Prompt. I was wondering and stumbled upon literally nothing in the internet if it could be done in an easier way because I will be updating my work constantly and have to recompile and re-jarify my work. I have heard of third party programs that will do the trick, but somebody on some website said that they could potentially be causing problems and stuff, so I dropped the idea quite quickly. Now that I am in a seriously tight spot though, I wish to hear opinions and suggestions on this. So to sum up:
I want a way to compile a big bunch of .class files in a single jar without typing all of them over and over again between compilations allowing me to save time and frustration.
I would prefer native stuff if this is even possible to do - e.g. the jar compiler of the JDK instead of anything third-party. If there is a way to do this using manifest or any other file in compile-time arguments, let me hear it.
Anyone who cares to suggest, discuss or give me a good reason why to or not to use third party applications for this will be most welcome.
Keep in mind that I work on Windows but my aplication will be cross-platfrom, so don't suggest as a main option some compile solution that will make a final file with a .exe extension (although if anyone knows how to do this, I would like to hear it in a comment as I wonder about this as well).
Thanks in advance and if you feel the need to ask me anything to help you reply, shoot away!
Have a look at this ant tutorial which shows how to write a simple build.xml which can compile and jar.
http://ant.apache.org/manual/tutorial-HelloWorldWithAnt.html
You can then adapt it for your own needs.
Note: ant is only suited for smaller projects like yours.
The solution to this, and related, issues, is to stop typing at the command line and use a build tool. The common tools here for Java builds are:
Apache Ant http://ant.apache.org
Apache Maven http://maven.apache.org
There are other less common ones. Both of these tools will provide you with what you need.
Just want to add some information about Ant and Maven.
In your case, you need to automate the build of your application. The basic solution would be some kind of script but it's not used at all. Nicer solution exist :
If you come from the idea of a script to automate your build, you can use a tool like Ant, it's a bit like make and such tool in the C world where you define the needed tasks for your build in a configuration file. The problem with such solution is that it allow you to define your own structure for your build and a new comer to your project may have some difficulties to understand the logic of the build.
The other approach is to describe what kind of build you want to do, organize your sources and resources as it is done in most cases (by following a convention in fact). For example, java sources are in src/main/java, tests are in src/test/java, config files are in src/main/resources, and so on. In the description of your build you will just say : this is a java project and I want to build a War web application and execute my tests using jUnit 4. The dependencies of my project are apache xerces and hibernate 4. Then, the tool will know what to do without the need to say how to do. This is the way maven do.
In short, in the Ant approch, you will say how to do what you want and in the Maven approach you will define what you want to do and the tool will know how by default.
You may also be interested in some kind of hybrid approache like the one provided by tools like Gradle.
For more information :
http://ant.apache.org/
http://maven.apache.org/
http://www.gradle.org/
Hope it helps
We have a lot of jars which have been added over a period of years to the project and their usage has not been documented anywhere. I want to figure out references of any class in the jar in java or jsp files.
Now for our new jars we don't have this issue as we use Maven and it helps us maintain dependency etc much better. But I am trying to determine some of the old jars
Is there any way in Eclipse, or any other tool, to do this?
One way which I can think of:
You can use Relief to get a view of your whole java project. I haven't used it though, but have heard good things about it.
Update:
Finding unused jars used in an eclipse project
I've trying to use Eclipse JDT AST parsing classes. After including the initial JAR, and sorting out a couple more dependencies, it is with 7+ JARs and I still having NoClassDefFoundError exceptions. This situation arises whenever I'm trying to test libraries with little or no documentation. Trial and error seems a very dumb (and annoying) approach to solve this problem.
Is there a way to automatically sort this out using Eclipse?
Update: Later I found that adding all the JARs you have, and using Ctrl-T (to view/locate types), lets you manually locate the JAR. That was the solution that Google provided so far. Is there a better way?
If you refer to this SO question Finding unused jars used in an eclipse project, you also have:
ClassPathHelper, which can quickly focus on unresolved classes:
It automatically identifies orphan jars, blocked (obscured) classes, and much more.
The only limit is dependencies that are not defined in classes, e.g. in dependency injection framework configuration files.
I have found setting up a workspace exclusively for browsing the eclipse source code incredibly useful. In this manner, you can use PDE tools like the Plug-in Spy, bundle dependency analysis, browsing the documentation, etc much like you would your own plugin projects. I found this article at Vogella a very useful guide.
If you know which bundle your desired class is you can generate the transitive closure of dependencies by creating a new OSGi launch configuration, with just the single bundle selected. By hitting the Add Required button, you can see all bundles necessary to use the one you're interested in.
Edit:
From your question it wasn't clear as to the environment you want to run the compiler in. If you're interested in an embeddable Java compiler to be run outside of an OSGi environment, may I suggest Janino.
You could use a dependency analyzer like:
JarAnalyzer
This will parse a directory full of Jars and give you an XML output dependency map, for which there are several tools for displaying in either graphical or text form.
I'd like to set up eclipse with a bunch of plugins and DB connection configurations, etc and re-zip it up so my team-mates and new starters can all be working on the same platform easily.
It seems that installing plugins is fine, but when I add in custom jars (e.g. ivy2, ojdbc, etc) they all save with full, absolute paths which probably dont exist on others machines (particularly if they unzip in a different location to me).
Anyway, I'm hoping that this idea is not silly and am working if this sort of process is documented somewhere or if anyone has any tips in general.
Thanks,
I would recommend against requiring all developers to place eclipse in the same location. There are times when some developers may want to try an alternate version of eclipse to explore a technology that requires a different set of plugins or a different eclipse base version.
Let developers install eclipse where they would like.
However, for jars that you need to run plugins (external dependencies that you need to configure for proper plugin usage):
Hardwire a directory for those jars (as opposed to the entire eclipse dir), like c:\eclipse-helpers or something.
To deal with third-party library dependencies (in the code you're developing), you have a few good choices:
Create project(s) to hold the third-party libs and check them into your source version control system (which you are using, right?). You can then add the libs to the build path(s) of the project(s) - make sure you mark them for export in the "order and export" tab of the build path page. You can then simply add these third-party projects as project dependencies.
Reference the third-party jars as CLASSPATH variables when adding them to the build path of your projects. This allows other developers to store the dependencies in different locations. Perhaps define a CLASSPATH variable (in eclipse's Window->Preferences->Java->Build Path->Classpath Variables) called THIRD_PARTY_JARS; each developer can map it to a different path where they want to hold their deps.
Reference the third-party jars as a "user library" (Window->Preferences->Java->Build Path->User library). This is similar to classpath variables, but acts as an explicit set of jars.
Include the third-party jars directly in your projects. Use this option only if you need the deps in a single location.
Although not exactly in line with the direction of the question, you could use Yoxos OnDemand. It allows you to "roll-your-own" Eclipse distro and download it as a zip. They add in their own perspective where you can add more plugins (direct from their repo), or update the plugins that you have.
Although I've never used the feature, you can make make your own stacks and name them, allowing anyone to go to the site later and download it (with the most up-to-date versions of the plugins). Also, dependencies for plugins are resolved automatically if need be.
In eclipse - in many places it's possible to use workspace relative paths or system environment infos to reference external files, too.
Another option could be to place your jars into a workspace project so that every team member can check it out from cvs/subversion/whatever and start working. Working like this ensures a reproducible environment for server builds or for desktops even after years.
Talking about Yoxos...
it provides "Workspace Provisioning" as well. This means you can attach Eclipse Preferences, checkstyle configurations and Mylyn setups additionally to your list of needed tools/plugins for your IDE to your yoxos profile.
This means your team could share a profile and would be able to start working with the same setup regardless of their OS or whatever. (Its possible to use multiple profiles at once, too.)
We did a similar thing with our development environment (it needed both Eclipse and our own plug-in which, in the early stages, had to run in a known location).
We just put it in c:\eclipse_<projName> and made that a requirement for the team. That's probably the easiest solution for you.
It's your team, you can dictate this as a requirement. Unless your team members are absolute idiots, they'll work with you.
I found Yoxos really good and it does very good work in determining dependencies.
Its really a good tool and worth giving a look.
I just started using git to manage my eclipse install. I did a write-up. The approach might work for you, and it's probably worth looking at.
If developers all don't have the same paths on their machine, instead of adding independent JAR files you could create what Eclipse calls a "library" and include a bunch of jars in that. Then another developer just has to change the location of the library and it'll pick up all the jars in there.