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.
I noticed recently that 7.1 will not support visual editing of the Swing Desktop Framework projects. I can see deprecating the use of the framework, but ripping out the support for the framework is pretty brutal and disenfranchising to developers who, trusting Sun and the NetBeans team, developed many applications using the framework. Why is it being ripped out when it worked fine all these years? If you want developers to switch over, please provide a migration tool to convert the projects rather than just stopping support for it. Please reinstate support for this framework and also fix the bugs in 7.0.1 perhaps resulting from preliminary changes for 7.1.
Please, do not abuse bug-tracking system for such discussion. There are various mailing-lists that you can use instead: http://netbeans.org/community/lists/top.html
This is not an "abuse" of the bug tracking system. It is an attempt to track and force consideration of support for an important feature that was unceremoniously dropped from NetBeans 7.1 with, as far as I know, zero feedback from the community. I've changed this to "enhancement", but it is really a regression. I will also post to the discussion list and refer to this bug.
Created attachment 112830 [details] NetBeans disclaimer assuring user that its OK to create a Desktop Application Here is the disclaimer in NB 7.0.1 assuring the user that it is OK to create a new project. Notice that it does not say that your project will not be supported in future releases just that no new development will likely occur. (Although there is an open source project that is continuing development of the core library.)
I completely agree. Our company has developed hundreds of forms using SAF in several systems. The decision to remove support for it means we will not be able to move to Netbeans 7.1 or beyond. Note that we only used SAF because it was promoted by Netbeans. At the very least, NB should provide a means for converting existing SAF-based forms into "regular" Swing (remove the dependency on SAF and use normal property files etc.) A much better solution would be to retain SAF support. The code is there already, how difficult can it be?
IMO it makes no sense to support creation of new projects with a dead framework. I do agree that I don't see the need to remove the GUI editor to edit current projects. Maybe an Inspect and Transform action to remove the dependencies on SAF will do the trick. Is the GUI editor made to work with SAF? I don't think so. Hopefully is just a couple of minor template changes. Converting into NetBeans platform is not a straight forward thing, not saying that is hard, just that is way too dependent on the application for an uniform conversion. There's a tutorial to get you started: http://platform.netbeans.org/tutorials/60/nbm-porting-basic.html If they won't continue the support this is another area the community can take over.
An Inspect & Transform that removes dependency on SAF and replaces them with straight calls to ResourceBundles would be good.
*** Bug 207259 has been marked as a duplicate of this bug. ***
Hello, I am marking this issue as "resolved - wont fix". Currently there is no plan to implement this and there is nobody we are aware of who would continue supporting the framework. Some of the most frequently asked questions are answered here http://wiki.netbeans.org/SAFSupport We are trying to support technologies and frameworks that are alive. SAF never matured - the JSR was never finalized. We had the support for it since at the time when someone worked on the JSR we believed it would become part of the (java) platform. Unfortunately that never happened and the JSR was abandoned. Please don't reopen unless you have intention to work on this support. Thank you for your understanding.
I disagree with your assessment of the Swing Desktop Framework. I've used it to create many production small to medium sized GUIs with great success so it was quite mature and actually the NetBeans platform team could learn a few lessons from the usability of the APIs and the tight integration with the GUI builder. We were led to believe by Sun and with all the fanfare at JavaOne that this framework was to be integrated into the JDK so many adopted the framework. This bug has 10 votes which is higher than many of the other bugs that have been addressed. Did you all even try to work together with these guys who have continued to improve the framework after the original prime developer left Sun to work at Adobe? http://kenai.com/projects/bsaf/pages/Home I don't believe they have it integrated into the GUI builder though and now that you all have ripped out the infrastructure to support the framework, it may be too difficult to recover. Do you think the NetBeans platform is lightweight enough to support applets and other lighter weight applications? If not, what is the alternative besides cobbling together your own framework?
I don't use the SAF myself (neither I use the NB PLATFORM [too bulky, complex and heavy], I do reinvent the wheel myself everything with every time with my own "framework" (because SAF was incomplete first, deprecated then, and nonexistent now), BUT I do agree 100% with wobster. Last year I actually had to work once on a project that used the SAF (before NB 7.1 of course, otherwise its abrupt [and unnecessary] drop of SAF support would have made a nightmare) and I updated it with the BSAF libraries, that I saw were actively mantained (I got a 2-day-fresh released version) so, again, I second wobster on this topic: there is a better alternative than dropping the feature altogether.
Reopening for more commentary by the community and developers on the posed questions.
I am currently working on an XSLT file that, when applied to a .form file that used the SAF, converts it into a plain-vanilla Swing form that the new designer can open. You can use it in conjunction with the style task in ant to convert all the forms in a project. Primarily what this does is: replace the use of the ResourceMap and ActionMap with standard use of ResourceBundles, and a special Action object that reads the same properties from the form's properties file. Once the .form file is converted, you have to open the form in the designer, make a small change (like resizing it a bit) so that the "protected code" gets regenerated. All this is still a work in progress. I'll keep you posted.
Created attachment 115454 [details] XSLT file to convert SAF-based forms into non-SAF-based forms This archive contains 3 projects (maven based). One contains the actual transformer and supporting code, the others are just a sample SAF-based form and the same form after conversion. This code is being offered without warranty etc and is open source. I know it's incomplete - basically it works on the forms I tried it on so far. If you improve on this please share it back. The core of the transformer is an XSL file which performs the required transformations so that ResourceMaps and ActionMaps are replaced by calls to the resource bundle, or non-resource values, or instances of a new "MBAction" object. In the end you get a form that you can edit with the new Netbeans 7.1 form designer. To use, edit the supplied sample build.xml file to provide the paths to a source and destination project (the destination should be a copy of the source, it will get the form files replaced). Then, load the forms in the designer and make a tiny change like resizing it, to regenerate the protected code section. NOTE: Take backups of your stuff before trying anything, since this will overwrite the .form file each time it is run.
Thanks rcasha. I'll give it try. Has anybody ever created an applet using the NetBeans Platform or programatically created an instance of the GUI from another Java process such as MATLAB (not using exec)? The reason I ask is that if NB platform cannot be used as an applet, there needs to be an alternative to avoid forcing the developers to cobble together their own frameworks (as I have done). SAF seemed to be a good alternative when lightweight frameworks are required. Alternatively, maybe the NB Platform could be made easier to deploy as a JNLP-based applet?
The MSGS variable referenced by the transformed can in most cases be a regular ResourceBundle, as follows: private static final ResourceBundle MSGS = ResourceBundle.getBundle(MBAction.classBundleBaseName(Test.class)); (where Test.class is the form)
We have built more than 10 corporate applications based on SAF. They are in production and it would be a big pain to refactor them one by one. So far, SAF was the framework suggested by Netbeans when creating a desktop application. I'm a bit shocked that Netbeans promoted this API for so many years (even though the JSR was not more finalized than now), and suddenly decides to drop its support in Matisse. How can you make a U-turn so quickly (I mean : between a 7.0.1 promoting SAF and a 7.1 dropping its support in Matisse)? If you were so unsure about the future of SAF, why was it still the default API in Netbeans 7.0.1? We, as Netbeans users, tend to trust you on your choices and suggestions. I feel like you stab us in the back by changing your mind so quickly. It puts us in a very difficult situation, because we can not upgrade Netbeans any more, even if we still encounter bugs with version 7.0.1. We suffer for example from this bug : https://netbeans.org/bugzilla/show_bug.cgi?id=167208 . It prevents us from building properly with Maven 3. This bug is fixed in 7.1, but not in 7.0.1. I had to backport manually the fix in 7.0.1, and I'm trying to create a local update center for that single purpose. But that's not a long-term solution. Oracle should at least propose an official solution to migrate existing SAF applications
Created attachment 116213 [details] Patch to make original swingapp module work again The attached patch appears to make the swingapp module work again in (7.2) trunk. Without much knowledge of SAF I cannot say if all features are working. The only thing (that I know of) blocking it from working as a binary plugin to 7.1 is a single if-statement in the form editor that explicitly refuses to load a form that uses the resourceKey attribute. The patch easily corrects this logic error (by checking for the existence of SAF support first) but the change would have to be backported to e.g. 7.1.2 in order to let 7.1.x users work with the plugin. Of course the patch is only valid insofar as the form editor continues to maintain its semi-private APIs like ResourceService which are only used by SAF. Only developers of the form editor would know whether these are a serious maintenance burden.
I think there's a rather critical point that needs clarification. From my view, the SAF was more strongly supported than the Netbeans Framework is now. Because of that, there's no way that I want to jump on board another GUI technology Netbeans is pushing, considering that it might once again get dropped in one release without any warning an end user (me) will get. I'm a Java GUI newbie. I never ever realized that the SAF was different from a "normal" Spring application. I never got any warning when opening those application that I was using a deprecated technology. Sure. I admit that this is open source software, I haven't paid for it, and I can't demand a feature. On the other hand, there's no way I want to even touch the Netbeans Framework without something stronger than some nebulous hope and belief that it probably won't die the same way, and with just as little warning.
*** Bug 207617 has been marked as a duplicate of this bug. ***
I think is a big error remove support for jdesktop in netbeans. I'have a lot of program with jdesktop and is not right I can't upgrade my Netbeans to work with my old programs. I thing jdesktop is a good platform to develop simple desktop application (use of netbeans enviroment is excessive in many situatuion) and I like to use again in future. The answer I find in Netbeans site is 'use 7.0.1 for your old application' is not an answer: is not possible i can't update my work enviroment for the next years. Netbeans 7.1 must support jdesktop like 7.0.1, LIVE TO THE USERS the opportunity of use or not this feature for the next code. Thanks.
I grew up with computers like C64 so i'm an old-timer, a dinosaur one might say. "Incompatible" was the #1 reason i've seen marked-leaders vanish. Sun used to be compatible. Oracle? Well i don't know anymore! You don't "wow" me, i'm afraid.
The sudden lack of support in 7.1 for the Swing Application Framework (JSR 296) came as a shock and a major disappointment. My company has a number of large, important applications that are based on the SAF. In previous versions, when using the Create Project wizard, if the user specified "Java Desktop Application", the application that NetBeans created was based upon the SAF, and there was no warning of any sort that (a) the application skeleton that had just been created by NetBeans was using a deprecated framework, or that (b) NetBeans would possibly drop support for it in the future. It would be one thing if NetBeans wanted to change the application skeleton created by the Create Project wizard to one that uses a different framework. But it's something else entirely for applications that had been created by the wizard in previous versions of NetBeans to suddenly become uneditable and unrunnable in the current version! We find the decision to suddenly rip out support for the SAF from NetBeans to be outrageous, and our confidence in NetBeans for the future has been shattered. Recoding our projects to use a different framework is not a practical option for us in the short term, so we are left stuck using NetBeans 7.0.1. As regards our longer term plans: Unless NetBeans restores support for the SAF in its upcoming release, we will probably abandon NetBeans altogether, and switch to Eclipse's Windows Builder for our current and future GUI applications.
NetBeans is losing quite a lot of user base because of the way it introduces technologies, make developers adopt them, and then drop them without much warning. First the Visual Web Project (WYSIWYG web designer for JSP, etc -- ever so useful for the "R" in RAD [Rapid Application Development!] and for previewing your work) is DROPPED: thousands flee to Eclipse. Then, from 6.9 to 7.0 JavaFX visual designer is REMOVED: again, thousands of confused (and pissed-off) devs flee to Eclipse. Finally SAF is abruptly removed too: yet another flock of devs migrates from NB to Eclipse (or IntelliJ Idea, or whatever). What's up with all this demolition of Visual tools? It's not that nice to write tons of boilerplate code, reinvent the wheel all the day and be as productive as a drunken sloth, just because the best tools are deemed "unnecessary"! What will be removed next so that the last batch of loyal NB users will migrate to Eclipse? I'd suggest discontinuing the Matisse swing editor and having the programmers design UIs only in bytecode... "But hey, there's the NB Platform and blah blah blah" ...who cares? Not everyone needs all that massive overhead and not all projects are behemoth-scale modular enterprise projects that can take advantage of the NB Platform. There is a HUGE slice of the software market that consists of small to medium sized applications, where being forced to use the NB Platform would just be unnecessary, unproductive or even worse... bloating the size of your deployed applications and adding artificial complexity at all costs to things that could be so easy, fast and efficient. I really don't understand why there is such a couldn't-care-less attitude towards maintaining backwards compatibility to preexisting development models.
I second commenter #23. The Netbeans platform is no replacement for the SAF, and if the idea is to push it into every design, it is a very bad idea. Some people will complain but many will just abandon netbeans silently. Put it back, and add a template for a simple gui-based application with an option to make it an applet, and an option to enable web start support. We used to have that.
Here is another one trying to understand what happened. Stuck with 7.0.1 (and subversion 1.6) in a situation where migration to another platform is not possible for at least half a year. Very funny. I can't believe you just removed it. No deprecation warnings, nothing. How about Beans Binding support (JSR 295)? Will it be removed in 7.2?
> "But hey, there's the NB Platform and blah blah blah" ...who cares? Not everyone needs all that massive overhead and not all projects are behemoth-scale modular enterprise projects that can take advantage of the NB Platform. There is a HUGE slice of the software market that consists of small to medium sized applications, where being forced to use the NB Platform would just be unnecessary, unproductive or even worse... bloating the size of your deployed applications and adding artificial complexity at all costs to things that could be so easy, fast and efficient. In my case, I find the Netbeans platform to be "slow and bloated" in terms of writing code and how much I have to write. For me, execution time is unimportant, but most of the apps I make are something like a small calculator. A moderate amount of backend code and a few simple fields all plugging numbers into one function call. I could be wrong, but the Netbeans platform seems HORRIBLY suited to that. I think of it as having too much that must be extended. My apps are basically shell-scripts with a shiny GUI, and the "replacement" is horrid. You might as well try replacing a spreadsheet app with the Netbeans platform. Sure, Java gives you a lot more power, but that doesn't mean it's a good replacement for a spreadsheet. Both fill entirely different roles.
any offical plan to fix this bug in 7.1x? or 7.2?
I think removing SAF support all of a sudden without a migration tool is an extreme example of irresponsible behavior from a great IDE like netbeans (Are you guys joking? Do think that you are building something that should not be taken seriously?). As SAF was working well so it could be there as an alternate options for developing GUI, may be with a 'strongly unrecommended' warning message for new projects but it should have the support continued as long as it does not become completely incompatible with JDK x (a future JDK release). So either provide an easy migration tool (which will best) or continue supporting SAF, otherwise I am sure thousand of developers will lose their faith on netbeans (If that is the intention than I have nothing to say).
This is completely ridiculous. When did Netbeans stop caring about it's developers? We have tons of projects and thousands of SAF based forms! You just take something this vital away from Netbeans overnight? This is totally unacceptable. I'm extremely disappointed with Netbeans. Please consider reversing this very serious mistake.
@joey20srdet and whoelse is interested: Try https://sourceforge.net/projects/nosaf/ this is a UI for Ramon's XSLT stuff attached to the bug avove, and contains one or two additional fixes. The main problem you have are the @Actions, which this tool converts rather nicely into references to a JavaBean class that derives from AbstractAction. Cheers, Uwe
I am very interrested in the patch solution proposed by Jesse Glick... I am using NetBeans on Windows platform and I have no idea how to do that patch... Maybe some kind of tutorial will help.
Is the SAF NetBeans support in the core or a module? As a module we could improve it and everyone could install or not. I'm not a NetBeans core developer, but I've been contributing to the project reporting bugs and statistic usage. As everyone here I have projects developed with that important feature and now having to work with two NetBeans versions:NetBeans 7.0.1 and 7.2, making me an unproductive and error-prone developer. Is there anything we could do to help on this issue? Regards, Gilberto
(In reply to comment #32) > Is the SAF NetBeans support in the core or a module? Mainly a module, but it cannot function without a three-line patch in the basic IDE (re-)enabling existing hooks in the form editor; see comment #17.
And what about a project converter ?
We've just spent 2+ years working on a large (150,000+) line Java app based on SAF. I understand some of the reasoning behind the decision to stop supporting the SAF and move to the NetBeans framework. However, it was a BIG mistake to remove SAF support without giving us the tools to migrate to the new platform. I don't even know what is inside the NetBeans platform or what I have to change to get everything up & running. I dont think the "tutorial" is clear at all. I'm perfectly willing to migrate to a new platform, but I need the tools to do so. Why was/is it so difficult to provide a migration tool? In fact, if you very clearly publish the specs, I could probably build a parser/translator to do the job and make it available to the community. Right now, I'm at a standstill. I'm trying to migrate to JBoss AS7 because HornetQ is integrated inside the app server. However, AS7 is unsupported in NetBeans 7.0.1, so I have to either: 1) go back to AS6 and then fool around getting HornetQ configured correctly -not a trivial task on my part -or- 2) Move to NetBeans 7.1.x - but then my application won't work. I tried to build and install the AS7 plugin for NetBeans but as far as I can tell it appears to have a dependency on something that doesn't exist in 7.0.1. So I couldn't build it and I can't install it in 7.0.1. The Eclipse WindowsBuilder option someone pointed out above does not seem practical either - it doesn't exist yet so far as I can see. And what is so hard about building WYSIWYG environments anyway? Microsoft had this for VB and Visual C in the 90's. Sorry to vent, but after working 14+ hour days end on end, to say I'm frustrated is an understatement.
I used the SAF because it was easy to support where we have applications run as both Applets and desktop Aplications. It was one of the reasons to use Netbeans over Eclipse. Since we have applications built using this framework we are force to support them with the older version of Netbeans until they can be converted. The NB platform is to bloated to be an applet. Never received any notification of deprecation on any of the builds until we tried to upgrade to 7.1 only to find that we could no longer use the GUI builder. BSAF is currently being supported so some of the arguments about not be supported are no longer valid. At the very least re-enable the GUI builder to support existing projects, popup a warning about the deprecation. Then NOT providing the ability to build a new SAF, would have been acceptable.
Somebody of the Netbeans devolloper team may answer here about a project converter, please ?
Somebody of the Netbeans developer team may answer here about a project converter, please ?
Integrated into 'main-golden', will be available in build *201206120719* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/f6b194c5da30 User: Tomas Pavek <tpavek@netbeans.org> Log: #204661: leaving door open for the possibility to install swingapp manually
Incredible...somebody is reading our remarks... Even more...somebody is doing something with it. And for that, a big thank you. This is a begining... But why "leave a door open for the possibility to install swingapp manually", why this workaround, instead of just leaving Swing Application Framework working. This is incomprehensible... How do I "manually" install SAF ? A guide ? I hope it will be something more user friendly than "that"...
Created attachment 120741 [details] Follow-up patch (cf. DevFaqExternalLibraries [1]) Looks like a variant of my patch from comment #17 was accepted, so ant -f swingapp nbm from NB dev sources now works - although the license information is incomplete, hence the need for this minor additional patch. [1] http://wiki.netbeans.org/DevFaqExternalLibraries
This is great, I had almost given up on Netbeans. Perhaps someone could post simple instructions on how to get things working (applying the patch etc)?
In addition to all reasons given why the Swing Framework should be supported in NB 7.1, an important point has not been mentioned: Please correct me if I am wrong, but Swing is the best way to learn Java. At least it was for me. And now after coding some 20k lines, having watched the 10 screen casts on the Netbeans Platform API and having flipped through the book, I am no closer to use it in my own projects. NBP has a massive learning curve and is certainly not tempting for a Java newbie. So the Swing Framework should be supported until something comparably easy to use/learn comes along.
The code of the SAF support in repository is now working again (can install, open a GUI form, but not really tested). I have no idea if anything is going to happen with it, but if anybody really needs it, it is possible to build the NBM from sources and install it manually to the IDE, e.g as: $ hg clone -b release72 http://hg.netbeans.org/releases/ $ cd releases/nbbuild $ ant -Dcluster.config=basic $ cd ../swingapp $ ant nbm Note the first step (initial repository cloning) takes really long. The last step produces build/org-netbeans-modules-swingapp.nbm which should be possible to install to the IDE via Tools | Plugins > Downloaded > Add Plugins.
Is it possible to build it with the Better Swing Application Framework[1] libs? Regards, Gilberto [1] http://kenai.com/projects/bsaf/pages/Home
(In reply to comment #45) > Is it possible to build it with the Better Swing Application Framework libs? Would probably be straightforward, but this is something that should be done by BSAF developers. I think the swingapp source module should be moved from nb.org to bsaf.kenai.com for ongoing development and binary release, probably being converted to Maven format since that is what the framework itself seems to use.
(In reply to comment #44) > The code of the SAF support in repository is now working again (can install, > open a GUI form, but not really tested). I have no idea if anything is going to > happen with it, but if anybody really needs it, it is possible to build the NBM > from sources and install it manually to the IDE, e.g as: > > $ hg clone -b release72 http://hg.netbeans.org/releases/ > $ cd releases/nbbuild > $ ant -Dcluster.config=basic > $ cd ../swingapp > $ ant nbm > > Note the first step (initial repository cloning) takes really long. The last > step produces build/org-netbeans-modules-swingapp.nbm which should be possible > to install to the IDE via Tools | Plugins > Downloaded > Add Plugins. The line invoking ant didn't work for me because something ran out of memory. This replacement did work for me: export ANT_OPTS="-Xms256m -Xmx1000m"; ant -Dcluster.config=basic And I'm not complaining about the command being "wrong". It's probably implied to anyone who does any amount of work with ant. It's just here for anyone who's also an ant newbie like me.
Thanks Tomas Pavek, much appreciated.
I am working on Windows and I don't know how to integrate SAF again (sources from repositry, rebuild, etc...) Lets's hope that SAF will be part of NB 7.2 like before or as a module.
Please don't change the status unless you assign this to someone willing to work on it. Thanks.
How is this RESOLVED WONTFIX! This is anything but resolved. Swing support needs to return to Netbeans. The Netbeans developers must not care about their users at all!
WTF??? At least provide an update so that we can support our existing programs with the current version of netbeans! Not being able to start a new project with SAF, is a not such an issue. Not being able to provide support to projects that we have customers using code that we have developed using the IDE will force switching to a new IDE. If we have to manually modify, might as well go to Eclipse.
Hello, resolved wontfix means that there is no NB developer (that I know about) going to fix it. As I said if you find one please assign to him and then reopen. Reopening without anybody willing to do the work is not useful. There are steps described by Jesse Glick in Comment 46 on 2012-06-15 19:54:50 UTC that would need to happen for this to proceed further. Please note that the users who already use SAF can keep using the version of NetBeans where it is present. Please check http://jcp.org/en/jsr/detail?id=296 for status of the JSR 296. Br, David
Agreed. The NetBeans team hears your frustration, but we simply do not have resources to staff this. As such, it is closed as WONTFIX. This does not mean the bug is invalid, just that we won't be fixing it. Having open issues in our bugtracker that nobody has plans to fix does not help anyone. If the community wants to take over this project and provide the plugin on the update center, we are willing to help. But we have no plans to do so.
This enhancement request has 40 votes (in the top 30 of all bugs reported for NetBeans history) and has one of the longest running (6 months) threads on the NetBeans users mailing list discussing this bug. This issue should remain open so that it will not be forgotten. Closing it as WONTFIX does not help the user community. Has this issue been brought up before the Governing Board? I think that most people agree that it was a mistake to rip this capability out before addressing it with the community. Using Jesse's patch, why not make that part of the next patch release rather than forcing the users to patch their local version of NetBeans?
Closing it as "wontfix" doesn't mean there isn't a NB developer willing to take it on, it means there never will be because they won't see it as an open issue and won't see what a major problem it is causing for users. Having open issues on your bug tracker means that there are still unresolved problems. Please don't try to hide this under the carpet, it's a major flaw.
(In reply to comment #53) > Hello, > > resolved wontfix means that there is no NB developer (that I know about) going > to fix it. As I said if you find one please assign to him and then reopen. > Reopening without anybody willing to do the work is not useful. > I'm never heard this definition before. I've always heard of "no one has time to fix this" as "Open". WONTFIX is usually reserved for things that won't be fixed, even if a user offers their time. (In reply to comment #53) > There are steps described by Jesse Glick in Comment 46 on 2012-06-15 19:54:50 > UTC that would need to happen for this to proceed further. My understanding is that this changeset is half the work: http://hg.netbeans.org/main-golden/rev/f6b194c5da30 Now the plugin just needs to be included in the plugin repository. Yes, the steps described in 46 would be wonderful for someone to do, but that sounds like fixing a leaking pipe by replacing every bit of plumbing in the house. At this point, it can still be used for a bit longer, until it either springs another leak, or someone redesigns it. And, even if there's another problem, it won't affect general users, since it is a plugin. (In reply to comment #53) > > Please note that the users who already use SAF can keep using the version of > NetBeans where it is present. > > Please check http://jcp.org/en/jsr/detail?id=296 for status of the JSR 296. Sure, but I find it irrelevant to the point that you don't go from recommending a technology to removing it this fast. If you think having to support a withdrawn JSR is bad, then you shouldn't tell everyone they should use a JSR that's not ready yet. Protip: The Netbeans platform framework isn't a complete replacement for this. It's like saying an SUV is a replacement for a bicycle. True, there is overlap in usage, but it's not a one-to-one replacement.
Hello, I have built the plugin (thanks to Tomas) and made it available as a plugin for 7.2: http://plugins.netbeans.org/plugin/43853/swing-application-framework-support I guess we can finally close this report as fixed. Bela
As suggested in comment #46, I have extracted the swingapp module's history into a standalone repository, converted it to Maven format, and switched it to use BSAF. It seems to work, from what little I know of what the module is supposed to do. You can see the new sources at [1]. I would suggest that 1. Anyone interested in maintaining (B)SAF integration with NetBeans use these sources and the bsaf.kenai.com infrastructure. Perhaps onkentes would like to build binaries from this source and publish to plugins.netbeans.org, or perhaps someone else would like to own it. In the meantime, 'mvn -am -pl plugin package' should suffice to build an NBM. 2. The swingapp module sources be deleted from the default branch of the NB main repo, to avoid confusion. (*) Some notes about the new sources: 1. It uses a new code name, com.kenai.bsaf.netbeans.plugin, both to indicate its hosting point and to differentiate it from the (non-B) SAF plugin. 2. It still includes the wizard warning panel about SAF being deprecated, which could presumably be deleted. 3. BSAF 1.9.3 does not seem to be in Maven repos yet, so the plugin uses 1.9.2 for now. 4. The plugin has impl deps on o.n.m.form and o.n.m.form.nb, which is not a big problem since these expose numeric implementation versions. But it also has an impl dep on o.n.m.properties (not a friend of the new CNB), which is more aggravating since this does not expose a numeric implementation version, so unless and until that is fixed the plugin would need to rebuilt [2] for each NB release. 5. Some configuration could be simplified when nbm-maven-plugin 3.8 is released. (module.xml will be no more, and license.txt could be omitted.) (*) 09bff123568f by mkleint is the only change since the release72 branch point that I am imported; it can only work in 7.3+, and may not even be necessary in 7.3+ if Maven library syntax was kept compatible. A comment in refactored sources indicates what should be changed to use that new syntax if desired. [1] http://kenai.com/projects/bsaf/sources/netbeans/show [2] http://wiki.netbeans.org/NbmPackageStability#Usage_from_external_modules
Fantastic work, Jesse Glick! I've created a issue[1] with that improvement and you have done it. Thanks! Now we need to make it publicity! Maybe on netbeans.org[2], BSAF[3] project site or stackoverflow.com[4]? Thanks again, Gilberto [1] http://kenai.com/jira/browse/BSAF-121 [2] http://netbeans.org [3] http://kenai.com/projects/bsaf/pages/Home [4] http://stackoverflow.com/search?q=bsaf?
What is the difference between these two SAF Support plugins: geertjan: http://plugins.netbeans.org/plugin/43836/swing-application-framework-support onkentes: http://plugins.netbeans.org/plugin/43853/swing-application-framework-support Has anyone tried both and compared them? Are there advantages to one over the other? Thanks, Moshe
I'm a little bit sad about netbeans. Previously we have a pretty large project depending on the Visual Web Pack since Netbeans 5.x until 6.7.1. After 6.7.1, Netbeans suddenly stopped support of the VWP. Now they did the same thing to the SAF. I would say, without the VWP and SAF, I really didn't see any reason I don't Eclipse.
What is the current status of support for 296? I couldn't quite figure out if 'resolved' meant it was working again. And FYI if you don't support me, and the 50 or so applications I developed with it I'll have to a) continue to use the last version that did work to support my apps, and 2) will not write another java application until you do. When java arrived it solved a gnarly cross-platform problem. There are other cross-platform solutions available now, so why use Java? - Yes, it's easy, and I'd love to return to the fold having been one of the earliest (Java 1.0) advocates - but I'll never return if you won't support us in the trenches... So, anybody know if 7.2 supports it again? Thanks, Kurt
It is obviously not fixed in 7.2 Don't understand how anyone can mark it as resolved. My SAF projects won't let me run the designer. To be fixed Netbeans should at the very least: Tell me that SAF is a deprecated feature. It should either be supported or provide a converter The plugins listed in the comments are marked as NOGO
As per comment 204661#c58 you can enable the JSR 296 feature installing the plugin[1] or building it yourself - that's what I did: build it with BASF 1.9.2 api. Thanks Jesse Glick, his time on this work[2]. [1] http://plugins.netbeans.org/plugin/43853/swing-application-framework-support [2] http://kenai.com/projects/bsaf/sources/netbeans/show
The plugins worked great! http://plugins.netbeans.org/plugin/43853/swing-application-framework-support The plugin is marked NOGO because of the uninstall. it shows up in the plugin list inside netbeans as: Netbeans Plugin Development IDE 7.2 (Build 201207171143) Other than that it works great! Thanks,
(In reply to comment #61) > What is the difference between these two SAF Support plugins: > > http://plugins.netbeans.org/plugin/43836/swing-application-framework-support > http://plugins.netbeans.org/plugin/43853/swing-application-framework-support Geertjan's is just built from original 7.2 sources and probably needs to be shut down. onkentes's is also still built from obsolete sources. Someone willing to assume responsibility for this plugin ought to build from the http://kenai.com/projects/bsaf/pages/Home fork which bundles BSAF and is open to ongoing development (I can assign developer status on that project).
*** Bug 217651 has been marked as a duplicate of this bug. ***
SPAM - Removed by Administrator