Bug 83343 - Ability to compose project's lookup from multiple sources
Ability to compose project's lookup from multiple sources
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
5.x
All All
: P2 (vote)
: 6.x
Assigned To: Milos Kleint
issues@projects
: API, API_REVIEW_FAST
Depends on: 87544
Blocks: 72091 86680
  Show dependency treegraph
 
Reported: 2006-08-24 09:00 UTC by Milos Kleint
Modified: 2006-11-20 13:03 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
proposed diff of api and implementation (42.27 KB, patch)
2006-09-18 15:03 UTC, Milos Kleint
Details | Diff
changes in j2se project to allow project lookup composition (4.78 KB, patch)
2006-09-18 15:05 UTC, Milos Kleint
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Kleint 2006-08-24 09:00:18 UTC
allow to compose the project's lookup from multiple sources. is part of the
project extendibility effort - #72091
Comment 1 Jesse Glick 2006-08-28 18:34:36 UTC
Presumably taking the freeform project SPI as a starting point, though that
would need to be cleaned up quite a bit.
Comment 2 Milos Kleint 2006-09-05 12:49:03 UTC
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()

Comment 3 Jesse Glick 2006-09-06 14:35:53 UTC
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).
Comment 4 Milos Kleint 2006-09-18 15:03:56 UTC
Created attachment 34086 [details]
proposed diff of api and implementation
Comment 5 Milos Kleint 2006-09-18 15:05:04 UTC
Created attachment 34087 [details]
changes in j2se project to allow project lookup composition
Comment 6 Milos Kleint 2006-09-18 15:09:02 UTC
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.
Comment 7 Jaroslav Tulach 2006-09-21 13:57:26 UTC
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?


Comment 8 Vitezslav Stejskal 2006-09-21 17:14:03 UTC
Wed 10am CET works for me.
Comment 9 Milos Kleint 2006-10-02 14:02:36 UTC
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.
Comment 10 Milos Kleint 2006-10-04 14:15:39 UTC
if there are no more objections, I will integrate into trunk tomorrow.
Comment 11 Milos Kleint 2006-10-04 14:17:51 UTC
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.
Comment 12 Milos Kleint 2006-10-05 12:10:52 UTC
integrated into trunk. both the api/impl and j2se project conversion.
Comment 13 Jesse Glick 2006-10-05 21:14:44 UTC
Aren't you going to change the ant/freeform SPI to use this?
Comment 14 Milos Kleint 2006-10-06 07:39:22 UTC
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.
Comment 15 Jesse Glick 2006-10-06 15:14:11 UTC
I filed issue #86680 for matching freeform SPI changes.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo