I think it’s wise. I vote for it ! I’ve used the SDK for a while at the beginning of OpenRTS dev but I switched back to Eclipse eventually. The SDK is still a wonderful tool box and I use it often for many little tasks.
If those tools become independant, or maybe plugins for our favorite IDE, it would be awsome IMO.
But I’m curious : do we have some stats about the abits of the jmonkey users, to know how many are using the SKD to code, as a separate tool, or not at all?
I don’t think these numbers would be possible to gauge. For example, up until recently I left my SDK open all the time… now I’m 100% gradle for my active project and I’ve been able to close it.
Nor does the statistic matter at all, really. If a billion people used the SDK… it still wouldn’t change that fact that no one has stepped up to support it.
It’s a pretty big loss, really… certainly for the first time adopter. When I came back to JME in 2011, the SDK was a quick way to get up to speed and productive. Even gradle templates won’t help with that nice quick feedback cycle that turned a couple hours of poking around into a basis for expertise.
But such is life.
That won’t happen though, at least not from the core team. We want plain old java apps, else people would complain “why a plugin for this ide and not this one” and we’ll be in the same position as with the SDK today.
This is understandable. If users needs and want to, they will certainly be able to contirubte with their own plugin translation of the apps for their favorite tool.
I’m sad to see such a big software to be abandonned too, and I symathize with you guys that have spend time developping it.
I’m also sure this is a natural evolution process of our great engine, and from this important (althougt sad) decision, will born some even more awsome developpements.
Also we hope to bring more contribution to the tools from the community, by making simple applications. But that’s another battle I guess 
On github/bintray, I have a set of tools (asset pipeline for gradle, customisable model viewer, …). I’ll start topics (in user contributions) for each, when back to home.
I’ve always though that separate tools are a better way because of many reasons so go for it :D. This can even encourage people to help on any desired tool easier than helping to anything for the full sdk.
But then PLEASE make sure to provide a good api (i.e. split “libmodelviewer.jar” and “ModelViewer.jar” (the latter is just the awt/swing stuff)), because then we could still use them from inside the SDK and changes to the ModelViewer would automatically keep the SDK intact.
And what will happen: Will it simply be decoupled/unmaintained/not released anymore, or will it completely be dropped as in don’t develop it anymore?
Because since I am now familiar with PRs I might try to improve it once I have the time for it.
IMO we will discontinue dev on the SDK (I mean the netbeans based SDK). At least from a core perspective.
But don’t worry all the PR you are now posting are hardly lost time, The fix you made recently will mostly be used as is in the stand alone apps (specially for the material/shader node editor)
This is really a very SAD day in my life.
BUT, I do understand…
To every one of you that are ‘super sad/upset’… remember that the code is right there and you are welcome to pick it up and fix it, continue it, etc…
“I’m not THAT sad.” Heheh.
Finally I’ll have single instance of NetBeans open instead of two, one normal and one for SDK. Maybe it even will encourage me to find some time to learn NetBeans API and port some code from SDK or standalone tools to version of NetBeans I’m currently using.
I guess my next move is to google how to make intellij idea plugins…
YesI have been waiting for this 
I noticed that quite some effort was bound by keeping the sdk uptodate, but I said nothing, didn’t want to be the hateful eclipse user 
As a linux user I always prefered once simple tool that does one task well instead of a big mess. (and yes I notice the irony using eclipse)
I think you have to play for a licence for this…
There are quite a few doors that this can open. On the plus side it means that users aren’t bound to netbeans (although I do prefer it myself for java) - and also development of tools isnt bound to learning how netbeans likes to play. This does mean that tools are far easier to create in terms of learning curve. As @pspeed said on the slack chat, he can throw out a model viewer in an hour using swing, but doing it as a netbeans plugin is a pain. That summarizes most peoples thoughts with SDK contributions.
However, I have been thinking about this, and it isn’t overly-complicated to create a base-application that accepts plugins directly from github. Sort of an interface application. So you can open a project (or in other words, point it to a jme project) and the material editor and what not will list your materials, or let you create a new one and put them in the correct folder. The plugin interface itself needn’t be complicated at all and provides a one-stop base for all jme tools, with the added benefit of organisation because the app will know about the JME folder structure and whatever else, and you can add/remove/update plugins with very little work involved.
That’s my thoughts on the matter, but it shows that just because one door closes, it doesnt mean it has to be a bad thing. I am quite sure something will be done to replace or improve upon the situation at hand.
As far as I have found, you don’t need ultimate edition. Even if you do that is no problem, since I have a licence (at least something that school is good for ).
Well, I’ve used the SDK mainly for coding now and really enjoy Netbeans. But the level editor - I tried to use it and it was not so good. Good to know anyways, because I won’t invest more time in learning all functions of the SDK then (only the coding stuff). Bad for my tutorial which will be donated soon, but okay - a SDK tutorial turns into a Netbeans tutorial (I can live with that). 
Like Nehon said: You are reinventing jME SDK. Like Pspeed said: You are having separate tools like in libgdx now. “You can’t make an omelet without the eggs” is what everybody understands I think. :chimpanzee_closedlaugh:
So, now for one aspect that is a pain (whether with jME SDK or without): It’s finding a good overview of tools and plugins. There is often stuff that nobody knows and SDK plugins are becoming broken very easily. But the important part is the “that nobody knows”. Which is why we should definitely encourage people to contribute to Wiki pages like this: http://wiki.jmonkeyengine.org/doku.php/jme3:contributions
Thanks for all the good work to the makers of jME and tools for jME,
Ogli
As far as I can see on Github, SDK is not going anywhere and is still being worked on. It’s just that core members won’t work on it anymore. At least that’s how I understand it.
Reading through this thread I’d like to share a few of my thoughts on this matter. Obviously I spent a LOT of time on the SDK and am kind of sad to see it go the way of the dodo but alas, I don’t have time to maintain it so I’ll let the rest of the team do as they think is best. And given the lack of proper support I completely understand this decision.
So don’t take these comments as a “defense” of the SDK or me trying to convince anybody to keep it part of the jME distribution. These are just some (imo) facts around this topic that should be considered.
The SDK hasn’t yet stopped any developments or drained more than a few hours of Kirills personal time for jME coding since my departure - this move is exactly preventing that. Core features and external extensions have been developed at the same pace as they always have.
Any development of an integrated SDK-like application, even if written from scratch will result in something similarly “complicated” as Netbeans / the current SDK, so any ideas like plugins for another IDE, a unified standalone app or similar should be disregarded. Even a unified SPI for jME “editor” plugins - as was thought about for a while in the core team - which would work in the current SDK and other environments (jME-standalone, other IDEs) would result in a set of rules and documentation that will make 80% of people thinking to contribute go “well I can do that with (insert tool/library X he likes) in a few hours”.
With the above in mind, there can not be a similar thing, the best solution would be a few command line / visual tools to circumvent the most problematic things that are hard to do “code only”, a few gradle build targets and the hope that the user can put them together in a way that allows him to make a game.
Some refer to the SDK scene editor as a “Level Editor” but in fact the visual tools in the SDK were just meant as building blocks for actual “Level Editors”, “Entity Editors” and all kinds of similar things. The Terrain Editor being the only real example of somebody else writing such a plugin. I said this a few times already but since jME has no concept for “spawn points” or “npcs” built in there can not be such editors, they would have to be a combination of these concepts (i.e. libraries) and the according editors - something for which the SDK was designed to be a platform.
Also regarding the above, some people might under-estimate what having these tools integrated in the actual build and coding system (i.e. IDE) actually means. For example the SDK texture selection tool actually finds all textures, even those in included jar files, the code completion for material and material definition files does so too. The “Add Control” feature in the scene editor allows attaching freshly coded (or included) controls etc. etc.
So to integrate both the project (assets, libraries and code) and the editor (put spawn points, use the entity system and add NPCs) there needs to be a larger combination like the SDK but it seems to be impossible to achieve.
For features of the SDK like deploying to Android and iOS at the same time while developing on desktop (i.e. without any emulators) proper build tools like gradle scripts can be used but as Paul said, being able to download a program, start it, code a bit and then deploy an application to Desktop, Android or iOS is a whole different thing. I mean we’ve seen people give up in despair trying to even install a JDK
Note that in these assessments I also include the experience with jME2 which for a long time lived as “solely” a java library. From the beginning on people started to develop small tools, some external applications and a a whole slew of “world editors” - none of that ever converged into a usable toolchain. If at all it further diverged the development of jME2 - for example the animation system being replaced by every other model import system. The blender exporter for jME2 lived about half a year despite being a good prospect - it either broke on the blender side due to blender development or on the jME2 side due to jME development. And all the while other model importers that broke the animation system again were developed instead of the blender exporter getting any supporters.
So I don’t see how jME3 can prevent falling back to this kind of situation. Model importers that break if you have the wrong python version installed, world editors that create one-trick-pony games based on patterns that the creator deemed useful for the game he wanted to create at that time, a few tools by the core devs that effectively create text files one could write by hand and things like that won’t help or make jME3 greater.
That said, being “just a library” won’t stop jME3 from being useful for people who know how they want their coding environment set up and work through the issues of setting up a toolchain - it doesn’t stop them now from bypassing the SDK and doing exactly that either. Just like it didn’t stop them with jME2.
Anyway, maybe I’ll be proven wrong and we’ll have a paradise of readily available tools to make jME3 games in the future
All the best,
Normen