Remove the "Add Required Plug-ins" button from the Product Editor's Contents tab

[HannesWell]

In the Contents tab of PDE's Product Editor there is a button to Add Required Plug-ins to a Product, that adds all Plug-ins that are required by the ones already included in the product and not yet in the product. An equivalent button exists for Feature based products:

This used to be useful to launch Products in the IDE before the option to Include required Plug-ins automatically was available and requirements were not automatically added. When building Products with Tycho/P2 requirements are already added for a long time and there is currently no way to disable that.
Consequently adding requirements now is just useless and leads to 'over-defined' products, meaning the configuration could be smaller with the same outcome.

Such over-defined product can be tedious to maintain when added requirements change the bundle name, which requires changes like #280.

Because I see no real value for those Add Requirements buttons (and the associated check-box) anymore and using them can make maintaining the product harder, I suggest to remove them.

Or does anybody still knows a reasonable use case for them?

[laeubi]

I won't remove them, these two functions are simply different and its more a user choice if one likes to mention dependencies directly.

What would be useful would be the revers, a button instead to remove items that are already covered by others so if the "include required" is set PDE computes what items are no longer required to be present.

[HannesWell]

I won't remove them, these two functions are simply different and its more a user choice if one likes to mention dependencies directly.

It would still be possible to add requirements (but then of course one by one manually).
But currently the Add Required (Plug-ins) (IMHO) encourages users to add requirements although it is not necessary. From my experience (of others and myself) user tend to click buttons if they are available. And the name can be understood that it is necessary to do it.

What would be useful would be the revers, a button instead to remove items that are already covered by others so if the "include required" is set PDE computes what items are no longer required to be present.

That is something I thought about as well already. Regardless of this the initial suggestion this is something that would help to clean up existing products. So a button like Remove Implicit could be added and it is only enabled, if the automatic inclusion of requirements is enabled.

This gives me the idea, that the Add Required button could be disabled if the automatic inclusion of dependencies is enabled?

[laeubi]

This gives me the idea, that the Add Required button could be disabled if the automatic inclusion of dependencies is enabled?

Sounds reasonable.

[merks]

Is the statement also true when the product is built within the IDE by exporting it rather than by Tycho?

[HannesWell]

I just checked that and indeed the IDE export does not add requirements for Plug-in and Feature based products.
As long as this is not fixed (as suggested elsewhere by using the P2-director directly instead of the ant-tasks) this suggestion is actually obsolete.

[vogella]

I like to see in the product what will be exported and use these buttons frequently

[HannesWell]

Yes, it often interesting to see the full set of Plug-ins/Features that will eventually be installed in the product, but wouldn't it be better to have a dedicated view for that, instead of adding required units in the editor?

Instead of a separate view, the resolved units could be displayed grayed out in the contents tab.

[vogella]

Yes, it often interesting to see the full set of Plug-ins/Features that will eventually be installed in the product, but wouldn't it be better to have a dedicated view for that, instead of adding required units in the editor?

Instead of a separate view, the resolved units could be displayed grayed out in the contents tab.

I don't understand why this would be better. If my clients develop an RCP they typically want to know which JARs find their way into the final application. By having all listed in a text file like product you can easily see these also in your Git repo via the web browser. An additional view which only works in Eclipse is not that powerful. The question, does the application uses XXX lib can be easily answered if you currently check your product. The dynamic display of plug-in, like for example in the target platform is not as nice, it is slow, the calculation takes time and it is errorprone (speaking now for the target platform display, as you sometimes get NPEs, frequent downloads).

So -1 from me for removing or disabling this depending on state. Such disablement is only confusing for the user.

What would be the advantage of not listing all plug-ins / features which go into the final product?

[HannesWell]

I don't understand why this would be better. If my clients develop an RCP they typically want to know which JARs find their way into the final application. By having all listed in a text file like product you can easily see these also in your Git repo via the web browser. An additional view which only works in Eclipse is not that powerful. The question, does the application uses XXX lib can be easily answered if you currently check your product.

I understand that one want's to know the content of the app quickly but the product definition is not a reliable source for that.
For example if one updates the TP and any plugin listed in the product gets a new dependency not yet listed, that jar will be build into the final application nonetheless. At least when the product is build with Tycho/P2, as noted above, PDE-Build works indeed different at the moment. But when one builds with Tycho one can only say that the listed plug-ins will be in the product, but not if any given plug-in will not be in it, before the product is build.
Or do you/your clients update each Product's content list with each TP update?

At the same time this strategy can have the effect that actually not needed plug-ins are installed in the product. If some plug-in was listed in the product because it used to be a dependency of another, but that plug-in get rid of the dependency that dependency stays in the product forever, because Add Required only adds plug-ins/features. Removal of obsolete dependencies needs to be done manually and that person needs to know that that plug-in was only listed because it was a dependency and not because it was one of the really wanted 'root'-plugins.

Therefore my preferred strategy to define products is to add the plug-ins/features I really want to have in it (the 'root' artifacts of the dependency tree) and to use autoIncludeRequirements=true so that all requirements are added automatically when launching that product from the IDE and when the product is build. This way only those artifacts that are really wanted and needed are installed.

The dynamic display of plug-in, like for example in the target platform is not as nice, it is slow, the calculation takes time and it is errorprone (speaking now for the target platform display, as you sometimes get NPEs, frequent downloads).

The performance of the proposed view cannot be compared with the Target-Editor. Such a Resolved Contents view in the Product-Editor would work on the already resolved target-platform state as it is and would just collect all dependencies of the listed artifacts in that state. This is basically a breath first search that runs magnitudes faster compared to the resolution of a TP, since it just operates on the existing state and does not perform any downloads.
The runtime would be the same like when you press Add required in the Product-Editor or use Include required plug-ins automatically while launching for launching in the IDE. For the former action my subjective impression is that this completes almost instantaneously and most of the time is spent to update the UI.

So -1 from me for removing or disabling this depending on state. Such disablement is only confusing for the user.

What would be the advantage of not listing all plug-ins / features which go into the final product?

As described above/initially it would simplify the maintenance of a Product when dependencies changed, renamed or removed and make it simpler to get products that don't contain unnecessary plug-ins.
Removing Add Required would encourage users to not do that respectively would make it de-facto impossible because nobody want's to do that manually.

Nevertheless before that could be done completely the Product export from the IDE has to work more like Tycho/P2 respectively should be done by P2.

[vogella]

Or do you/your clients update each Product's content list with each TP update?

Yes, we frequently update the product especially after a TP update.

At the same time this strategy can have the effect that actually not needed plug-ins are installed in the product.

Good point, that and the following explanation makes sense. So I remove my -1 vote and would be ok with the removal of these buttons.