This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Ability to compose project's lookup from multiple sources | ||
---|---|---|---|
Product: | projects | Reporter: | Milos Kleint <mkleint> |
Component: | Generic Infrastructure | Assignee: | Milos Kleint <mkleint> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | abadea, jglick, pjiricka, vstejskal |
Priority: | P2 | Keywords: | API, API_REVIEW_FAST |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 87544 | ||
Bug Blocks: | 72091, 86680 | ||
Attachments: |
proposed diff of api and implementation
changes in j2se project to allow project lookup composition |
Description
Milos Kleint
2006-08-24 09:00:18 UTC
Presumably taking the freeform project SPI as a starting point, though that would need to be cleaned up quite a bit. jesse, can you point out which parts need clean-up? is it the api itself or the underlying implementation? the LookupMerger looks good and the only other api related to lookup is the projectnature's method getLookup() LookupMerger is OK, though I would probably change it so that there is one instance of LM per mergeable class, so you would have public interface LookupMerger<T> { Class<T> getMergeableClass(); T merge(Lookup lookup); } ProjectNature.getLookup as written is specific to Ant-based projects. It might be preferable to make the lookup merge SPI more generic, though in the case of Ant-based projects you do want to get access to the PropertyEvaluator etc. Note that passing an AntProjectHelper to project natures is unacceptable in general since project types such as j2seproject actually use an UpdateHelper for nearly everything and do not use AntProjectHelper directly. (Since APH is a final class you cannot create a proxy version of it with your own hooks.) Merging of ActionProvider is problematic even in freeform projects. Be careful about what default mergers you provide (if any). Created attachment 34086 [details]
proposed diff of api and implementation
Created attachment 34087 [details]
changes in j2se project to allow project lookup composition
attached is the proposed api change. I've placed it into projectapi module. It includes the framework for composing lookup from multiple sources and for merging multiple instances into one. Also added factory methods for creating merged instances of Sources, PrivilegedTemplates and RecommendedTemplate. The latter two reside in projectuiapi module. please review, thanks. I am sorry to disagree with your work, but here is my set of thoughts that shall explain my reasons: 1. well, most of the API (LookupProvider, LookupMerger and createCompositeLookup) has nothing to do with projects 2. Does it mean it can be usable without projects? Yes, it can. 3. Is it handy enough that people will try to (mis)use it? Sure, it is. In fact it filling a hole left here when looks were disgarded. 4. Ok, that means people we meaninglessly depend on projectapi module just to get the composite lookup functionality. That is no good. 5. Aha, so we should separate this generic part of the commit out into a separate module, maybe "composite-lookup", or something like that. 6. this module should likely be part of the platform cluster, as it seems to be useful for everyone 7. hey, wait a moment, there already is module like this in platform! It is the mime-lookup module. It does few things differently, and is artificially restricted just to mimetype lookup, but in general there is nothing preventing it to handle the kind of functionality Milos needs in projectapi. 8. So I talked to Vita, as he knows the most about mimelookup currently. He confirmed that mimelookup misses the LookupMerger functionality, that would need to be added, otherwise it seems general enough to do what Milos needs. 9. So let's move the generic part of Milos's patch to mimelookup for a benefit of everybody. Pros: - standard way how to register items into composite lookups using layers - one code to bugfix Cons: - mimelookup is horrible name for a generic lookup no longer tight to mimetype Regardless of the last cons, I think that sharing the composite lookup infrastructure is beneficial and looks like the right way to go. Vita is in Prague by next Wednesday, so we might meet and discuss possible details of the implementation, resolve problems, etc. Wednesday 10am CET? Wed 10am CET works for me. 2. it is usable without project but there is nothing magical about it. people can easily write it themselves or copy from projects. The important part is not the method signatures but the semantic meaning regarding what can be done to a project from 3rd party plugins. adding the api to "mime-lookup" will generate more confusion among the api users then it gives to the reusability of the api. I don't know why mime lookup could not have a similar LookupMerger functionality but with the semantic context of the mime-lookup. Fine with me. But not sure any of the mentioned apis gains anything by sharing the interface for doing so. if there are no more objections, I will integrate into trunk tomorrow. Additionally I would like to add javadoc and code asserts to enforce that only the project type owner can put LookupMerger instances into lookup. That should ensure that no 3rd party module can hijack the project behaviour without the consent of the project owner. integrated into trunk. both the api/impl and j2se project conversion. Aren't you going to change the ant/freeform SPI to use this? I can, but haven't thought about it yet. I haven't done it for customizer panels either. It would probably mean a non-compatible change in the spi. I filed issue #86680 for matching freeform SPI changes. |