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.
Summary: | Support SPI: visual classpath customizer | ||
---|---|---|---|
Product: | projects | Reporter: | Jesse Glick <jglick> |
Component: | Generic Projects UI | Assignee: | Milan Kubec <mkubec> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | dkonecny |
Priority: | P2 | Keywords: | API |
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 41837 |
Description
Jesse Glick
2004-09-28 18:05:02 UTC
Probably not usable for web apps anyway, since they have a slightly different GUI - note checkbox column for each CP entry... Is this really needed? I would close it as wontfix. What are the usecases here? David would know best. As part of issue 150357 I will take some of existing classes implementing classpath customization and put them into friend API module (java.api.common) and make them reusable for J2EE/Web projects. In that respect this could be closed as dupl of issue 150357. Re. usecases - classpath is Java concept and so all of classpath related code (if possible) should be within Java domain. It is quite a lot of code which become non-trivial and history shows that all clones in J2EE/WEB are still identical to its J2SE ancestor (minus changes caused by bugfixing). The checkbox/editbox shown in some of Web/J2EE classpath customizers is visual part which is project type specific but underlying data model is in principal the same (current classpath data model is implemented as list of ClassPathSupport.Item's and in issue 150357 I enhanced it with Properties for an additional attributes). This data model is what I think should definitely be reused - parsing properties and project.xml and creating memory model; altering model with different types of classpath items: project, libary (global or shared), jar (absolute or relative or variable based path; javadoc and sources jars); handling broken references; saving changed model; etc. All this should be reusable. *** This issue has been marked as a duplicate of 150357 *** |