A list of further development of apisupport in NetBeans 6.7.
Enhanced Configuration of NB Platform Applications
More in Enhanced Configuration of NB RCP Projects. Probably the most asked for improvements. Basic requirements are:
- Ability to reuse modules (suites) in several applications (or even in other suites in more complicate setups)
- Ability to further extend deployed NB platform app by 3rd-party modules
- (tomwheeler): ideally source and javadoc associated with original platform and these 3rd-party modules would be carried through to the new platform that this creates. In other words, it would be extraordinarily useful if one could start with a base platform and some number of additional modules, associate source/javadoc with that platform and all the additional modules, and then be able to build a new platform binary, plus optionally build source and javadoc archives which developers could be associate with that platform binary in their IDE. This would allow them features like debugging and code completion to work with extended platform applications.
- Support such enhanced configuration in UI
This can be achieved in a number of ways:
- Just specifying several applications within one big suite. Can be done without changing the harness, but probably wouldn't support #2.
- Use existing suite-chaining technique. Also probably doable without changing the harness and not including #2, it also only permits linear inclusion of whole platform in another, bigger one.
- Enable suite-to-suite dependencies and split suite project into two separate types - suite project (cluster, modules, platform, depended on suites) and application project (branding, included clusters/modules, set of suites). Probably tricky to retain backward compatibility, solve dependencies on different platforms, etc., also adds another type of NB project to current 4-5 ones.
- Maven NB projects may support such configurations by default... (?)
- 83088 (target platform to include ext. clusters), 125522 (programmatic installation of NBMs into platform), 124910 (customized platform distribution)
- UI: 67868 (UI for jar-excludes), 61681 (UI for multiple JARs in wrapper), 122821 (transitively include missing modules into plaf.), 135247 (showing runtime deps), 148986 (icon branding UI), 64618 (VM args in properties dialog), 147525 (props. dlg. for modules in suite cfg)
- more (if time permits): 65565 (friend dep UI), 141335 (Prop. > Build > Documenting UI), 70883 (Suite branding UI), 61227 (broken NBM refs), 70894 (let lib wrapper use built JAR from J2SE prj)
Other info: Current API Support Spec
Visual Editing of NB Platform App UI
Here NB Platform as well as Eclipse fall behind Visual Studio. This includes:
- WYSIWYG editors of main menu, toolbars and window layout of application as a whole. <This layer in context> node in project window already shows relevant data, but lacks the UI part.
- (tomwheeler): hopefully this means that the visual tools will allow one to easily set the existence and position of the menu and menu items (and also toolbars and toolbar items) as this is very tedious to do manually and the "This Layer in Context" visual support is buggy.
- (tomwheeler): It would be ince if this visual support allowed for the creation of new modes as well.
- Adding actions and windows to modules in the context of the whole app, i.e. developer sees directly where his contribution will appear
- Renaming, rearranging and hiding of actions and windows in the branding layer. Gives application developers more control over UI layout including ability to create truly empty application, i.e. not having Navigate > Go to line... menu item by default.
- Visual view / editor of module and cluster dependencies - not related to application UI, but also requeste
- (tomwheeler): It would be very helpful if this support also specifically allowed for setting the title bar text. Developers commonly ask how they can "change the number" (build number) on their app's title bar, so ideally the customization dialog might have a textbox for "Title bar text:" and a corresponding checkbox which says "Include version number in title bar?"; if checked, this could enable an additional textfield which allows the user to set the netbeans.buildnumber property. In a perfect world, this build number could optionally be overlayed on the splash screen, but this is probably asking too much.
All necessary data are already present, most of the work would consist of UI only.
Persistence Support in NB Modules
Also often requested, might be easy to do - there are templates for entity classes, etc. in J2SE projects, NB bundles Oracle's JPA implementation, TopLink, and Hibernate.
Related issues: 128643, 123217 (New Entity Class, Persistence Unit, ...) Other info: Best Practices With JPA And BeansBinding, http://www.netbeans.org/kb/60/java/gui-binding.html
- Rests from 6.5, nice to have, etc.: 141246 (CoS), 73741 (Remove unused deps), 71055 (lib. wrapper title from JAR)
- Service and Layer Entries via Annotations (Jesse's initiative): 147393, 149136, 150447
- More wizards: 147525 (Navigator provider), 84945 (Palette items), 65627 (modes - probably WONTFIX), 70891 (Code Completion provider)
- Add module deps issues: 70598 (show descriptions), 69574 (forbid module deps. cycles), 70258 (allow adding excluded module's dep), 71051 (cluster filtering), 70775 (match case), 71054 (cp extensions)