Community
Participate
Working Groups
the launch dialog adds fragments by default when u hit "add required bundles". now i understand that this is usually wanted but somewhat problematic when these are test fragments as these need usually additional dependencies, than i have for the product, such as junit for instance. as a consequence the added test fragments make the config invalid due to these then missing dependencies. for now i have to deactivate the test fragments on my own, which is cumbersome. now i understand that it might be difficult/impossible to determine test fragments w/o a convention but since the widely adopted convention is to use append ".test" to test bundles/fragments we can safely go with this hard wired or even provide the possibility to provide a pattern that would select them. IMO it would be good to have in general a little more control over what bundles/fragments are added/deemed as required, e.g.: - optional dependencies - fragments (any) - test fragments - source bundles, see bug 305888 for this one for 1st one there exist already a checkbox to control the behavior and i suggest to add some for the others.
The difficulty I see here is presenting the user with the options. It isn't realistic to put that many options on to the launch config tabs. A preference page would be more appropriate, but if a user wants to regularly change the behaviour that workflow will be problematic.
Adding fragments that only contain tests for classes of the host-bundle, often called 'test'-fragments, is not only problematic because of additional dependencies, it is also very problematic because those test-fragments often contain test-resources that are then contributed to the launched Eclipse- or Equnix/OSGi-Application. Those additional resources can alter the behaviour of the launched application without intention or even damage it. One example is additional extensions of Extension-Points, but it could be any other kind of resource. Because I see no reason why one could want to add test-fragments when adding missing requirements to an application, I suggest to not add test-fragments at all when adding missing required plug-ins. If one wants a test-fragment to be launched, for example for JUnit Plug-in test, the desired test-fragment is already selected for the launch and has not to be added. To detect if a fragment is a 'test-fragment' it should be checked if all src-entries of the fragment's classpath have the 'test' attribute set to true. This is a more robust criteria than just checking the name of the fragment, so waiting for 10years had some benefits. @Christoph FYI.
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/189927
Gerrit change https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/189927 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=328d0d89f9993bd30476cae8efea02fae0974c74
Mickael, you raised concerns about making assumptions based on the 'test' classpath-attribute on the pde-dev mailing list last week (sorry for coming back to this so late). I choose the implemented approach based on that attribute because it seemed to most defensive and therefore most reliable one. I also implemented it as defensive as possible and require all src-entries in the classpath to have the test-attribute set to to true in order to be considered as test. However I'm would like to have a robust and suitable solution for the described problem and are therefore honestly interested in your advice how this could be done better? At the moment I see only three alternatives: 1. Not add fragments (automatically) at all for all kind of Eclipse/Equinox/Plug-in Test launches when requirements are added, as suggested in Bug 578644 for only feature-based launches 2. Relay on a test-Bundle attribute as suggested by Christoph in Bug 573534 3. Just include all fragments again as it was before Option 3 would be in my opinion be really unreasonable because it can cause real trouble as described in previous comments. If it should not stay as it is now, I would tend to option 2, because for plug-in based launches I see at least a small benefit in adding fragments when adding requirements in contrast to feature-based launches. Thank you.
> 2. Relay on a test-Bundle attribute as suggested by Christoph in Bug 573534 Rather than an attribute there is often a convention that a test-fragment ends with .tests in its name. This can be good enough to rely on by default to decide whether to auto-include it or not, and usually more correct than relying on the "test" flag on classpath entry. I personally never use Feature-based launches for this family of trouble they induce, so don't really mind in practice which fragments get added, as long as it's easy to remove them from a plug-in based launch if I have any doubt.
(In reply to Mickael Istria from comment #6) > > 2. Relay on a test-Bundle attribute as suggested by Christoph in Bug 573534 > > Rather than an attribute there is often a convention that a test-fragment > ends with .tests in its name. This can be good enough to rely on by default > to decide whether to auto-include it or not, and usually more correct than > relying on the "test" flag on class-path entry. That's right. But I intentionally not relaid on the name convention, because as you said it is only usually correct but not always. And since this change adds less fragments to a launch then before I wanted to avoid false positive checks for being a 'test'-fragment. It is right that there will be test-fragments that don't have the test-attribute set in their class-path, but I assume that there never will be fragments in the workspace that have the test-attribute set but are not test-fragments? The more I think about it the more Christoph's suggestion from Bug 573534 for a dedicated test attribute respectively a consistent criteria for test fragments/plug-ins could help here. Maybe not for arbitrary bundles (also in the TP), but at least for workspace fragments. The IDE could also mark them visually as test-fragments if it detects them as such (similar to test-source folders). Test plug-ins (that are not fragments) are usually not a concern in this regard because they are only added to a launch if explicitly referenced. If the only reason to not relay on the test-attribute is that is it might not be always used, I could add a check if a fragment that matches the usual test-fragment name convention also has it's src class-path entries marked as test. A error marker with configurable severity could be added, so it can be switched off entirely if a user is not interested. However I'm not sure if this would be the right direction. In general I understand that plug-ins can be test-only dependencies for some and ordinary dependencies for others, but in case of 'test'-fragments using the test-attribute seems to be quite appropriated to me. > > I personally never use Feature-based launches for this family of trouble > they induce, so don't really mind in practice which fragments get added, as > long as it's easy to remove them from a plug-in based launch if I have any > doubt. What kind of trouble are you referring to? When it comes to Eclipse products I got the impression that Feature-based launches are in general superior because one has to specify less elements and they reflect better how a product is installed/started. Therefore I made a series of improvement to Feature-based launches and have a few more minor changes pending. The implemented changes are summarized in the N&N: https://www.eclipse.org/eclipse/news/4.23/pde.php#eclipse-applications-launching and the pending changes can be found in Gerrit: https://git.eclipse.org/r/q/project:pde/eclipse.pde.ui+status:open
Verified with Eclipse SDK Version: 2022-03 (4.23) Build id: I20220215-1800
