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.

Bug 129439 - move ClassPathProviderMerger from projects to Java API Common
Summary: move ClassPathProviderMerger from projects to Java API Common
Status: RESOLVED DUPLICATE of bug 134341
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: apireviews
URL:
Keywords: API_REVIEW_FAST
Depends on:
Blocks:
 
Reported: 2008-03-06 16:53 UTC by Lukas Jungmann
Modified: 2008-05-20 08:34 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
proposed API (3.88 KB, text/plain)
2008-03-06 16:54 UTC, Lukas Jungmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Jungmann 2008-03-06 16:53:24 UTC
ClassPathMerger is now copy & pasted in all project types. This change is about moving this class to Java Common Project
API module so projects can share one implementation.
Comment 1 Lukas Jungmann 2008-03-06 16:54:32 UTC
Created attachment 57901 [details]
proposed API
Comment 2 Lukas Jungmann 2008-03-06 17:23:28 UTC
ooops, I meant ClassPathProviderMerger (not ClassPathMerger)
Comment 3 Jesse Glick 2008-03-06 17:46:06 UTC
The Javadoc and impl do not seem to match. Spec says that ClassPath's will be appended. But the impl just picks the
first CP returned by any provider and returns it as is. I guess all the CP's should be concatenated (with appropriate
listening support).
Comment 4 Tomas Zezula 2008-03-06 18:00:22 UTC
[tz1] Add a note into apichanges.xml
[tz2] I know that the common API was not yet released, but there was a beta which may be treated as a small release, so increasing spec version  may be 
good.
[tz3] I would prefer  full name createClassPathProviderLookupMerger instead of  createCPPLookupMerger

Comment 5 Petr Hejl 2008-03-07 09:15:18 UTC
[ph1] I would rather use Parameters.notNull() rather than assert to check the parameter of the api method.
Comment 6 Lukas Jungmann 2008-03-10 22:10:20 UTC
re [ph1]: Ok

re [tz1-2]: I was thinking about that, but wasn't sure. So I'll add it.

re [tz3]: I've got inspiration for the name in org.netbeans.spi.java.project.support.LookupMergerSupport and tried to be
consistent with that. Anyway I'll change it to createClassPathProviderLookupMerger (looks better)

re Jesse: "I guess all the CP's should be concatenated (with appropriate listening support)."

Yes, that's a goal. I've discussed your "requirement" with Andrei today and have one question - do I need to care about
the case that some CPP will return different classpaths for a FileObjects in the same SourceRoot? I'm trying to figure
out what should I use as a key for a cache of already known classpaths - using FO in question doesn't seem to be the
right solution since there could be hundreds or thousands of FOs (maybe use some hard limit on size of the cache?) and I
think sth like key=srcRoot+cpType could be sufficient. What do you think?

Thanks for any suggestion.
Comment 7 Jesse Glick 2008-03-10 22:49:47 UTC
key=srcRoot+cpType should be fine.
Comment 8 Milos Kleint 2008-05-20 08:34:37 UTC
i've integrated issue #134341 which is probably a duplicate of this one.
The added lookup merger for classpath provider is merging the results of originating CPP instances.It's currently
caching results on FileObject+Type. Feel free to improve the implementation as per suggestions in comments.

*** This issue has been marked as a duplicate of 134341 ***