This is a Android project that includes both JDT and CDT natures to build an Android app with a native library using the upcoming Android Native Development Kit. As you can see both JDT and CDT contribute to the list of things in the project. The Resource system would put it's own twist on the project if I hadn't turned it off.
The Common Navigator was a great idea when it was proposed. Have a single navigator framework that projects could contribute to. I have the sense it wasn't meant to handle the use case where you'd want to see a project that that has multiple natures leading to multiple contributors. The result is confusing at best, and embarrassing at the least.
But it's a good example of where the Eclipse dream of interoperability is a bit of a failure. Yes, there is a bug on this (didn't have time to look up the number but one of the CDT committers warned that this was going to happen). And my understanding is that it won't make the cut for 3.5 meaning this behaviour will be seen in commercial products as well, unless the vendors fork and fix it locally. And it's just not the JDT's fault, CDT is helping here too, and not knowing, I wonder if it's something missing from the framework to help co-ordinate this.
It's pretty disappointing and, yes, embarrassing, as I try to get the Android community to use the CDT for this style of application. There's no reason to create separate projects for Java and C++. Everything else is working fine in the one project. They'll just have to make sure the expand the right version of the src folder to find their Java source, at least there's icons that differentiate it, unlike the assets and res folders.
In our application, we added several filters to remove unwanted entries. Filters are run only when a user uses our perspective. I think that this is the simplest solution and it works quite well.
ReplyDeleteWell, I want to see the JDT items and the CDT items. But each of them is trying to interpret items created by the other. But how is it supposed to know? You wouldn't want to write code for the CDT that looks out for JDT. What if someone else comes along and adds things.
ReplyDeleteIt's a hard problem and unfortunately it looks like we have half a solution.
I feel the existing project concept and the way you can structure projects in Eclipse is strongly component-oriented. The granularity of your example would suggest that two projects are needed, with the native artefact of the C/C++ project a dependeny of the Java project. Your remark is reminiscent of the old 'nested projects' discussion. Perhaps you'd like to put everything into a single 'logical' project, to simplify distribution? How do you feel two separate projects would affect the experience you're trying to convey?
ReplyDeleteI totally disagree, especially in this case. The project is implementing one application. There are two programming languages involved but they work together to solve a single problem. And this is true with all JNI Java/C++ projects. Why artificially separate them into separate projects?
ReplyDeleteIn fact everything else is working. There are 7 builders working in order to create the Android APK file. The CDT indexer is working, the Java indexer is working. The only thing that isn't working is the Navigator and that should be a solvable problem.
I am a bit surprised you would insist on the one-to-one relationship between an application and a project. Eclipse itself is an example to refute that. Again it demonstrates the extreme views on how to interpret the granularity an Eclipse 'project' offers. I admit, you might consider a JNI example, with a strongly coupled Java part and a native part, a good example of a case where they would belong together in the same project. But OSGi shows you, with its platform-specific fragments, that the actual granularity is determined by the platform-independent Java component, and all the different native platforms supported. That's 1+N components, or projects in this case. That partitioning is driven by the advantages of modularity (and re-use). But you haven't explained yet why you appreciate the single-project approach. Is it ease of distribution? Have you considered using Buckminster to help people populate their workspace for your example project?
ReplyDeleteMy point is: let me decide. I don't want Eclipse to decide for me. That's what kills Eclipse with embedded developers.
ReplyDeleteIn my case, I have a Makefile that updates the APK file that the Android build creates from the JDT built class files. It's easier to manage if it's all under one root directory, i.e. a project.
"Doug misses the mark"
ReplyDeleteJDT and CDT should work well together, as should other obvious pairings. Who wouldn't want to put the natives for some small application in the same project as the Java code?
The thing is though, the particular problem that you seem to be seeing is a *bug*. Unfortunately, one which, given the level of investment in CN and the Eclipse Project's rules of engagement for fixing bugs late in the cycle, _can_not_be_fixed_ for R3.5. I'm sorry, but the rules are there because that's what it takes to get the quality we deliver every year.
I don't, however, believe a bug is a reason to throw out the whole framework.
If you find something embarrassing about the platform, feel free to contribute to fixing it. That's going to get you more value in the long run.
Thanks, McQ. It's a bit of a paradox. We are locked down to improve quality, yet there is a pretty serious bug in the common navigator (and the bigger issue is Resources versus CDT). And I would help but we're in lock down.
ReplyDeleteI just listened to your EclipseCon talk (http://live.eclipse.org/node/739) from which I'd like to quote this: "What's the incentive for people to come and help you? You have to create the need. There has to be a need for people to come and contribute. If you are a vendor and you're depending on Eclipse technologies, and you need changes in there to satisfy your customers, don't expect the open source community to do it for you. You need to get in there and fix it. And that's the need, that creates the need."
ReplyDeleteVery well put! It looks like we've learned from you and created a need here. :-)
The Common Navigator framework works pretty well for a good number of use cases, and thanks to Francis Upton got a *lot* better in 3.5. If your use case does not work well, we'd love to have you contribute. See http://wiki.eclipse.org/Platform_UI/How_to_Contribute
Thanks, Boris. I can't argue with that now can I :)
ReplyDeleteI guess no one else had this need.
I have to say that CDT, in the form of Anton Leherbauer, has been pretty much the largest contributor of fixes to the CNF, and they have been of very high quality. Much of *my* work would not have been done without the work of Tony. And not only has he contributed fixes, he has actively commented on the Wiki and worked with my in resolving problems.
ReplyDeleteI'm sorry this one came so late in the cycle and we were not able to address it.
I tried Ganymede and the problem was there too. I guess no one has tried a project with both CDT and JDT natures on it. We'll try and clean this up for 3.6.
ReplyDelete