ProjectClassPathExtender is deprecated, but various projects keep an impl around for compatibility with old clients. (There is already a way for new clients to use old SPI impls, but not vice versa.) This causes code bloat and forces use of a deprecated SPI.
Should be a factory method (in ProjectClassPathModified I guess) for a ProjectClassPathExtender impl based on a ProjectClassPathModifierImplementation impl that you can add to project lookup. It would guess at the right params. For example, addLibrary(lib) would delegate to addLibraries([lib], findFirstSourceGroup(SOURCES_TYPE_JAVA), ClassPath.COMPILE).
Are you going to work on it or should I do it?
It would be also good to replace the usages of PCE in the IDE.
Assigned to me for now, I will see if I can get to it.
Using core-main ProjectClassPathExtender_196455 to work on it. Please take a look if you are interested.
I may also want to move the maven impl of LookupMerger<ProjectClassPathModifierImplementation> into java.project.
David - I would appreciate it if you could look over the EE-related changes, especially in core-main #2bb44b3f69ec. Unit tests pass but I am not entirely sure what the ClassPathSupportCallbackImpl.ELEMENT_INCLUDED_LIBRARIES (etc.) param was for (not used by j2seproject) and if the ClassPathModifier fully subsumes that function.
In branch have now removed all usages of ProjectClassPathExtender in main & contrib except:
1. The compatibility APIs: ProjectClassPathModifier.extenderForModifier, and ClassPathExtender (now itself unused).
3. Java ME (which never seems to have implemented ProjectClassPathModifierImplementation).
4. J2SEProjectClassPathModifierTest.testClassPathExtenderCompatibility (which now implicitly tests extenderForModifier).
Created attachment 109994 [details]
Running patch: hg pdiff ProjectClassPathExtender_196455
(In reply to comment #4)
> David - I would appreciate it if you could look over the EE-related changes,
> especially in core-main #2bb44b3f69ec. Unit tests pass but I am not entirely
> sure what the ClassPathSupportCallbackImpl.ELEMENT_INCLUDED_LIBRARIES (etc.)
> param was for (not used by j2seproject) and if the ClassPathModifier fully
> subsumes that function.
Re. "ClassPathSupportCallbackImpl.ELEMENT_INCLUDED_LIBRARIES (etc.)" - web/ee projects have additional metadata for classpath items (eg. should compilation cp item be included in runtime cp or not? at what path in archive the cp item should be stored?) and these metadata are stored in project.xml. Project classpath modifier needs to create them/remove them from project.xml when classpath is modified.
After reading lots of code and trying to figure out how it used to work before your change I think your changes are fine. I cannot remember why ClassPathSupportCallbackImpl.ELEMENT_INCLUDED_LIBRARIES would be passed both to deprecated ClassPathExtender and also separately to ClassPathModifier (via ClassPathModifier.Callback.getElementName()). Must be a result of some refactorings - there was lots of them; it used to be way more messier than now. Thanks for fixing web/ee project types!
Integrated into 'main-golden'
User: Jesse Glick <email@example.com>
Log: #196455: provide better deprecation path for ProjectClassPathExtender.