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.
The FROM_JAR and FROM_LIBRARY cases look suspicious; don't know what you're doing but it sounds wrong. FROM_PROJECT is almost certainly wrong. + else if (origin == FROM_PROJECT) { // NOI18N + Project project = ProjectManager.getDefault().findProject( + FileUtil.toFileObject(new File(originLocation))); + if (project != null) { + AntArtifact[] artifacts = + AntArtifactQuery.findArtifactsByType(project, "jar"); // NOI18N + roots = new URL[artifacts.length]; + for (int i=0; i < artifacts.length; i++) { + File jarFile = new File( + originLocation + artifacts[i].getArtifactLocation().toString()); + roots[i] = FileUtil.getArchiveRoot(jarFile.toURI().toURL()); + } + } + } So you're storing some project and then finding every JAR it produces? Why?? This makes little sense. What if the project produces two JARs, one of which is a bean JAR and one of which is something completely different? Probably the storage of palette items is just designed wrong. Keep the actual classpath you need to use for the bean. If you need to know more about where it came from later - e.g. to add something to a j2seproject classpath - get the information when you need it. E.g. you can use AntArtifactQuery.findArtifactFromFile.
Thanks for noticing me. This code is still experimental (is not executed from anywhere yet). Asking a project for all JARs does not make much sense, I agree. The palette item will know which concrete JAR it need. But the other cases seem ok to me - a reference to JAR or library needs to be kept by palette items, so they know where to load from. Why is this suspicious?
FROM_JAR is probably fine. FROM_LIBRARY may be; depends on what you want to happen if that library is removed (when the JAR(s) still exists), or its CP is changed, etc. I think FROM_PROJECT is the problematic one. Either keep the actual JAR path you are using, or keep both the project dir and the artifact's associated target, which together form a primary key.
In case of a project, the palette item now holds the name of the output JAR file. When adding to a form, AntArtifact is found for the JAR and added to the project classpath via ProjectClassPathExtender. As for the library case, I think it's enough to refer just to the library name - the library is found when needed. If the library is removed, the item fails to load. But once the item class is loaded, changes in the classpath are not reflected (at this level). I'm closing this as fixed. Thanks for feedback.
verified