Community
Participate
Working Groups
Build Identifier: N20100727-2000 You can describe both features and bundles in the .product file definition which you desire to be included in your product. However, “useFeatures” attribute in .product file determines which of the two types of installable units will be actually included in the product when published. The relation is as follows: If ‘useFeatures’ is “true” then only the features described in the product file are included into the product; described bundles and fragments, if any, are ignored If ‘useFeatures’ is “false” then only the bundles described in the product file are included into the product; described features, if any, are ignored If the attribute is not defined in the .product file then its value is assumed to be “false” and we arrive at the case above. The user is not warned about this behavior and may be left confused with the final result if the attribute’s value has been overlooked. Reproducible: Always Steps to Reproduce: 1. Create a product file which contains both bundles and features 2. Add "useFeatures" attribute to product definition with value false 3. Run ProductPublisher 4. Observe that the published product lists only bundles in its requirements
Created attachment 179128 [details] Publisher supportability improvement The provided patch prints a helpful warning message if p2 product publisher application finds out that the value of the “useFeatures” attribute conflicts with the .product file contents, e.g. the value is “true” but the .product file lists bundles and vice versa.
This is related to bug 325614, we may get both in which case the warning is unnecessary.
(In reply to comment #2) > This is related to bug 325614, we may get both in which case the warning is > unnecessary. Bug 325614 is related to the creation of .product files, not to the way they are handled. The warning would be still necessary for the support of products in the old format. Besides, we don't know yet what solution will be proposed for bug 325614. For example, it could allow the creation of .product files in a somewhat backward compatible format, e.g.: - if you want to use the product in the old way, the useFeatures attribute will be generated with the proper value; - if you want mixed content, this will be notified by the absence of the useFeatures attribute. By the way, this is the proposal in related bug 325622, as you already know. :) As long as the adopted solution preserves the usage of useFeatures attribute, users will want to see these warnings. Of the three bug reports (well, one is for enhancement actually) the current is the only one which is ready for immediate contribution while the others are dependent on each other.
I agree that it would be nice to have the product publisher issue a warning when a product definition file contains an obivous user error. However I don't think that a sysout is the right way to do this. Instead, the message should be an info/warning status in the multi status returned by the publisher.
After a code review of ProductAction class, I think that the propagation of the warning message to the final status will complicate the fix too much. I suggest to simply replace the sysouts with LogHelper.log(). Thus, the messages will appear both in the logs and in the console when running the product publisher - this is enough to inform the user to take action and we meet our purpose. I am ready with a fix, based on this proposal. Would you be OK with it ?
Created attachment 197950 [details] Second bugfix proposal The new proposed patch replaces the sysout with logged messages. In case of differences between the "useFeatures" value and the product file contents, a warning will appear both in the logs and also in the console output when running the product publisher application, so the message will be visible enough for the end user to make the necessary corrections in the product definition, if necessary.
Tobias, did you have the time to look through the patch? It's a simple change so maybe if you don't have capacity, someone else of the commiters could take a look at it?
I'll integrate the patch within the next days. I am going for my proposal from comment #4, so if there is content in the product file which is ignored through the useFeatures attribute, the publisher call will return a multi-status with an info severity child with your message. @Andrew, Ian: With an info severity child status, isOK() of the status returned by ProductAction.perform will be false. Do you see any issues with that? (I'll make sure the PDE build tests pass.)
Comment on attachment 179128 [details] Publisher supportability improvement Just to let you know about my progress: The patch is integrated with the modifications proposed in comment #4: a product file with ignored content will yield an info status message. (Could be a warning as well, but it didn't seem severe enough because this can happen after normal use of the product editor. We can discuss again if you like.) I still need to adapt the callers of the ProductAction so that they don't treat the Info status as error. I am planning to address this issue generally in bug 351056, but I may not get to this in M1, so I'll do a local fix first.
(In reply to comment #9) > I still need to adapt the callers of the ProductAction so that they don't treat > the Info status as error. This is done with commit e45af3d for Juno M1. IMHO the changes don't need to go into 3.7.1. I also tried this out with Tycho and did the necessary modifications (so that Tycho will work once we update to p2 Juno M1).
