Bug 196455 - Remove need for ProjectClassPathExtender implementations in project lookup
Remove need for ProjectClassPathExtender implementations in project lookup
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Project
7.0
All All
: P3 (vote)
: 7.1
Assigned To: Jesse Glick
issues@java
: API, API_REVIEW_FAST
Depends on: 96414
Blocks: 75471
  Show dependency treegraph
 
Reported: 2011-03-08 21:56 UTC by Jesse Glick
Modified: 2012-06-06 15:53 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Running patch: hg pdiff ProjectClassPathExtender_196455 (101.56 KB, patch)
2011-08-15 21:36 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-03-08 21:56:49 UTC
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).
Comment 1 Tomas Zezula 2011-03-09 09:08:05 UTC
Sounds good.
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.
Comment 2 Jesse Glick 2011-03-09 17:05:17 UTC
Assigned to me for now, I will see if I can get to it.
Comment 3 Jesse Glick 2011-08-12 18:38:04 UTC
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.
Comment 4 Jesse Glick 2011-08-15 18:45:52 UTC
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.
Comment 5 Jesse Glick 2011-08-15 19:49:12 UTC
In branch have now removed all usages of ProjectClassPathExtender in main & contrib except:

1. The compatibility APIs: ProjectClassPathModifier.extenderForModifier, and ClassPathExtender (now itself unused).

2. BlueJ.

3. Java ME (which never seems to have implemented ProjectClassPathModifierImplementation).

4. J2SEProjectClassPathModifierTest.testClassPathExtenderCompatibility (which now implicitly tests extenderForModifier).

5. contrib/gwtsupport.
Comment 6 Jesse Glick 2011-08-15 21:36:03 UTC
Created attachment 109994 [details]
Running patch: hg pdiff ProjectClassPathExtender_196455
Comment 7 Jesse Glick 2011-08-15 21:36:27 UTC
Please review.
Comment 8 David Konecny 2011-08-16 01:02:11 UTC
(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!
Comment 9 Jesse Glick 2011-08-22 19:38:05 UTC
core-main #c04c9ba92cad
Comment 10 Quality Engineering 2011-08-23 14:00:19 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/c04c9ba92cad
User: Jesse Glick <jglick@netbeans.org>
Log: #196455: provide better deprecation path for ProjectClassPathExtender.


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