I downloaded and installed the 32 bit version of Eclipse Juno. I'm running under Win 7 Ultimate 64 bit with only one minor problem. I've only done minimal testing but I have modified and rebuilt libraries and device executables with no problems and installed the Mercurial Eclipse plug-ins alongside the NNDK plug-ins (placed in the drop in folders). When doing my standard test of importing the factory demo, it worked very well up to creating a new configuration. I could not create a new run configuration. I could copy a compatible existing configuration and modify it to work with the new project.
I'm interested in Juno because rumor has it the Code Analysis (Codan) has been improved and reports far fewer false positives. Also the Extract Function refactoring, which is quite useful, had a bug where it would often create non-member methods when it should have created member methods. In my testing this bug has been fixed in Juno but not Indigo.
Juno and NNDK
Re: Juno and NNDK
I'd love to hear your experiences with codan in juno. Currently, codan is causing a lot of support emails, and I am considering disabling it by default in our release unless there is some big outcry to keep it.
Forrest Stanley
Project Engineer
NetBurner, Inc
NetBurner Learn Articles: http://www.netburner.com/learn
Project Engineer
NetBurner, Inc
NetBurner Learn Articles: http://www.netburner.com/learn
Re: Juno and NNDK
If it's disabled by default will there be any way for the user to enable it from NBEclipse? If so then I say it's a no brainer - disable it by default. If the user can't enable it, then it's a tougher decision, but if I had to manage tech support I would disable it. It's just too confusing for a new user. An experienced user who wants the feature should be willing to install Indigo. If you disable Codan do you lose the refactorings too or are they independent features?
Juno proved to be worse for me than Indigo as far as Codan is concerned. The refactorings are better but not worth the price of increased Codan annoyance. In Indigo I thought the fix for forcing it to index stddef.h (and potentially other missing includes) was sensible and easy enough to do. In Juno, because they claim they fixed the bug that caused the problem they removed the option to explicitly specify additional files to index. Great, in theory, not so much in practice. At first when I tested Juno it appeared to work. Then when I started importing more complex code the old size_t problem came back and now I see no way to fix it. It also falsely reports that it can't resolve any include files that aren't at the root level of an include path. (The code compiles fine you just get code littered with warnings in the editor).
I would caution that I'm only one lonely data point and others may have had a better experience. I went back to Indigo and with the added indexing I find it works pretty well. Maybe the Kepler 2013 release will finally be truly Codan ready with more bullet proof refactorings.
Juno proved to be worse for me than Indigo as far as Codan is concerned. The refactorings are better but not worth the price of increased Codan annoyance. In Indigo I thought the fix for forcing it to index stddef.h (and potentially other missing includes) was sensible and easy enough to do. In Juno, because they claim they fixed the bug that caused the problem they removed the option to explicitly specify additional files to index. Great, in theory, not so much in practice. At first when I tested Juno it appeared to work. Then when I started importing more complex code the old size_t problem came back and now I see no way to fix it. It also falsely reports that it can't resolve any include files that aren't at the root level of an include path. (The code compiles fine you just get code littered with warnings in the editor).
I would caution that I'm only one lonely data point and others may have had a better experience. I went back to Indigo and with the added indexing I find it works pretty well. Maybe the Kepler 2013 release will finally be truly Codan ready with more bullet proof refactorings.
-
Ridgeglider
- Posts: 513
- Joined: Sat Apr 26, 2008 7:14 am
Re: Juno and NNDK
Hi Forrest:
I haven't been adventurous enough to try NB w/Juno, but despite it's frustrations, I'd agree w/ Tod that the best option might be to disable the Rev 2.6 codan option, assuming that the user could fairly easily re-enable it. I have not used this kind of tool before, and despite it's learning curve, I've found that it gives users very useful insight into their code. If the default is to disable the feature, one idea might be to have add a CODAN_PROPERTIES file in the platform directories that configures the correct build paths. Also there might be a set of properties that codan users might import to properly configure other features of eclipse like the indexer that seem to require changes. Bottom line, I've found codan is more useful than not, even though it produces lots of errors and warnings, even with successful builds.
I haven't been adventurous enough to try NB w/Juno, but despite it's frustrations, I'd agree w/ Tod that the best option might be to disable the Rev 2.6 codan option, assuming that the user could fairly easily re-enable it. I have not used this kind of tool before, and despite it's learning curve, I've found that it gives users very useful insight into their code. If the default is to disable the feature, one idea might be to have add a CODAN_PROPERTIES file in the platform directories that configures the correct build paths. Also there might be a set of properties that codan users might import to properly configure other features of eclipse like the indexer that seem to require changes. Bottom line, I've found codan is more useful than not, even though it produces lots of errors and warnings, even with successful builds.