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.
See #27112. Form Editor's Component Palette will probably need to construct GUI beans from the user project's classpath. If so, the "normal" .instance files cannot be used as they use module classloaders and will not be able to properly use currentClassLoader. Provide InstanceCookie through a ProjectObject, rather than DataObject and have instanceCreate to use a classloader, which loads classes from ProjectPath.RUNTIME classpath (or some derived, Form-module provided one ?). Should these InstanceObjects reside on project fs or will be Component Palette global ? Issues: what to do w/ several classpaths within one project (different build targets with different sets of libraries) ?
Some comments... > Should these InstanceObjects reside on project fs or will > be Component Palette global? Currently, the palette is global (the instance files are placed in default filesystem). For several reasons I think it should stay global also in future. The global form of palette makes some serious implications, e.g. like: (1) as the classpath is defined by projects, some palette items (defined by user) can be unavailable at the moment (depending on opened project), (2) it's hardly possible to deliver project context to instance file. (1) requires the InstanceCookie provider to be able to recover from errors (ClassNotFound...) when classpath changes (i.e. another project is opened). This is where current InstanceDataObject fails. (2) means that the InstanceCookie provider should probably use classpath from all opened projects (so working still on DataObject, not ProjectObject). I guess these ideas can be wild for someone, so I'm waiting for comments - before writing the other requirements ;-)
Provided that you want to have the Component Palette global, then you indeed need a merge of all classpaths from all projects for loading your beans. This could be solved with the currentClassLoader() and/or union filesystem (see issues #27112, #27386). Though it's none of my business indeed, what is the user model for the component palette ? Is it OK if it offers a bean from another project, so the source becomes uncompilable ?
*** Issue 27826 has been marked as a duplicate of this issue. ***
Well, it is not so obvious now if this will be really needed by form module. See issue 27181 - form editor could probably handle this by itself. In other words, it does not need whole InstanceCookie functionality (needs just the class name), but on the other hand, more stored information is needed (i.e. JAR/project an item belongs to). More important seems to be the related issue with classloader (see issue 27182). Should we create a new issue in java module for this? Or reopen/reword issue 27826?
I am not sure about the use case of this feature. The FormEditor can use a FileSet to store actual PMs and the currentClassLoader to create instances as Svata has already described. Priority changed from P1 to P4. BTW: I don't want to make the Java module API like the Multics, "the tool for everything". If there is a simple way how to do it I don't see a reason why Java Module API should provide an additional contract.
See comments above, especially Additional Comments From Svatopuk Dedic 2002-10-02 00:04 PDT
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped. Marking issue as VERIFIED --->
---> CLOSED