In Eclipse, how can I quickly access the source of an "android library project" from the source of a project that uses it?
Asked Answered
C

1

6
  • Project A is an android library project in my workspace(via project properties->android->library: is library).
  • Project A declares classA.
  • Project B uses project A (via project properties->android->library: add...).
  • Project B instantiates classA.

When I use F3 ("open declaration") over the classA instance in project B, it leads me to the classA.class in the A.jar that is included in B, built from A.

Is there a way to go directly to the source classA.java in project A rather than looking for it in the package explorer?

I think this is new to ADT14, formerly there were X_src folder for each included library project: e.g. A_src would appear in B as a source folder in the root of the project.

Coremaker answered 25/10, 2011 at 23:0 Comment(3)
Is the source for A.jar defined in eclipse for Project A? If so, I would think B should be able to utilize that as well.Foveola
The best I've been able to do, though it works some what inconsistently, is to get to view the source that is included inside the library jar file, but this is not the same as the original .java source. I've tried messing with the settings to get that to work but I haven't found a way, and more often that no even break the lookup of source in the library jar which makes debugging impossible. It would probably work better all around if Android tried to do less 'magic' in eclipse and just forced more steps on library creation.Deposition
After further thought this may be an issue with how ADT builds and includes the Library. It appears to build the the library as a jar with src included. On top of that, in the project using the library ADT uses internal mechanisms to include the jar which prevent override of the src location (attempts to change this will just reset). If one is building a library with no resources it may be possible to just include the jar like a normal library, but that somewhat defeats the purpose. It may take a bug against ADT to get this fixed but I hope not.Deposition
P
7

Right click on the non-library project (Project B) and select Build Path:

  • In the Projects tab, add the library project Project A as a dependency.
  • In the Order and Exports tab, be sure Project A is given higher precedence than the placeholder/bundle Library Projects.

I had to do both of these steps in order to fix this issue, with ADT15, Eclipse 3.7 and new projects.

Plumley answered 28/10, 2011 at 22:22 Comment(5)
I'm afraid I had the exact configuration you show, and already did the steps shown in the reference. But the behavior is what I explained. Even with the new ADT15. What ADT are you using? Can you navigate to the sources directly?Coremaker
That worked, both those steps in the Build Path are required to resolved the issue with Open Declaration. I didn't have a chance to do debugging but I assume it will cause .java files to open consistently on breakpoints as well. It does mean that it is effectively building against both the jar and the library source. I haven't been able to verify if it has impacts on any resources in the library project (the main point of complexity in the android build process), but I assume not.Deposition
Checked that and... it works! I cannot understand why ADT does not does this automatically... If anyone knows a way to suggest this to Google for the next ADT upgrade that has some effectiveness, please tell us and we could try to pressure them to include this! BTW I am setting this as the right answer!Coremaker
When I do this then my Call Hierarchy contains all calling methods in duplicate. Is there any way around this?Dobla
@MarkCarter In the call hierarchy view, click on the downward right triangle, select "Search In", and deselect "Application libraries".Plumley

© 2022 - 2024 — McMap. All rights reserved.