I wrote an eclass to auto-generate the necessary netbeans module for any java library to be recognized by netbeans as a library (under Tools->Libraries). The module descriptor files are stored in /usr/share/netbeans-portage-cluster. For netbeans to pick up that cluster, add this line to $netbeans_dir/etc/netbeans.conf: netbeans_extraclusters="/usr/share/netbeans-portage-cluster" To add support to a java ebuild, inherit the eclass and add something like # use netbeans-library && java-netbeans_create_module to the ebuild (see attached xalan ebuild for example). This is tested with netbeans-6.8. There is one remaining problem though: Netbeans seems not to handle modules not under its own control not well; if a module is installed, un-installed, then re-installed, it won't be picked up any more. There might be an option to get netbeans to actively scan the extra cluster on each start for new/updated/removed modules, will investigate... Reproducible: Always Steps to Reproduce:
Created attachment 217497 [details] java-netbeans-library.eclass
Created attachment 217498 [details] xalan-2.7.1.ebuild with netbeans support
Update: Aforesaid problem (un-installing, re-installing) seems to have gone away since netbeans-6.5.
Created attachment 218221 [details] a few fixes and cleanups
Created attachment 218835 [details] handle SLOTs correctly
nice thing. only thing that imo seems to be solved is when new java packages are installed or some are removed. did you find out a way how to regenerate the list on each netbeans startup?
Just tried once again to un-install my example package xalan, restart netbeans (library and module gone), re-install, re-start netbeans (library and module back). The bug is gone. I do get, however, an exception (red symbol on the lower right) complaining that some zipfile could not be openened, probably the module's resource jar. I'd say this is a netbeans bug, and not a very serious one at that. I just wondered: Could one integrate the call to the java-netbeans-library eclass into java-pkg-2 to have the integration feature while not having to change ebuild code?
are you still interested in this feature? i got some ideas while preparing new ebuilds for netbeans 7.0
Yes I am, but I noticed that the problem with netbeans not picking up newly installed libs is back with version 7.0. What do you have in mind?
well, i was thinking about it and it seems "little bit" overkill to me to add support for netbeans to every java package when less than 1% of gentoo users in fact use gentoo. so my idea was following: i could add some use flag to netbeans ebuild that would enable support for this feature. when enabled, netbeans startup script would first run your script, that would update netbeans database about the installed jars. it would have two slightly different behaviors, depending on whether it is running for the first time or it has already been run before: 1) on first run, it would read all /usr/share/*/package.env files and pass the info to function that would generate netbeans library xml files. 2) on second run, it would read emerge log, either directly or through a command line tool and see whether there were any additions or removals since last check (so it would have to store last check timestamp somewhere). then it would pass info about new and modified packages to the same function as above, or it would perform removal of netbeans files for removed package. these steps above need to be different only for detection of what packages were added and removed. the rest of the code can be same for both cases. it's also easy to check whether the package has sources and javadoc compiled, as these are in /usr/share/package/(api|sources). this approach is imo better as it is run only for users that use netbeans and want this feature (devs using only maven would not use it for example). little disadvantage is that it might slow netbeans startup little bit, but it would be probably very small slowdown compared to how long it takes to start netbeans. there are two things that would have to be solved though: 1) the script, if run from netbeans startup script, would have to be able to write files that the user himself should not be able to modify, but i guess this is solvable. 2) the script should check whether it's already running to not have two instances running at the same time. what do you think about this solution? btw, you might find latest netbeans ebuilds at http://git.overlays.gentoo.org/gitweb/?p=dev/fordfrog.git since 7.0, netbeans is split into ebuilds by clusters. i would prefer to implement this feature first on this version and then if there would be any interest or need, we could add support for older version(s) too. in fact if the format of the xml files is the same, it should be pretty easy. we just would have to pass slot number to the script to tell it for which version we want to grab and write the changes. also, i wanted to ask you, because you have more experience with this, whether it is possible to replace in netbeans ebuilds bundled documentation with the system ones (like for junit, swing-layout etc). netbeans bundles documentation in zip files and i would like to replace it with link to unpacked documentation, but i do not know whether that is possible and how to make it work. any idea?
Andreas I'm not quite sure what to do with your report so I'm gonna go ahead and close it. If you're still interested in implementing this feature, with Netbeans 8.0 this time round, feel free to reopen this bug. Signed off by fordfrog.
Hey Patrice, that's fine, it's not as if had the time nowadays to maintain something like this, and if anything, to do this in a sane manner, support for externally managed java libraries for netbeans should be implemented upstream. Thanks, guys!
