request: mark jars not referenced by own
Brought to you by:
bryanth
Menu
▾
▴
Hi,
at first let me say that this is a great tool. I have been waiting for this a very long time. Excellent work!
I have a little suggestion: In a project, it is often the case that you want to know wich jars are referenced by your self written classes. So it would be nice if all jars could me marked that are not referenced by your self written classes (that reside in the project output folder).
That way you could see in a quick way wich jars are "used" by your own code and wich are not (and may be only necessary because of inter-jar referencing).
What do you think?
Best regards,
Sebastian
Addendum: It would also be nice to have an option in the context-menu when right clicking a jar that removes the selected jar from the build path (e.g. if if was an unreferenced jar).
Sebastian,
The "Locations by Locations" view (which summarizes lots of the Info at the Jar level) will show you how a location such as aa your build folder depends on (and which) jars.
I think this is sort of what you are describing although I think your idea is maybe a little stronger allowing specific marking. But I think the information is similiar.
The problem I've found with this is that you typically only use a subset of classes from a third party package, so sometimes the recursive dependencies are misleading. You can actually get by with fewer jars than the static dependencies suggest because you simply will never use the classes that require additional thirdparty stuff.
An example might be a jar that has a JMS related package, Classpath Helper will show the missing javax.jms classes (assuming you don't have a J2EE jar to resolve them). But if you never do any JMS related calls, this would be fine.
The context-menu idea is a good one. Some of the features I plan 1.2 will be focused on making it easier to find classes not on your classpath (i.e. allowing you to see classes from jars in your project or in some directory that aren't in your classpath).
From there the idea of right clicking to add a needed jar made sense. So I guess an action to remove a jar makes just as much sense.
Thanks for feedback.
Bryant
Bryant,
somehow the dependencies from our class folder into the JARs don't seem to work properly. I just tested version 1.1.6 and it seems pretty much all our own classes are ignored, the only one used is a little patch we did against Hibernate.
Do you filter on package names somehow? The only difference I notice is that our normal code is in "de.iteratec...", while the patch is in "org.hibernate...".
Otherwise pretty cool :-)
Cheers,
Peter
Hi Peter,
What platform are you on? Sascha Hunold found a bug in Linux where some directories are ignored after a (silent) error is encountered. He coded me a fix and I had planned to release it as part of a 1.2.0 beta (along with new functionality).
If you are on linux I could create a 1.1.7 with the fix.
To answer your other questions, I do not perform any name filtering accept for packages starting with java. (i.e. all the standard packages). So your de.iteratec package should be fine.
One other issue to keep in mind, Classpath Helper operates on .class files, not .java files, so if you have a project that is not compiling, you wouldn't have the .class files. So in this case Classpath Helper wouldn't see them. I'm considering digging deeper into Eclipse to pull out class information for partially built classes but that would be a large undertaking.
Let me know about the platform this is on. Thanks,
Bryant
Hi Bryant,
I'm currently testing on a Windows XP installation with Eclipse 3.1.1 running on a Sun JRE 1.5.0_06.
The project builds fine and the expected class files are all in the output folder. The Eclipse error log doesn't show anything related (nothing in the relevant time interval).
HTH,
Peter
Peter,
I've confirmed this is 100% a bug. There will be a 1.1.7 release on the Beta branch with a fix by the end of the weekend 6/25/06.
Thanks for pointing this out.
Bryant
Sounds good -- I'd love to use it to investigate the need for all the jars our project has accumulated over the years.
Cheers,
Peter
Seems to work ok. Thanks for the quick fix.
1.1.7 has been put up on the beta release download section.
sourceforge gave me a little trouble in my attempt to download, I'll double check in an hour or so once it has had a chance to replicate out to the various mirror sites.
Peter please let me know if this resolves your problem.