I have to apologize to the Platform team and Francis in particular for my earlier complaint about duplicate entries showing up in the Project Navigator. It turns out that the problem was actually all CDT, or more specifically, how I set up the CDT part of my combo JDT/CDT/Android project.
By putting my source and build output into their own subfolders in the the project and setting the C/C++ Paths settings to point to them and not the root Project folder, the CDT stopped trying to display the other folders in the project in the navigator, the JDT folders in particular. No more duplication!
My disappointment has turned into happiness. I can now work on my Java and C++ files using the same perspective. The only thing that still doesn't make sense is the tool bar where the new Class button still depends on the perspective, but that's minor.
I'll have to come up with some way to automate the creation of what I call JNI projects that have the mix of Java and C/C++ so others don't run into the same thing I did. Maybe an improved Convert wizard.
At any rate apologies all around and thanks!
How about a JNI perspective that explicitly includes all the relevent tooling/views/toolbars/menus etc.
ReplyDeleteHi Doug,
ReplyDeleteYou should consider faceted project framework as a way to enable the JNI project usecase that you've described. Convert wizards are so last year. :)
If you are curious about how this scenario could look to the user get any Galileo package that has WTP in it (such as the Java EE one). Then go to create a new project and select "Faceted Project" under "General". Fill in the name and hit finish. Now you have a blank project. Go to project properties and select "Project Facets". You should see Java listed there. Check it. You should now see an optional configuration link. You can explore that or take the defaults and hit finish. Now you have a fully-configured java project.
Now imagine if we had a C/C++ facet. You could easily create JNI projects by adding Java to C/C++ or C/C++ to Java or you could select both technologies from the start. If you change your mind about JNI, you could just as easily remove the technologies that are no longer relevant.
If you are curious, here is some background reading:
http://www.eclipse.org/newsportal/article.php?id=4&group=eclipse.fproj#4
http://www.eclipse.org/articles/Article-BuildingProjectFacets/tutorial.html
The framework is part of WTP for Galileo (it doesn't actually have any dependencies on WTP) and the goal is to graduate it as an independent project for Helios.
The framework includes the Java facet as part of a Java Enablement component. It would be great if there was interest in the CDT team to take advantage of this technology either directly (by taking a dependency) or indirectly (by contributing a CDT Enablement component to fproj project).
Let me know if I can answer any questions.
- Konstantin
Sounds interesting. But I can already do what I want with what I have. Adding the CDT nature and builders are pretty easy to do. I also want to generate some files at the same time. A wizard can take care of that easily.
ReplyDeleteOne of the main issues that facets address is proliferation of project wizards and convert actions. At some point, you are just fighting the cross-product effect. It is just not feasible to create a project wizard for all combinations of technologies that we might want to use in a single project. You could build the JNI project wizard, but if tomorrow you needed to add JPA to the mix. You would need to either create a JNI + JPA wizard or create a convert action. Neither one of these approaches is particularly elegant. On the other hand, if the CDT projects were faceted, then user can just add Java and JPA technologies as necessary either during project creation or later in project properties. There is no wizards cross-product effect or ton of convert actions littering the menu system.
ReplyDeleteA facet can do pretty much anything when configuring a technology. It can generate files just as easily as a wizard could. If gathering information from the user is necessary, wizard pages can be associated with a facet action.
Finally, creating a facet for core technology such as CDT, enables the downstream community to more easily extend the capabilities of CDT projects by writing their own facets. In WTP we only have a handful of facets that we maintain. That number is dwarfed by facets exposed by adopters. Facets have proven to be a very effective extensibility point for WTP.
Think about it.
- Konstantin
I here you. But I don't seem to "need" facets, which means I don't have the need to implement them. If someone else has the need, we'd accept the contribution.
ReplyDeleteHi, Doug
ReplyDeleteDo you have any plans on publishing little tutorial on JDT/CDT/Android NDK setup?
Yes I do. I got sidetracked by something else, but I'll be back to it in a few days. I'll post another blog entry when it's ready.
ReplyDeleteThis comment has been removed by the author.
ReplyDeletelook forward to your tutorial, whenever you get the chance.
ReplyDeleteUsing Eclipse for Android, recently started using the NDK, found this page on Google. So far I've spent >3hrs in vain trying to figure out how to add the CDT nature to an existing Android project (maybe it's dead-obvious as is often the case, but I'm a relative newbie :).