Home » Language IDEs » Java Development Tools (JDT) » FINDING ALL PROJECTS AND ALL PACKAGES
| FINDING ALL PROJECTS AND ALL PACKAGES [message #259921] |
Fri, 01 May 2009 10:40  |
Eclipse User |
|
|
|
Hi,
I have the following questions.
1)
I want to have all the java projects in my workspace in an array form so
that i can process them one after the other. The following gives me only a
specific project:
IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
IProject project = root.getProject("talkProject");
but i want to have all the projects in an array and process them.
2)
Like the first question, i would like to have also all the packages in a
specific project in an array form and process them also one after the
other. i tried the following code snippet but didn't give me the array of
all the packages in the project.
IJavaProject javaProject = JavaCore.create(project);
IPackageFragment[] pk = javaProject.getPackageFragments();
Thank you all.
Regards,
Eddy.
|
|
| | | | |
| Re: FINDING ALL PROJECTS AND ALL PACKAGES [message #259959 is a reply to message #259952] |
Sat, 02 May 2009 14:30  |
| Eclipse User |
|
|
|
"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 18:42 |
| Eclipse User |
|
|
|
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: Fri May 02 13:08:05 EDT 2025
Powered by FUDForum. Page generated in 0.05372 seconds |
Home