It’s not so complicated. I have started to look into SDK code like one week ago from exactly same reason than you are thinking of doing it and my first PR was merged into master yesterday. Previously I haven’t worked in netbeans. Start with small details that aren’t hard to fix and eventually you’ll be able to contribute something bigger if you keep going 
You can get details on building the sdk here: [SOLVED] Need help with JME SDK building - #15 by Vortex
Hope this helps.
The SDK can surely be distributed separately with compatible core engine libraries (if somebody cares for the distribution). The issue is that core engine changes might break how the SDK works so not all core updates can be pushed to the SDK. In general that was how the whole setup was designed, with the SDK plugin system being used to push only engine changes / SDK changes / single plugin changes. Which was also what happened during the 3.0 alpha/beta time and the lifetime of the 3.0 SDK with nightly updates up until it became incompatible to the newer 3.1 builds of the engine and SDK at which point only stable updates to the 3.0 SDK were delivered. The build targets etc. are all there.
In the case of core engine libraries breaking the SDK, wouldn’t it make sense to have some kind of modular tool structure (like SDK functions/tools as plugins) and then require an update of the broken tool to have it work with the new libraries again?
The functionality of the single broken tools could then be recovered again by smaller updates. That way no development would have to wait for the other. Of course updates that potentially break certain tools have to communicate that to the user before installation.
I mean like for the user he would still be able to work in the SDK (I guess that large parts like the code editor or the file system will never be touched by core engine changes) while having up-to-date libraries to code against.
I think that having the comfort of getting an update notification with an instant install option right in the SDK is a big bonus.
I don’t know since when you’re using jME but this “instant install update” was exactly what was happening as I just said. The single parts of the SDK functionality (e.g. Material Editor, Scene Composer etc.) are modular in nature. This whole thread is about maintaining that and it was decided it won’t be maintained anymore… You’re kind of talking past the point.
Ok, nevermind then, thanks for the insight. It was kind of hard to follow this long winded discussion.
I just hope there will still be such an easy entry point to JME as when I first discovered it.
I mean there are tons of open source game engines out there where you have to install an IDE, the libraries, dozens of dependencies, asset tools, etc. before you can get productive. I hope that JME will still be relevant among those without a single stand-alone SDK.
So… I say that then update only the engine. If sdk gets broken and bug reported we (the community) will fix it…
…eventually 
Hello guys, I am at the position of a complete beginner. I know how to code in Java and a couple of other languages, but I’ve never done something game/3rd dimension stuff before.
Will there be tutorials on the wiki?
I need something that shows me at least the basics. I don’t know which key topics are important for game developing, because I did not come from another project and just have to learn to migrate; I have to learn everything from the base.
What do you recommend to me? To switch the engine to learn the basics and have a stable knowlege to overcome all the upcoming obstacles? But how? Unity is script based, Unreal Engine uses C++ or is also script based. Is it a better idea to take a look on libgdx?
As I said, I’m completely lost without any guide. But I want to find a way through, at least there is a will
all is here
Thanks. There are tutorials that teach me how to use jMonkey without the SDK? Then I’m going to to dig there and see what I find. See you later ^^
Yes, it’s basically lines of code - which work both with SDK or without SDK.
Be warned though, many links are broken: Those links to google code (there are some) - because jME is now on github and the old code is “archieved” by google code (whatever that means).
EDIT: jME 3.0 SDK still works and is (as I see it) the best way to start learning jME.
Google discontinued google code… that’s what that means. All google code projects everywhere that ever existed are now ‘archived’. You can download a zip of them but that’s it.
For better or worse, the deed has been done:
In all honesty though, I do think this is a Good Thing. It won’t be without its rough patches, but I’m sure it’ll be worth it before long.
I m just wondering, will the SDK auto update with the new library? Or do i need to download them and replace?
Unfortunately, no. SDK updates are part of the SDK and therefore also won’t be provided.
Just keep the 3.0 SDK in the download section, then everything will be fine for me and my students… :chimpanzee_closedlaugh:
I think a single utility program would be an excellent investment. Something that’s IDE-agnostic and does some of the basic operations that we would need:
With this, you could simply point the program at your project directory or create a new project directory and run this only when you need one of its services. It’d probably be a pretty lightweight program that could easily run in the background without bogging anything down. People could write their game in any IDE they desire, then launch this when they need to convert a new model, make or edit a material, that kind of thing. Admittedly I’m not sure what kind of effort it would take to create something like this, but I imagine just some basic functionality wouldn’t be too difficult.
my simple ModelViewer could be used :
Links
Here is a project that seems to have quite a few features. Maybe the author can be contacted to continue, or allow collaboration.
Here is the link to the DArtE jME3 Sandbox Editor project on Github.
Here is the link to the forum page where it is discussed by the author.
My two cents worth on this. Even though I use the SDK quite a bit in my project, I am glad we are dropping it in terms of a NetBeans plugin. If someone can port the tools like the material edit and scene composer into Swing Applications (Unfortunately I never cared for the NetBeans API and never bothered to get up to speed on in over the decades) then I can certainly volunteer my time to maintain it. Part of my game needs this functionality built into a swing client anyway because my Alpha testers are also my development team. They currently have to run NetBeans for scene/object/material creating separately from the game client and them use the game client to integrate the assets into the game.
So if you guys can take it through the first step, I can spend time as a contributor and even contribute my networked server layer that allows you to distribute the swing editor over the network and retain the final game assets on a central server. Basically have a central asset repository that people actively collaborate with. If that is overkill for the community, I can minimally maintain the tools. I will be finally able to add all my code into an editor to take advantage of all the cool 3.1 features through GUI configuration … like instancing, network enabling model attributes, etc.
@erlend_sh please let me know what you guys think. I have grown to love JMonkey and I think it’s time I gave back to this project.
I always loved the sdk. I think it’s a great way of jumping into development.
What if we kept it for deployment and such?
All other tools would be stand-alone single-threaded jme netbeans projects
Would that remove most of the work on the devs and make it easier for others to help?
I mean, I need the sdk for android, deployment and such.
The idea would be that only the engine devs work on the netbeans sdk (because it’s hell to get ready and is all about deployment and such). Others would work on stand-alone tools.
I had no problem creating my own (not at all generic though) scene-composer / material editors and so on, but not in a thousand years would I get anywhere near something multi-threaded guarded by code nazis (code nazis are needed, code nazis are beautiful).