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.