Home » Language IDEs » Java Development Tools (JDT) » FINDING ALL PROJECTS AND ALL PACKAGES
| | | | |
| Re: FINDING ALL PROJECTS AND ALL PACKAGES [message #259959 is a reply to message #259952] |
Sat, 02 May 2009 18:30   |
 Walter Harley
Messages: 847
Registered: July 2009 |
Senior Member |
|
|
"Eddy Freeman" <win1for@yahoo.com> wrote in message
news:5ebdc79ffc187e4e4d477a794b174f74$1@www.eclipse.org...
> Hello,
>
>
> I did the following:
>
> System.out.println("pacakge: " + pk.length + " name: " +
> pk[0].getElementName());
>
> and get this results:
>
> "pacakge: 678 name: "
>
>
> There is only one package in the project's "src" folder and only four
> classes in that package.
Package fragments include all packages in the classpath. Not just source
files, but everything in every jar on the classpath, including rt.jar (the
Java runtimes). So for instance you will see java.lang,
java.util.collection, etc... That is what I meant when, in an earlier post,
I told you that the Java Model includes all the classes on the classpath,
not just the source files. And that is what I meant when I told you that
not every package contains compilation units.
The default package (that is, the package that contains classes that don't
have a 'package' statement) has an empty name. This is stated in the
javadoc for IPackageFragment.getElementName(), I believe. Sounds like
that's the first one on the list. I imagine that it always shows up on the
list even if there are no classes in it.
The lesson here is that, when your code doesn't work as expected, you might
want to take a look with the debugger (or with System.out.println) and see
what's going on. As a programmer, your tools should be:
1. Carefully read the javadoc for all the classes you are considering
using, and for the other classes in the same packages.
2. Study other code that uses those classes. Google Code is useful here.
You can also import the source code of Eclipse plug-ins into your workspace
(in Plug-in Development perspective, bring up the Plug-ins view and
right-click on a plug-in, then Import As... Source Project, that's one way
to do it), and then just look for usages of the classes.
3. Use the debugger to step through your code to see what data you are
getting. THIS IS CRUCIAL. DEBUG DATA, NOT CODE. If you don't know what
data you are working with (i.e. in this case, what getPackageFragments() is
returning) you cannot possibly write correct code. Guessing does not work.
4. Write test cases and use assertions to validate each of your
assumptions, step by step.
5. When all else fails, search Google and/or post to a newsgroup to try to
get help.
This is pretty broad advice but I think most of the professional developers
on this group would agree that it reflects how they work. In other words,
experience proves that these steps (in this order) are necessary in order to
work efficiently.
> Should i access the "src" folder before i can access the packages inside
> them? Is that why i get this strange results. I read the
> IPackageFramentsRoots but i don't understand it well. Should i use it
> before i use the IPackageFrament?
You might want to, yes. That way you could restrict yourself to only
looking at package fragments that are in source folders.
IPackageFragmentRoot.getKind() will tell you whether the root is a K_SOURCE
or K_BINARY, that is, whether it refers to a source folder or to a binary
container such as a jar file.
If you know the names of the source folders already, then you could use the
IProject.getPackageFragmentRoot(IResource) form of the method, to get the
package fragment root corresponding to each source folder. That might run a
little quicker than getting all the roots and checking each one to see if
it's a source root.
|
|
|
| Re: FINDING ALL PROJECTS AND ALL PACKAGES [message #260111 is a reply to message #259959] |
Mon, 11 May 2009 22:42 |
|
Hi Walter
your explanations in this thread were very interesting, thank you.
I created a little example to demonstrate the usage of JDT for finding
projects, package and source files, perhaps this helps someone:
http://www.vogella.de/articles/EclipseJDT/article.html
Best regards, Lars
Walter Harley wrote:
> "Eddy Freeman" <win1for@yahoo.com> wrote in message
> news:5ebdc79ffc187e4e4d477a794b174f74$1@www.eclipse.org...
>> Hello,
>>
>>
>> I did the following:
>>
>> System.out.println("pacakge: " + pk.length + " name: " +
>> pk[0].getElementName());
>>
>> and get this results:
>>
>> "pacakge: 678 name: "
>>
>>
>> There is only one package in the project's "src" folder and only four
>> classes in that package.
>
>
> Package fragments include all packages in the classpath. Not just source
> files, but everything in every jar on the classpath, including rt.jar (the
> Java runtimes). So for instance you will see java.lang,
> java.util.collection, etc... That is what I meant when, in an earlier post,
> I told you that the Java Model includes all the classes on the classpath,
> not just the source files. And that is what I meant when I told you that
> not every package contains compilation units.
>
> The default package (that is, the package that contains classes that don't
> have a 'package' statement) has an empty name. This is stated in the
> javadoc for IPackageFragment.getElementName(), I believe. Sounds like
> that's the first one on the list. I imagine that it always shows up on the
> list even if there are no classes in it.
>
> The lesson here is that, when your code doesn't work as expected, you might
> want to take a look with the debugger (or with System.out.println) and see
> what's going on. As a programmer, your tools should be:
>
> 1. Carefully read the javadoc for all the classes you are considering
> using, and for the other classes in the same packages.
> 2. Study other code that uses those classes. Google Code is useful here.
> You can also import the source code of Eclipse plug-ins into your workspace
> (in Plug-in Development perspective, bring up the Plug-ins view and
> right-click on a plug-in, then Import As... Source Project, that's one way
> to do it), and then just look for usages of the classes.
> 3. Use the debugger to step through your code to see what data you are
> getting. THIS IS CRUCIAL. DEBUG DATA, NOT CODE. If you don't know what
> data you are working with (i.e. in this case, what getPackageFragments() is
> returning) you cannot possibly write correct code. Guessing does not work.
> 4. Write test cases and use assertions to validate each of your
> assumptions, step by step.
> 5. When all else fails, search Google and/or post to a newsgroup to try to
> get help.
>
> This is pretty broad advice but I think most of the professional developers
> on this group would agree that it reflects how they work. In other words,
> experience proves that these steps (in this order) are necessary in order to
> work efficiently.
>
>
>> Should i access the "src" folder before i can access the packages inside
>> them? Is that why i get this strange results. I read the
>> IPackageFramentsRoots but i don't understand it well. Should i use it
>> before i use the IPackageFrament?
>
> You might want to, yes. That way you could restrict yourself to only
> looking at package fragments that are in source folders.
> IPackageFragmentRoot.getKind() will tell you whether the root is a K_SOURCE
> or K_BINARY, that is, whether it refers to a source folder or to a binary
> container such as a jar file.
>
> If you know the names of the source folders already, then you could use the
> IProject.getPackageFragmentRoot(IResource) form of the method, to get the
> package fragment root corresponding to each source folder. That might run a
> little quicker than getting all the roots and checking each one to see if
> it's a source root.
>
>
>
>
|
|
|
Goto Forum:
Current Time: Sat Oct 19 09:04:45 GMT 2024
Powered by FUDForum. Page generated in 0.05114 seconds |
] 
Search
Help
Register
Login
Home
