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.
J2SE library descriptors already let you deliver a library to an end user via a module. But there's no way through the UI to put a JavaBean from that library on the component palette. It would be nice if the template would take care of this - it should be possible to simply detect the presence of any Java-Bean: manifest entries and choose based on that. There are a lot of JavaBeans out there, as well as a lot of small vendors who do components, and with nbextras.org existing as well, this could be a huge value add both in terms of the number of modules out there (we like them metrics) and in terms of the value add to Matisse. I'd call this P1 at the lowest, in terms of potential to do good things for NetBeans.
Just scanning for "Java-Bean: true" might not be enough; I imagine many libs have valid beans which are not marked as such. Perhaps not *production* JavaBeans libs from established vendors, but individual efforts. Would preferably permit you to manually add public classes with public no-arg constructors. (Do they have to extend java.awt.Component?) But not critical I guess. Wade expressed interested in this, IIRC. Looks like you can just create files in Palette/Beans/*.palette_item like <?xml version="1.0" encoding="UTF-8"?> <palette_item version="1.0"> <component classname="pkg.Clazz" type="visual"/> <!-- opt; defaulted? <icon16 urlvalue="nbres:/pkg/res/icon16.gif"/> <icon32 urlvalue="nbres:/pkg/res/icon32.gif"/> description possible too; again, defaulted? --> </palette_item> but there is no apparent documentation for the format that I can see. Do we have a completely undocumented SPI here? (There is "Common Palette" Javadoc but this says nothing about the Form Editor's palette in particular.) form/arch/arch-form.xml claims ----- Content of the component palette is read from the layer. It is located in FormDesignerPalette folder with one level of subfolders serving as categories, and .palette_item files in the subfolders as items. The palette item file is a xml file defining the class, display name, icon, and origin of one component in the palette. See form module's layer file for examples. ----- but the folder name is wrong and the last sentence here is not documentation.
I have a separate module I'm currently working on which was going to allow such things. It was a completely separate module though. I've been planning to start trying to build this stuff into the Library projects. I also plan on allowing selection of a J2SE library from the Tools->Library Manager for the module to wrap. My only limitation is the time I can devote as I have a lot on my plate, but yes I have interest in adding this stuff. If anyone else is planning on working on this please let me know so I don't spend time on it at the same time. I was planning on grabbing code from the 'Form Editor' module for the bean selection stuff, and yes it allows one to see either only marked beans or all beans (no Java-Bean: true in manifest).
Should I assign this to myself, or how does it work if I intend to be working on a patch? Thanks for answers.
If you plan on creating a patch for apisupport/project/src/org/netbeans/modules/apisupport/project/ui/wizard/Library*.java then go ahead and assign to yourself. BTW see http://www.netbeans.org/community/contribute/patches.html
See contrib/Beans2nbm/beans2nbm - it's a standalone tool that will take a JAR w/ JavaBeans, read the manifest and via a wizard, generate a complete NBM that will install the beans on the Component Palette. It's not a complete solution - not as flexible as what APISupport could do, since it just writes everything into the zip stream and kicks it out onto disk, and doesn't use any NetBeans code at all, but as a way to get folks with JavaBeans who may have no interest in running NetBeans to make their components easily available in NetBeans, it works. Wade or whoever, feel free to borrow from it if there's anything useful to you there. I'll probably eventually make an integration that provides the action for it over jar files and J2SE projects; a better solution from the apisupport module is still desirable.
Yes that was something similar to what I was working on. I had the Library->Module part working, but had not yet done the part to add the beans to the palette from the module. Basically what I had done so far was create a module that would take a J2SE library and package all jars and zips into a structure and make a module which would install as a module which could be depended upon to access the classes from the library and would install a library to the J2SE Library Manager so this library could be used in both module and J2SE and Web applications. What you have then would help me in finishing that part of that module as it does just what your does as it creates a zip stream and dumps the module to disk less the beans from the project being added to a palette and category. So, I think using both of these things (when I get some time...swamped) I can start trying to add the overall capabilities to the project types as Jesse mentioned in the mailing list on this issue unless someone is already at work on this. Thanks Tim. If nothing else what you and I have together pulls the information together (less the part to tie into the API support and projects). I was thinking about trying to add support to J2SE projects and standalone module projects to allow either one to generate both modules and libraries and vice versa Module Project <-> J2SE Library Project (and the module generated by them allow beans to be added to the palette and a category). Basically allow the projects to have a check box which could be turned on to allow the extra information to modified/entered and to be generated into the dist folder and the module to have the ability to become a J2SE library just by turning it on in the project....hope that makes sense.
I think this deserves a closer look.