0

I have two Eclipse projects: one that depends upon a certain library (android.jar) and one that is more abstract and doesn't contain that dependency.

I am in the process of migrating all classes that have no dependencies on the package, in my case android.*, to the more abstract project. Is there a Eclipse feature that can help automate the move?

Ideally, there would be feature that directly lets you automatically search for and move files that can be relocated to a new project. It would find files that that are:

  • independent of a specified package (with wildcards)
  • independent of other files within the same project that are dependent on the same package (in other words, no indirect dependencies on the package)
Jeff Axelrod
  • 27,676
  • 31
  • 147
  • 246
  • Is it a viable way of doing it? What if A doesn't depend on android, but depends on B which depends on android? – JB Nizet Mar 10 '12 at 14:00
  • Your edit indeed expresses the same concern as my comment. I don't think this is a task that can (or should) be automated. You should refactor based on the functionality that each class, set of classes, or package offers, and you might have to re-design the code to make android-dependent classes not dependent, but still usable in an android context (using interfaces, abstractions, strategies and other OO patterns). – JB Nizet Mar 10 '12 at 14:08
  • @JBNizet I'm confused why you wouldn't want to automate the task? Keeping these independent files in a separate project that is independent of `android.jar` would help provide a clear break from dependencies on Android. It would also ensure that dependencies don't accidentally leak back into the classes. Your ideas about creating new independent classes are perfectly valid and good, but I don't see how they relate to--or discourage the automated refactoring. This refactoring would help to automatically relocate files where the redesigns you suggested have already been performed. – Jeff Axelrod Mar 10 '12 at 14:15
  • I'm not saying the refactoring shouldn't be done. What I'm saying is that it should probably be done manually, and think about the design while doing so. Suppose 100 classes all depend on class A, which has a tiny dependency on android. That makes these 100 classes ineligible for being moved. Maybe this class A should be manually refectored to eliminate the direct dependency to android (using a dependency to an android-independent interface rather than a concrete android implementation, for example). All those 100 classes would then be eligible for being moved. Doing so requires manual design. – JB Nizet Mar 10 '12 at 14:23
  • Still, I completely agree with your claims, however I don't understand how it makes the refactoring any less useful. If the goal is to eliminate as many dependencies as possible, once the already-independent classes have been identified and relocated, the developer can more clearly see the ones that require manual work to decouple the classes as you describe. Then, once that work has been done, the move can be automated again, and so on. – Jeff Axelrod Mar 10 '12 at 14:36

1 Answers1

0

I submitted an Eclipse enhancement request to support such a refactoring. In the meantime, I found some promising tools to help with the decoupling and dependency analysis.

  • eDepend is a dependency viewer plugin that includes a Class/Package dependency diagram that displays elements dependencies, relationships with libraries/other projects and dependency cycles. It can also list find classes that caused the dependencies.
  • STAN structure analysis for Java
  • nWire
  • Class Dependency Analyzer
  • Dependency Finder

Related questions: 1

Community
  • 1
  • 1
Jeff Axelrod
  • 27,676
  • 31
  • 147
  • 246