Community
Participate
Working Groups
categories should only be declared by approved sources. Ensure that the discovery system can enforce this policy based on declarative syntax in the directory.
implemented: the directory must now indicate which bundles may provide categories with @permitCategories="true"@
Created attachment 135892 [details] mylyn/context/zip
David, can you change the policy to always allow contributions from local extensions? That would make testing much easier.
(In reply to comment #3) > David, can you change the policy to always allow contributions from local > extensions? That would make testing much easier. How about a system property to disable the check? I'd prefer not to open it up for all plug-in extensions.
Sorry, I missed your comment. Properties are hard to discover and will leave testers wondering why their contributions are not visible. What is the main concern with category contributions from installed features? My understanding is that the use-case for loading extensions from installed bundles is testing. Even if a plug-in defined a category I don't think the discovery mechanism needs to actively prevent contributions from plug-ins that were deliberately installed by a user.
(In reply to comment #5) > Properties are hard to discover and will leave > testers wondering why their contributions are not visible. Agreed > What is the main concern with category contributions from installed features? In previous discussions we agreed that categories could only be created if they meet certain approval criteria. Currently the only way to manage this is via the directory. Installed bundles are not referenced in the directory, thus by default their category-creating permission is turned off. > My understanding is that the use-case for loading extensions from installed > bundles is testing. Though this is a valid use case we should not assume that people will use it only for that purpose. > Even if a plug-in defined a category I don't think the > discovery mechanism needs to actively prevent contributions from plug-ins that > were deliberately installed by a user. This statement is contrary to previous discussions. If we need to reconsider, then let's do that. Perhaps a discussion at the next weekly meeting. Keep in mind that categories should rarely be created. We only expect to have a few, and they'll be done as part of 3.2. So while your concerns are valid they may only affect a person once or twice over the next few years.
Created attachment 138238 [details] patch
The driver for adding this restriction was to control the contribution of categories on the Mylyn discovery portal. The intention was not to generally limit category creation. I believe that category contributions should be allowed by default and explicitly disabled instead of the other way around. The discovery code is fairly generic and may get reused by others in the future. It's an unnecessary hurdle to require integrators to discover a magic system property for enabling contributions (I am not aware of any other Eclipse extension with a similar requirement). In addition it makes testing more difficult if a contribution does add categories or if an extension specifies a custom category. Mik, what are your thoughts?
(In reply to comment #8) > The driver for adding this restriction was to control the contribution of > categories on the Mylyn discovery portal. The intention was not to generally > limit category creation. I'm not sure if that satement is correct. My understanding is that the intention was to prevent arbitrary creation of categories. > The discovery code is fairly generic and may get reused by others in the future. The discovery code is currently internal and should not be reused by anyone in its current form. > It's an unnecessary hurdle to require integrators to discover a magic system > property for enabling contributions (I am not aware of any other Eclipse > extension with a similar requirement). Integrators should not be creating categories. So none of them should encounter this problem. > In addition it makes testing more > difficult if a contribution does add categories or if an extension specifies a > custom category. Agreed, though as afore mentioned this issue should only be encountered when the Mylyn team decides to create a new category, which is unlikely to occur often.
> > The discovery code is fairly generic and may get reused by others in the > future. > > The discovery code is currently internal and should not be reused by anyone in > its current form. Even if an implementation is in an internal package there is always a chance that it will get reused by others and we should aim for supporting that within a reasonable effort. > > It's an unnecessary hurdle to require integrators to discover a magic system > > property for enabling contributions (I am not aware of any other Eclipse > > extension with a similar requirement). > > Integrators should not be creating categories. So none of them should encounter > this problem. I do not follow that argument. We simply can not anticipate all use cases of integrators, e.g. for a discovery portal that is internal to a company. We know of environments where users are not allowed to install extensions unless they come from internal sources. > > In addition it makes testing more > > difficult if a contribution does add categories or if an extension specifies a > > custom category. > > Agreed, though as afore mentioned this issue should only be encountered when the > Mylyn team decides to create a new category, which is unlikely to occur often. It is possible that discovery jars that are not maintained by the Mylyn project will be permitted to contribute categories.
(In reply to comment #10) > Even if an implementation is in an internal package there is always a chance > that it will get reused by others and we should aim for supporting that within a > reasonable effort. There is always a chance, I agree _however_ there is no requirement in the discovery project for supporting a reusable API, particularly not in internal packages. Until the requirements change I don't see any need to support such usage. > > Integrators should not be creating categories. So none of them should > encounter > > this problem. > > I do not follow that argument. We simply can not anticipate all use cases of > integrators, e.g. for a discovery portal that is internal to a company. We know > of environments where users are not allowed to install extensions unless they > come from internal sources. The requirements of this project as set out in previous discussions is to only allow creation of categories in cases where it's approved. I'm open to changing those requirements; however until those requirements change we should not open it up. > It is possible that discovery jars that are not maintained by the Mylyn project will be permitted to contribute categories. See above; the current requirements prohibit this.
revised requirements per today's call: installed plug-ins can create categories
new policy implemented
