Community
Participate
Working Groups
3.3 RC3 If you create a .target file, and specify a list of plugins that comprise that target, it would be nice to be able to export that target as a directory of plugins, pulled from the environment you are running in. This could be done either in the target editor (Overview or Content pages), or in the Export menu with the target file selected, or both. A more comprehensive wizard would set the runtime for execution to be that exported target directory.
An obvious use of this is for packaging up of a target for others to consume.
I recently opened a feature request (Bug 209207) with the DSDP project to allow users to export plugins/features directly to their target system. How cool would it be if you could add this target platform import/export feature in such a way that you could export the target plugins/features directly to any filesystem (local or remote)!? That way I could have a .target file for each of my embedded platforms (as I do now), load one up, develop/test, and deploy to the target system. Please let me know if there is already something like this that I am missing.
(In reply to comment #2) Right now, you can simply use the Deployable Plug-ins and Fragments wizard to achieve something similar to what you want. However, with this deployable target functionality, do you want to include your workspace and target platform plug-ins, ie., everything you specify in your .target file? This shouldn't be that hard to do, however, this makes me thing that we really need one way to define a "list of plug-ins" ... right now... they are scattered amongst feature.xml's, .product files, .target files etc...
I'll see what I can cook up in the PDE kitchen for 3.4M5.
(In reply to comment #3) Yes. My idea was to allow users to specify the entire set of plug-ins (target platform and workspace) for a particular target and then deploy directly to that target. Would be nice to align the concept of target device or filesystem with that of the .target file. Thanks!
We should include Andrew to make sure he is aware of any changes that are suggested since he is the one to actually do the work behind the scenes :)
I don't see any work here for build unless you expect to run a headless build based on the .target file. (Then we are in an analagous situation to the .product file, where both ui and build have handling for a file, and we should maybe consider sharing). I would expect that the .target file is just another way of listing what should be included in the auto-generated feature that is used by export. With the addition of specifying the target config os/ws/arch.
Kevin, could you create a feature that contains all the plug-ins you want to "list"? You could then include the one feature in the .target file so you get the same functionality. You could also export the feature through existing PDE menus. One last bonus is that since it is a feature you could even install your "list" of bundles into your environment through Update Manager so all your developers could quickly and easily load the list.
This sounds a lot like "provisioning/building" a target - something that p2 should be leveraged for. It's analagous to the p2 admin UI being used to install an SDK - except in this case you want to use a target file to drive what gets installed.
Created attachment 143232 [details] PSF for Target Bundle Ian and I have tossed some code in the PDE incubator recently that handles this. There's an export wizard that takes the currently set target and exports it to a directory. This wizard is quite useful if you want to quickly setup a headless build based on your current target definition. Essentially, you just have to set your baseLocation to this directory and you're golden. It needs some more polish still before we can consider it to be moved outside of the incubator.
In addition to what Chris said, the tool also exports (mirrors) any metadata your target definition knows about. This way you can set p2.context.repo in your build.properties file, and PDE Build will reuse the metadata.
I am waiting for your patch Ian <3 :)
Created attachment 164160 [details] Target export wizard Here is a patch against PDE/UI (head) from the incubator where we did this work. For some reason, build.properties is marked as binary, so this patch does not include the addition of the component.xml to the binary build. So, if you apply this patch, please add OSGI-INF/component.xml to the binary build :-).
Created attachment 164371 [details] org.eclipse.pde.ui.patch An updated patch.
Created attachment 164373 [details] org.eclipse.pde.ui.patch An updated patch.
done. Thanks for pushing me on this Ian. > 20100409 There's still a couple polish items left (need to improve the icon in the wizard) but we can push that out a bit. Please test this in your scenarios for the next build.
Thanks Chris, you rock!
Sounds cool to be able to export a target definition... when I tried the feature I was surprised by a couple of things: * Why can't I type a directory name in the wizard for the export directory? * Why can't I choose any existing target definition, rather than just export the active target?
(In reply to comment #18) > Sounds cool to be able to export a target definition... when I tried the > feature I was surprised by a couple of things: > > * Why can't I type a directory name in the wizard for the export directory? Fixing this in HEAD now :) > * Why can't I choose any existing target definition, rather than just export > the active target? https://bugs.eclipse.org/bugs/show_bug.cgi?id=308655
