Community
Participate
Working Groups
I20100323-0800, needs to be fixed for 3.6 With the advent of p2, it has become more complicated to test a fix in a user's install. The old way was: - use the Plug-in Export wizard with an increased qualifier - drop the exported plug-ins into the user's plugins/ directory - start with -clean The Eclipse doc needs to be updated with a list of steps required to achieve the same with p2. Something like /org.eclipse.pde.doc.user/tasks/ui_export_install_into_host.htm , but not installing into my own host but into a different install. The scenario should work with multiple plug-ins that have different qualifiers in their versions, and that are contained in different features in the user's install (e.g. org.eclipse.jface and org.eclipse.jdt.junit).
What is the suggested way to do this in 3.6? Is is to create a "New > PDE > Feature Patch"? If you export the feature patch with metadata, the user can install using the "Install New Software" dialog, but you have to patch each feature individually.
Several possibilities to address this: 1) create a feature patch for the feature that contains the plugins for which a change is needed. This necessitates to know which version of the feature the user has. 2) Modify (reusing the code that export in self) PDE to generate a patch that can be applied on more than one version of a plug-in. This will require to know some upper range to let the patch get disabled automatically
This is on http://wiki.eclipse.org/Polish3.6
(In reply to comment #2) > 1) create a feature patch for the feature that contains the plugins for which a > change is needed. The hard part is that the plug-ins can come from multiple features, so you may need to describe how to create a feature patch for multiple features, see comment 0: "The scenario should work with multiple plug-ins that have different qualifiers in their versions, and that are contained in different features in the user's install (e.g. org.eclipse.jface and org.eclipse.jdt.junit)." > This necessitates to know which version of the feature the user has. We can assume that that's known.
Any chance to add this important documentation for 3.6?
I'll add it to the list of doc bugs for 3.6
This didn't make it for 3.6. Its sounds like we don't even have consensus on what approach to recommend. Personally I do roughly the same as the old steps: - use the Plug-in Export wizard with the same version and qualifier - drop the exported plug-ins into the user's plugins/ directory - restart
(In reply to comment #7) > - use the Plug-in Export wizard with the same version and qualifier Yeah, that works for a single plug-in, but it requires too many click/wait cycles if I want to do this for multiple plug-ins with different qualifiers. In the olden days, Eclipse SDK developers used to selfhost on daily plug-in exports that could be generated with simple Ant scripts. Nowadays, this is really complicated, and we're losing quality in the I-builds because nobody selfhosts any more.
Ping. Please work on this. It's really a sore point that selfhosting is so complicated that nobody does it any more (or maybe we just don't know how it works).
(In reply to comment #7) > This didn't make it for 3.6. Its sounds like we don't even have consensus on > what approach to recommend. Personally I do roughly the same as the old steps: > > - use the Plug-in Export wizard with the same version and qualifier > - drop the exported plug-ins into the user's plugins/ directory > - restart I export into running instance. Is that not the recommended way?
(In reply to comment #10) > (In reply to comment #7) > > This didn't make it for 3.6. Its sounds like we don't even have consensus on > > what approach to recommend. Personally I do roughly the same as the old steps: > > > > - use the Plug-in Export wizard with the same version and qualifier > > - drop the exported plug-ins into the user's plugins/ directory > > - restart > > I export into running instance. Is that not the recommended way? We have many plug-ins which we want to export from our build machine and make them available to all team members (see also comment 0).
> > I export into running instance. Is that not the recommended way? > We have many plug-ins which we want to export from our build machine and make > them available to all team members (see also comment 0). In this case, I suggest for your build to produce a feature patch (a feature that patches the content of the existing one) and make it available as a p2 repository. This way, the patch can be installed and you can easily revert back in case there is a problem with it.
(In reply to comment #12) > > > I export into running instance. Is that not the recommended way? > > We have many plug-ins which we want to export from our build machine and make > > them available to all team members (see also comment 0). > In this case, I suggest for your build to produce a feature patch (a feature > that patches the content of the existing one) and make it available as a p2 > repository. > This way, the patch can be installed and you can easily revert back in case > there is a problem with it. Yes, but the problems are: - our code covers more than one feature - there are several projects in some of the features that we don't want to export - we don't want/need to have the features in our workspace Maybe this is easy doable (see comment 0 how easy it was) but not documented. Therefore this bug asks to document the best and fasted way to export a set of projects that can come from anywhere (might not even be in a feature) and then make this export available so that all team members can easily install them into their workspace.
This has been identified as polish item for 3.7, see http://wiki.eclipse.org/Polish3.7. Can someone please take care of this? Thanks.
(In reply to comment #13) > Therefore this bug asks to document the best and fasted way to export a set of > projects that can come from anywhere (might not even be in a feature) and then > make this export available so that all team members can easily install them > into their workspace. There are only two ways to replace the contents of a plugin in your install: 1) Use the same bundle id and version, replacing the file with identical name in your install 2) Use a feature patch There is also "Exporting into Running Host", but that just creates a feature patch for you, so it is essentially 2). So as far as documentation I don't see anything to do here. Feature patches are documented here: http://help.eclipse.org/helios/topic/org.eclipse.pde.doc.user/guide/tools/project_wizards/new_feature_patch.htm Exporting into running host is documented here: http://help.eclipse.org/helios/topic/org.eclipse.pde.doc.user/tasks/ui_export_install_into_host.htm This idea of being able to create a feature patch without having any feature is not something that can be done with p2 today.
> This idea of being able to create a feature patch without having any feature is > not something that can be done with p2 today. Which means self-hosting on a set of n bundles coming from different features is no longer easily and quickly doable.
no work planned there.
