Hi,
Due to the constant request of multiple users I made v3.2-prealpha-sdk1 available yesterday 
This means you can now try the latest engine features like PBR, the new Profiler and many other cool things.
Notes about this Release:
Note that prealpha means that there isn’t even a alpha1 engine version right now, so we just take what is on master at the time of the build (which also means no reliable engine version, however the engine build is always outputted as you start the sdk). This is also why I hope that you will experience many bugs (so we can fix them!). Specifically I expect PBR Materials and Shadernodes to have some bugs since those are new/not much tested as of now. The SDK has support for PBR and as such I guess you can place Lightprobes and such in the Scene Composer already, but bugs may appear.
General Notes:
With this announcement I want to state a few things about the sdk in general though:
Personal Opinon:
I’ll first start with a personal opinion (whining):
In the past, I’ve seen many people complaining about the sdk. They don’t use it because it just sucks.
Now while you are free to have that opinion, there is no way for the SDK to improve.
If you look at the Issues, you’ll see there isn’t much there. Most of those things are one-time problems with ancient versions on ancient computers or design/feature requests.
While I can understand that it’s just more fancy to use IntelliJ with a dark theme while sipping a club mate through you a red straw while maintaining your work-life-balance by playing foosball, I can’t see anything bad with netbeans itself. Sure it’s not fancy, but technically NB, Eclipse and IntelliJ aren’t really far away. For example there is a Gradle Plugin for Netbeans and I use the SDK for all kind of projects. I use it for university projects (they are using jme now ;)) and all.
Sure you have an opinion but I don’t see a reason to hate one IDE or another, you just get used to the workflow. If it’s something apart from the workflow, we’d love to hear from you, because that is the only way we can improve at all. This holds true for the engine itself. For example I just discovered that the android tests weren’t buildable due to some awt dependencies. No one ever reported that.
I know that sometimes waiting for an issue to be fixed might be annoying, I also know that reporting an issue might not be fun, but even only the subject might help us even KNOWING that there is something wrong. This btw increases the release cycle speed. Take the engine as an example: Since there weren’t any reports (positive or negative) the core team just waited a few days/weeks until the next version got released.
It sounds demanding however this is my overall impression at the moment: We need more feedback, more community. It’s Open Source, just dare to get your feet wet, technically you can’t do anything wrong, we’ll help you to help. That is how I started, for example: I had a look at some engine issues which were pretty easy to fix and I submitted PRs for them.
If you for example want to learn about that process for non critical things, take a look at the javadoc warnings appearing during build. Most of the time only a parameter name has been changed, the parameter has been removed or it simply misses two words (e.g. @param spat, you add the spatial to process). Missing @Override's are another common thing, typos, etc.
These are things were you can learn how to do it without much effort (e.g. trying to understand the problem and all), and we’d be happy to see you on board. We’re also open to bigger changes and actual bugfixes, if you feel ready, just make sure to format your code properly (SDK: Source->Format) and have a descriptive PR.
If you are still reading here then you might ask yourself the same question as I do now: Why the hell did I write so much about something so obvious, I don’t know 
Building the SDK on your own:
See here
Why don’t the updates work:
I’ve written it multiple times and considering the amount of text I already put into my opinion I am keeping this short:
We used to have an own server/webspace updates.jmonkeyengine.org. I consisted of a maven repository and the netbeans/sdk repository where plugins and updates were stored. I think this server was a sponsorship deal arranged by a monkey. Anyhow as it happens mostly for OSS: People disappeared, got distracted by own projects, got kidnapped by Arnold or killed by HAL-9000.
This lead to us being unable to publish several maven artifacts (jme3-jbullet , jme3-testdata, etc), because for jCenter they might be ToS violating (Test Data has no code or javadoc, it’s all resources).
Apart from that, SDK plugins and updates stopped working.
To prevent such a kind of issue again, we are actually trying to reduce complexity by relying on other services (instead of our jenkins server we use travis, instead of our own maven there is jCenter), but we still miss that part for the SDK:
Technically we only need some Webspace with FTP or SSH (SCP) access. However this should be some Open-Source Plan (no arranged manual sponsorship and such) possibly accessible using Github Team Sign On, so that unless the whole team is kidnapped, there is always the chance to recover.
We’d need something like a cloud storage, web space thing, some CDN, AWS, I don’t know what 
We do not want to setup a server or something like this though, just FTP and go. However we need Directory Listings to be enabled.
Feel free to suggest something to us as long as it’s a publicly available deal for Open Source Projects (Since everything else adds inreliability and uncertainity). I tried searching myself however a search only brings up open source cloud software instead of cloud for open source software 
I even had a look at github:ripienaar/free-for-dev however I don’t know if I’ve overlooked something.
I’ll give it a try asap.
