question: Why need it be that a jar shows itself in the Reference By and Depends On? This would seem to be a bit self evident. (Maybe this is a request also: The ability to filter out self references.)
request: The ability to filter out unresolved references. For example, aspectjweaver-1.5.jar has unresolved references to com.bea.* and com.jrockit.* which I don't use and will never use. Once I have seen the missing reference and decided that it is correct (for my environment) I would like to filter that information out so I can stay focused my actual needs.
-barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
[Jars showing self reference]
I actually personally use this alot, since it quickly shows me what files use or are used by something. It shows itself by jar because when a class depends on many jars it breaks out the classes by jar.
So in the simple case, where it only depends on itself it might look a little strange, but that's how that came about.
So are you requesting that in the single jar dependency case that it just show what it depends on? I mean it is posslbe to write classes that don't depend on the jar they are in (in terms of other classes). So it is show a legitimate dependency/reference on other classes from the jar.
The unresolved referenecs question is an interesting one. How would you expect to use that?
I know you mostly use the Java Project selection, so I assume you'd want it saved per Project. Because some global entry would probably not be the best choice (current filtering is global).
I think I like this idea. I can imagine having a per project dialog that lets me enter in package paths to ignore with regards to unresolved classes. ex.
com.bea.*
com.jrockit.*
etc.
Let me know if this is what you are thinking.
I'll explore this one, I might try to push out 1.1 then continue this on the beta branch. Since the 1.1 beta is so much better than the 1.0 I kind of would like to get the laggards onto the newer stuff. But its a good idea.
Bryant
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the package paths to ignore is what I meant. But I'm not clear on the per-project part. I have a product that is composed dozens of projects. All the jars are contained in a few "thirdparty" projects which are dependended on. For the product I am not using, eg, jrockit. I don't want to have to specify a filter for dozens of projects.
Maybe an extension of a working set -- a classpathhelper filter working set -- similar to the breakpoints working sets. The I could simply select a classpathhelper filter working set to be applied to the workspace.
-barry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Barry,
I added support for being able to specify some packages/classes as not showing up in unresolved lists. I'm still behind on the documentation, but you can access it from the main properties area of ClassPath Helper (same area as the not showing as blocked stuff).
I think I like both of these suggestions, thanks for passing them along.
btw, I sent you a personal email via sourceforge, since I've not gotten too many emails via this channel I wanted to make sure you got it. If not follow up with me at bryant_harris@hotmail.com, let me know how things are working out at the new job.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(Hi Bryant!)
question: Why need it be that a jar shows itself in the Reference By and Depends On? This would seem to be a bit self evident. (Maybe this is a request also: The ability to filter out self references.)
request: The ability to filter out unresolved references. For example, aspectjweaver-1.5.jar has unresolved references to com.bea.* and com.jrockit.* which I don't use and will never use. Once I have seen the missing reference and decided that it is correct (for my environment) I would like to filter that information out so I can stay focused my actual needs.
-barry
[Jars showing self reference]
I actually personally use this alot, since it quickly shows me what files use or are used by something. It shows itself by jar because when a class depends on many jars it breaks out the classes by jar.
So in the simple case, where it only depends on itself it might look a little strange, but that's how that came about.
So are you requesting that in the single jar dependency case that it just show what it depends on? I mean it is posslbe to write classes that don't depend on the jar they are in (in terms of other classes). So it is show a legitimate dependency/reference on other classes from the jar.
The unresolved referenecs question is an interesting one. How would you expect to use that?
I know you mostly use the Java Project selection, so I assume you'd want it saved per Project. Because some global entry would probably not be the best choice (current filtering is global).
I think I like this idea. I can imagine having a per project dialog that lets me enter in package paths to ignore with regards to unresolved classes. ex.
com.bea.*
com.jrockit.*
etc.
Let me know if this is what you are thinking.
I'll explore this one, I might try to push out 1.1 then continue this on the beta branch. Since the 1.1 beta is so much better than the 1.0 I kind of would like to get the laggards onto the newer stuff. But its a good idea.
Bryant
The self reference issue is no big deal.
Yes, the package paths to ignore is what I meant. But I'm not clear on the per-project part. I have a product that is composed dozens of projects. All the jars are contained in a few "thirdparty" projects which are dependended on. For the product I am not using, eg, jrockit. I don't want to have to specify a filter for dozens of projects.
Maybe an extension of a working set -- a classpathhelper filter working set -- similar to the breakpoints working sets. The I could simply select a classpathhelper filter working set to be applied to the workspace.
-barry
Hey Barry,
I added support for being able to specify some packages/classes as not showing up in unresolved lists. I'm still behind on the documentation, but you can access it from the main properties area of ClassPath Helper (same area as the not showing as blocked stuff).
I think I like both of these suggestions, thanks for passing them along.
btw, I sent you a personal email via sourceforge, since I've not gotten too many emails via this channel I wanted to make sure you got it. If not follow up with me at bryant_harris@hotmail.com, let me know how things are working out at the new job.