NBDTTopicsForANBPlatformConferenceCall

Topics for a NB Platform/RCP Conference Call

Please note, besides issues you'll find in IZ, NB RCP project support is being enhanced, among other things, please see the following and its linked information:

http://wiki.netbeans.org/APISupportInNetBeans7.0

If anyone knows of anything else of interest which may be linked for folks to review before the call please add a blurb and a link. Thanks.

Contents


Questions from Tom Wheeler

  1. What does Sun expect the platform will look like in three years? In five years? Not necessarily meaning what it will look like in terms of UI (though interested in that as well), but instead how will the platform and platform development change in that period?
    1. What things are likely to be deprecated or removed?
    2. What things are likely to be added or emphasized?
    3. What things do you expect developers will like most and least about these changes?
    4. What do you see as the biggest strengths of the platform? What do you see as the biggest weaknesses?
    5. What do you see as your biggest competitor(s) (e.g. Eclipse RCP, Flash, .NET) and how will you beat them?
  2. Most importantly, how can we best help you? Are your biggest needs:
    1. Documentation
    2. Evangelism
    3. Tools support (e.g. API Support)
    4. QA/Testing
    5. API review
    6. Answer questions on mailing lists
    7. Other things?

Questions from Wade Chandler

Tom Wheeler covered most of what I planned to ask in regards to what we can do for you. I'll try to hit on things I feel are important from my perspective as well as what I have heard from others.

  1. Priorities of uses of NB RCP
    1. What priority does Sun place on the NB RCP as a tool for 3rd parties?
    2. What about Sun itself. What priority does Sun place on NB RCP for other Sun projects outside of being the base for the NB IDE? It is good stuff which can make other applications better. Does Sun management understand NB RCP? This would be what you can do with it, its power, and what it can mean to NB and Sun at large?

      The NB RCP/platform can generate major interest, and does for all those who find out about it. It is obviously good for business, but first you have to understand that point and why that is. Then you need to understand that we need to have it marketed better and we can't do it by ourselves. Too, if you grow it you'll almost certainly gain partners to help maintain the different pieces if we look at Eclipse as a model.
    3. In general, I think if Sun would really get behind NB RCP as much as JavaFX and some other things, they could really take the market lead in different areas. The time is now per what many of us are seeing on the lists and in our channels. At this moment, per the time being at hand, we really need a good push, commitment, and an understanding from Sun, on different levels, of what we (you and us - the rest of the community; not just the NB community) have in the NB RCP/Platform, and where it can go. I have seen others than myself express this feeling about the time being right and what they see folks talking about with regard to the NB RCP. It just needs that nudge.
  2. JavaFX
    1. Have there been any discussions of low level NB RCP JavaFX support? This would include things to make it easy to directly use JavaFX views in NB such as some kind of a JavaFXTopComponent and similar support? A combination of the NB RCP and JavaFX would be extremely appealing to many types of application developers.
    2. JavaFX is cool, but it doesn't have the modular capabilities in the NB RCP yet. Too, in most enterprise or tool set environments, at least considering user input methods such as a keyboard and a mouse and the systems today not reading brain waves to move around the UI, the UI components found and used in applications let users who are more interested in the data versus some cool graphics or media edit that data quickly without moving from their home keys. NB RCP, with the different things it supports, is great for enterprise applications.

      I envision JavaFX being useful in those type environments/applications for things like things like embedded media and fancy color pickers or other unique user components when needed. This wouldn't be the main use case for those type applications however, but certainly when needed would be great.
    3. I can imagine different cases where someone might want an entire JavaFX based user interface with the NB module system underpinnings and utility APIs. Even a game engine could be created on top of such a thing. That is another approach which leads into a more abstracted visual representation in the NB WindowManager which I'll talk about later.
    4. Folks may want to use JavaFX in other invented ways embedded in Swing APIs or APIs such as the NB Visual Library where the graph nodes could be JavaFX based animated components. That would be a VERY powerful thing to have, and would draw developers.
  3. Different platform profiles, and has any real thought been given here? - This would be something like a mobile, desktop, and web profile versus the singular profile we have now which is strictly desktop. I say strictly desktop, but not necessarily true, one can create service type applications with NB RCP fairly easily by excluding certain things, and they can also create web based module systems, but it isn't easy, and Fabrizio can enlighten us all on that topic. Either way, all these things would make NB RCP a one stop shop for full application architectures and make it impossible for folks to ignore.
    1. Mobile RCP - This would technically be a set of profiles. I'll mention two I have in mind below.
      1. Mobile RCP CDC - Works for more enabled devices such as the iPhone, Windows Mobile, embedded Linux, etc.
      2. Mobile RCP CDLC - More for phones or other small devices with limited support.
      3. Either way, for a real mobile solution we need a good mobile JVM. I don't see where this would be completely outside of the NB groups possibilities. It would be a good project which could be used and companies would purchase support if it were done right. I point to SuperWaba as a perfect example. It is awesome stuff. Legal issues of VMs and all put aside, maybe build it to supprt SuperWaba, but there are licensing issues there, so it may be we need another JVM which is easy to
        1. Include inside of a prepackaged application with on the needed footprint to output an actual native application for certain types of devices etc and make it easy to port if needed. This would mean the Java classes and the JVM become embedded inside of an application which helps with the deployment model on certain devices. Not all of them need this, but devices with no JVM really do, and this will be a good way to make it more successful.
        2. Install separately as a system component on systems where it makes sense such as embedded Linux, Windows Mobile, others.
        3. Have a good extensible emulator API to support it in the JVM.
        4. Have good levels/subsets of Swing support
        5. Hava JavaFX support
    2. Desktop RCP - This is what we have now in the RCP. Easy enough to make system services etc, but that could be easier as well, and I'll get to it
    3. Command Line RCP - This is pretty self explanatory.
    4. System Services RCP - This would easily enable one to create a service style application in different OS. Make it extensible so that folks can enhance it to support different operating systems if needed. Essentially it would:
      1. Generate hooks to be installed into /etc/rc.d for Linux
      2. Generate service wrappers for Windows, both 32-bit and 64-bit I suppose
      3. Allow for simple standalone server type applications. These can be run manually from the command line or both manually and tied to a service.
    5. Web RCP - These would be modular applications which run inside EAR and WAR web applications. Then modules can be added to these applications and removed from them etc. Different frameworks such as Wicket, the Google GWT, Struts2, and JSF1/2 could be supported.
      1. It can be extensible so that other vendors can hook their own technologies into it and design other IDE support for it
      2. It can those four frameworks above built in, and could support Dojo, Yahoo UI, and other JavaScript libraries as needed (jQuery is another)
      3. Make it easy to embed applets for special remote views
      4. Make it easy to operate against the backend with a Java Web Start enabled NB RCP desktop application. This would be done with different remoting capabilities such as those in Spring, JPA, or remote EJB. That would insinuate making sure those things are easily supported and work with in the NB RCP.
    6. Applet or Java Plugin RCP - This makes it easy to create NB RCP based Java Applets when needed. I know Fabrizio just had a request from a customer for such a thing. Too, Applet support and projects needs better support in the IDE as a whole.
    7. Distributed RCP - This may touch on different levels of the other profiles. It would be something with different sub profiles such as
      1. SOA
      2. Cloud
      3. Jini (Apache River)
  4. More Abstracted WindowManager - The current WindowManager is purely Swing in nature along with other aspects of the RCP. If it were to support generics it could be better used to support the above mentioned profiles. For instance:
    1. WindowManager.getMainWindow(T)/WindowManager.getDefault(T)/something similar - Could allow for any type to be returned from an implementation or some type of specializations for different profiles.
    2. TopComponent - This could be some kind of an interface or class abstraction not directly dealing with Swing components. For backward compatibility TopComponent itself could possibly be unchanged, but some other interface such as ITopComponent could be used, and then AbstractTopComponent could be used to allow new implementations to be created, and TopComponent as it is now used could be returned from some of these methods to keep it working essentially the same. That or a lot more code would have to be redone.
    3. Either way we look at it however, much code would need to be refactored as it relates to TopComponents, and other aspects of the NB system, at least at first glance, but if enough support is behind such ideas surely we can split up different aspects to be reviewed in the context of a larger review to build a report on what it would exactly take to make it possible. Then we can get others from dev@openide to help out with the review and offer input from their current implementations to see what headaches we are really talking here. This gets back to the question of what we can do for you. It may be to find out good information which can be used to make better judgment calls or to get some real work from the community all we need from Sun is some folks to help manage community efforts to get some things done and perform some delegation to those within pools of parties interested in particular domains and issues, and this reaches outside of this single context of the WindowManager; think about it in regards to everything discussed on this page.
  5. OSGi Support - I don't think it needs to be the module system as the NB module system lets NB move when it needs to, but RCP support for OSGi bundles would be good, and go a long way to getting through some folks cob webs and perceived barriers for NB RCP. OK, so now they can use OSGi modules. They can now use some 3rd party libraries, and will find out they can't use Eclipse or other OSGi based modules which have specific dependencies, but at least they can't claim that as a reason to not use NB.

    Too, don't advertise the fact that OSGi bundles are not the main NB method for modules as that really would have no meaning. All one needs to know is they are supported and will be running inside an OSGi container. Too, for any given NB RCP library which can be a standalone OSGi bundle allow it to be exposed that way so it can be copied into other systems. Modules will have to be exposed that way anyways for other OSGi bundles to have dependencies.
  6. Documentation Documentation Documentation (slightly similar to communication...) - Different modules don't have their documentation linked to the main JavaDocs. This would include the Visual Library. This needs consistency. The perfect place is the JavaDocs. Other documents can be linked to from the JavaDocs including tutorials and other information.

    A good look needs to be taken at the fact that different folks over different times, a good number of them, have mentioned that the NB RCP documentation needs to be better; some have recently cited it as a concern about the NB project. This documentation, and linked documents from it, need to be able to be downloaded as a unit and built in NB builds. Obviously something like the NB Wiki may not be able to be included, but most of the other developer documentation should be able to easily be included and linked into the main documentation; this should not preclude NB Wiki or other web resources from being linked to from the JavaDocs or other documents included with them.

    It would be nice if this main documentation were able to be used in the NB help system. Too, it would be nice if the NB help system, Java Help, were updated, and a sub-project of NB could be a better Swing web component taking code from FireFox/Gecko to use for its rendering and an upgrade to Java Help.
    1. NB Help System Upgrade - There are different issues with Java Help. That doesn't mean that Java Help is inherently bad either, but more indicates it needs some tender loving care. Part of that tender loving care really needs to be a new Java web browser component. This component could also be used by JEditorPane and other pluggable components in NB to make the user of HTML even better.

      This could all be a sub-project of NB if management can get the resources to help out. I'm sure there are 3rd parties who believe such a web component would be great for Swing at large even outside of NB. I think the goal of using FireFox/Gecko as a reference point to keep up with for the code would draw some interest as well. So, this component and taking on updating Java Help to bring it up to parity with the MSDN help viewer and other tools, taking good ideas from different systems such as Gnome Help, KDE Help, MSDN, etc, would make it first class.

      Too, if it had the ability to include things like Flash and other objects on different operating systems and embed JavaFX then that would provide immense power which can be incorporated into linked in documentation and show that information. Obviously security and other things will matter as they do in any web browser, but such a tool kit would help Java at large a lot.
    2. NB Help Assistance - This is not just limited to the ability to have some kind of a character or mascot such as Cubie ( maybe an NB mascot :-P ) who can show new folks around the IDE or an RCP application, yes I'm thinking the whole thing be pluggable/extensible, but can allow for the help system to integrate cues the link to overlays and other views with video and different media through out the system; this media can be included at install, a separate installer, or linked to from different sources on the internet (obviously limited when a slow or no network connection exists...shouldn't break, but should fall back to some tolerable default message etc).

      So, lets say we are opening an NB RCP based application or the NB IDE for the first time, or any number of times until we turn off the assistance or it times out (that's a possible good feature), then we see different cues and message balloons etc which can offer us ideas and guide us through using the system. Cues can have rollover capabilities and show previews or videos directly, or they can give us just enough information so we know what clicking on the cue will mean; different cues can do different things as needed. Maybe we click on the cue to get the full message, and the click again to go to the content or click a link at the bottom of the opened cue message.

      So, the cue can be a rollover overlay video and tutorial, or it can be a message that an overlay will pop up or another view will open, or it can offer to take the user to a web page. All cool features than can be supported by JavaFX and an updated Java Help and new web component.
    3. If needed, some of the APIs could support heavy weight components with embedded JDIC web browsers. I personally favor having a pure Swing control which can be embedded and used without OS specific support, but if needed such an API would be good for different things such as RCP applications. I would think this would be secondary to the things mentioned above.

Questions from Fabrizio Giudici

  1. About OSGi support (both technical and "political")
  2. What can be realistically be done to remove useless dependencies in "headless" scenarios

Questions from Antonio Vieiro

  1. How can we report weaknesses (in docs/features)?
  2. Are there any specific needs regarding documentation? Which ones? Shall we make a mechanism for you reporting them to us?
  3. What are the planned features for NetBeans RCP development?
  4. NetBeans RCP in the current economical situation: partnerships, consulting, training, development outsourcing.

Few random questions from Kristian Rink

  1. OSGi support vs. stronger "promotion" of an alternative component model (NetBeans modules?), and technical reasoning for that?
  2. Dealing with Eclipse predominance as an RC platform seemingly caused by ...
    • ... the vast set of "big names" in the Eclipse Foundation (maybe by stronger inclusion of "NetBeans Partners" possible?),
    • ... the wide-spread adoption of Eclipse RCP / IDE at universities (at least to be seen here in Germany -> i.e. by inclusion of Sun Campus Ambassadors?),
    • ... a set of interesting features available to Eclipse users so far lacking(?) viable alternatives in the NetBeans world (XText, OpenArchitectureWare, AndroMDA, RAP/RWT, to name a few)?
  3. Ways of drastically easing adoption of NetBeans RCP not just for application developers but also for those likely to contribute given plug-ins (in example to add some language, framework, tool support to NetBeans) by providing - more documentation? quickstart materials? more templates i.e. for "add a new project type to NetBeans in five minutes"?
  4. Ways of helping enthusiastic NetBeans "evangelists" (like the Dream Team ;) ) spread NetBeans adoption and generating a perception of NetBeans being a truly strong open-source project with a vivid community (both in terms of support and of developers)?

Questions/Comments from Toni Epple

  1. Companies I've been talking to have constantly been complaining about the lack of documentation compared to Eclipse RCP. Existing documentation is perceived to be coming from some very dedicated people inside sun only. This is perceived as a lack of interest of Sun in NB as a platform. Companies are afraid of incompatible changes or a stop in further development.
    1. Given that, how many resources is SUN assigning to NetBeans Platform documentation?
    2. How about Sun putting some NetBeans engineers fulltime on documentation?
    3. How serious is Sun really about the NetBeans Platform?
    4. What additional ways are there for SUN to show their commitment and interest in the platform?

Questions/Comments from Varun Nischal

  • Antonio raised a query on "Organizing NetBeans Tutorials" based on comments written to Fabrizio's blog.
  • Lot of brainstorming took place, Patrick and Geertjan were actively involved from Sun side. However, there has not been much discussed afterwards the way we thought of.
  • As this call is focusing on RCP related queries,
    1. What should be done about the brainstorming that took place as stated above?
    2. How can we provide more coverage to the community-contributed docs (See Related Links) on RCP Learning Trail?
  • Related Links
    1. Tutorials
    2. Tips & Tricks

Questions/Comments from Sven Reimers

  • Regarding the future of the RTC and the RCP
    1. How does Project Jigsaw (Modularization of JDK) effect the NetBeans ModuleSystem?
    2. How about using the upcoming real Filesystem API of Java 7 (should make listen to file changes much more easy)?

Questions/Comments from Anuradha Gunasekara

  • Why not Building trust on 3rd party to provide features than try to build everything in-house (Support 3rd party projects)?
  • OSGi at low level (running Netbeans on OSGi than try to embedding OSGi to Netbeans container )
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo