I have Workspace_A and Workspace_B.
I have a projects X, Y, and Z in Workspace_A
Each project has a particular run configuration (NB options and Run/Debug Settings) specifying the appropriate project, target platform and target IP.
I switch to Workspace_B and import "Existing Projects into Workspace", browse to the Workspace_A directory and select projects X, Y, and Z, and then COPY them into Workspace_B.
When I do this, I need to configure Properties-->NetBurner Options and select a target platform and IP, and then go to Properties-->Run/Debug Settings to configure a new run configuration for each project.
Is there a way to get this info to import? I seem to remember that this info did import in previous NNDK versions?? I am using the 2.6.3 Beta for the Nano for these projects.
Thanks
Including Run Configuration when importing a project?
-
Ridgeglider
- Posts: 513
- Joined: Sat Apr 26, 2008 7:14 am
Re: Including Run Configuration when importing a project?
Funny you should ask. I just recorded a demo on how to do this for my upcoming Pluralsight course Eclipse Guided Tour - Part 2 . You'll have to wait until December to find out how. OK as long as you promise not to tell anyone...
It's not really an import process, you just have to drag some files in the OS. Launch configurations are stored in your workspace under the .metadata folder. (If you're on the Mac you have to unhide this folder first). The full path is <workspace_folder>/.metadata/.plugins/org.eclipse.debug.core/.launches
You can either drag over the entire folder to your new workspace or pick and choose launch files. Any external tools you created are here as well, so you can get those over to your new workspace.
I've used this technique in Indigo, Juno and Kepler. I don't use NBEclipse but I suspect it will work there also.
----------------------------- more shameless self-promotion ---------------------------
Lots of other valuable tips are available now in my 4 hour course on the Eclipse Guided Tour - Part 1.
It's not really an import process, you just have to drag some files in the OS. Launch configurations are stored in your workspace under the .metadata folder. (If you're on the Mac you have to unhide this folder first). The full path is <workspace_folder>/.metadata/.plugins/org.eclipse.debug.core/.launches
You can either drag over the entire folder to your new workspace or pick and choose launch files. Any external tools you created are here as well, so you can get those over to your new workspace.
I've used this technique in Indigo, Juno and Kepler. I don't use NBEclipse but I suspect it will work there also.
----------------------------- more shameless self-promotion ---------------------------
Lots of other valuable tips are available now in my 4 hour course on the Eclipse Guided Tour - Part 1.
-
Ridgeglider
- Posts: 513
- Joined: Sat Apr 26, 2008 7:14 am
Re: Including Run Configuration when importing a project?
Tod: Just wanted to say overdue thanks for your tip on moving around and re-using launch configurations. I got sidetracked by your VERY comprehensive Pluralsight tour of Eclipse. Wow! I know all of us have benefited by your posts to this forum for years, but (and this is a plug...stomp, stomp, stomp) despite using Eclipse daily for years, I learned a lot from your tutorial. Pluralsight is very cool. I'll certainly make use of the many other training opportunities it offers. Thanks again!
Re: Including Run Configuration when importing a project?
Thanks for the kind words. It's really nice to get some positive feedback. Motivates me to kick into high gear on part 2.
-
Ridgeglider
- Posts: 513
- Joined: Sat Apr 26, 2008 7:14 am
Re: Including Run Configuration when importing a project?
Tod: here are some topics you might consider for Part 2:
>> Ways to organize all the various settings and preferences once you get things set up the way you want. For me, this came down to 4 areas:
Settings related to a modified Coding Style profile, typically one based on K&R, BSD, GNU, etc
Settings related to the contents placed in new C or C++ source or header files
Settings related to Editor Templates that effect appearance, behavior, or open View (tools).
Settings related to mods or additions to code completion/Code Assist.
It was particularly instructive to look at the contents of the .epf and XML files resulting from saving these four types of preferences and "templates" (confusing usage).
>>I think the other area that I've found useful is your insight into the modifications to the C++ build paths and includes needed to routinely make use of the standard (or custom) C++ libs and how they can be saved as defaults in the NB PLATFORM files. Of course this is more NB related than generic Eclipse, but still obscure to learn about still...
>>Finally, it seems to me that insight into how to keep Eclipse updated with a current ecology of plugins would be useful to a general Eclipse audience. Coming from NBEclipse, these options are obviously (in my opinion, unfortunately) disabled. It would be great if the NB tools ran a bit more like regular plugins than as a closed system. I do understand that design choice, as well as ways to work around it, nevertheless...
>> Ways to organize all the various settings and preferences once you get things set up the way you want. For me, this came down to 4 areas:
Settings related to a modified Coding Style profile, typically one based on K&R, BSD, GNU, etc
Settings related to the contents placed in new C or C++ source or header files
Settings related to Editor Templates that effect appearance, behavior, or open View (tools).
Settings related to mods or additions to code completion/Code Assist.
It was particularly instructive to look at the contents of the .epf and XML files resulting from saving these four types of preferences and "templates" (confusing usage).
>>I think the other area that I've found useful is your insight into the modifications to the C++ build paths and includes needed to routinely make use of the standard (or custom) C++ libs and how they can be saved as defaults in the NB PLATFORM files. Of course this is more NB related than generic Eclipse, but still obscure to learn about still...
>>Finally, it seems to me that insight into how to keep Eclipse updated with a current ecology of plugins would be useful to a general Eclipse audience. Coming from NBEclipse, these options are obviously (in my opinion, unfortunately) disabled. It would be great if the NB tools ran a bit more like regular plugins than as a closed system. I do understand that design choice, as well as ways to work around it, nevertheless...
Re: Including Run Configuration when importing a project?
Thanks for the ideas. Keep them coming if you have others. I already have an approved outline but I can find ways to squeeze things in.
In part 2 I do talk about my preferred way for getting all the settings for a new workspace. I find the import/export process too cumbersome. I suggest just starting a new workspace. Then exit Eclipse go to your old workspace and copy over the .settings folder from .metadata\.plugins\org.eclipse.core.runtime the old workspace to the new workspace. If you've changed versions of Eclipse this "might" not work but so far I haven't had any problems.
Also on staying up to date, I didn't cover it explicitly in part 1 (but thanks to you I'll get it in part 2 somewhere) there is a auto update setting. (I'm not sure which release of Eclipse this started in). Unfortunately this won't work with the NB plugins because they don't behave as normal plug-ins. I do understand why NBEclipse is a closed system. I'm not sure why the plugins themselves can't act like other plugins.
See the attached image.
In part 2 I do talk about my preferred way for getting all the settings for a new workspace. I find the import/export process too cumbersome. I suggest just starting a new workspace. Then exit Eclipse go to your old workspace and copy over the .settings folder from .metadata\.plugins\org.eclipse.core.runtime the old workspace to the new workspace. If you've changed versions of Eclipse this "might" not work but so far I haven't had any problems.
Also on staying up to date, I didn't cover it explicitly in part 1 (but thanks to you I'll get it in part 2 somewhere) there is a auto update setting. (I'm not sure which release of Eclipse this started in). Unfortunately this won't work with the NB plugins because they don't behave as normal plug-ins. I do understand why NBEclipse is a closed system. I'm not sure why the plugins themselves can't act like other plugins.
See the attached image.
- Eclipse preference setting for auto updating
- AutoUpdate.png (47.84 KiB) Viewed 5711 times