Merging xpenatan/dragome-backend

[czyzby]

It's logical to merge the repos with @xpenatan at some point, preferably ASAP to avoid confusion and reinventing the wheel. I'm obviously biased, so I'd like @fpetrola @xpenatan and @intrigus input on this.

Things to consider: existing code and issues, project structure (Gradle vs nothing/Maven).

From what I can see, dragome-backend repo currently contains Files and GL20 implementations (both based on GWT backend) that could be refactored and merged, the other core classes seem to be mostly empty. We agreed to wait with the implementation until proper typed arrays + WebGL support (#4), but I can try temporarily merging Xpe's code in a separate branch to finally run and test this backend. I'll link any related commits.

[xpenatan]

I'm porting and not reinventing the wheel. I will add some few stuff to easy things up and remove some ported stuff that may not need anymore.

The reason dragome-backend project setup is like that because its same structure as libgdx sources (with libgdx sources you can import and play in eclipse or use maven/gradle). Also, Libgdx eclipse project (Backends, Extensions and Tests) settings is pure eclipse java settings and dont have no maven or gradle attached and all dependencies points to /libs folders.

The libs jars are there for a reason:
1- It have some modifications in dragome jar files which is not yet in core;
2- All jars is 15 mb and is not a big deal (can eventually change to do similar command like libgdx "ant -f fetch" to free repo space);
3- Dont need to download any dependencies and focus on the backend;

This is working with sources. For snapshots/release I may merge everything in 1 jar with one of the build automation system.

The repo name I'm not even worried. There is a big title in README and repo sub title.

The other part of the backend (input, sound, etc) is easy to do and my focus now is improving graphics/jsDelegate to match interface perfectly so even for a improved (future) JsDelegate will work without changing much or anything at all.

[czyzby]

@xpenatan The thing is - you'll want to keep your repo, I'll want to keep mine. That's why I think other contributors should decide, especially @fpetrola.

Anyway, not everyone uses Eclipse, so I think it's a good idea to force this upon contributors. Keeping jars in the repo is just wrong, it's a huge step backwards from powerful build tools like Gradle or even Maven. If you have some custom Dragome code, I think you should use snapshot versions (if they are already pushed) or maintain a custom Maven repo (on GitHub, kinda like Dragome used to) - using Maven/Gradle from day one is crucial. You're right about the repo name though, I noticed it can be changed (and, well, folder structure can be easily refactored as well).

As for the code: your repo obviously has more code and functionalities for now, but it uses custom JS WebGL/typed arrays bindings which will eventually have to be replaced with official Dragome modules. GWT backend isn't exactly what I would call "clean" code, so I think it should be refactored rather than just adapted. Well, it works, so it should be a source of inspiration, but it definitely needs to be analyzed and corrected. While my backend forces a little different project structure than the original GWT, for me it seems it will be easier to maintain and extend.

I'm sick of GWT backend and I really want to target the web without some weird reflection (or what not) issues. GWT backend definitely needs more warnings and exceptions when using prohibited/not implemented features - that's why you'll rarely find copy-pasted GWT code, except for some small functionalities. I find this policy sensible, so I'll continue working on my project. At least for now. I think @fpetrola has the final vote on which repo we focus on.

BTW, when I said "reinventing the wheel", I meant there's no reason to maintain two Dragome backend repos.

[fpetrola]

I think @czyzby repository structure is more compatible with dragome-sdk structure and gdx structure. Using maven/gradle is very important cause it allows the integration of different projects and gives a way describe how is a project structured, released, compiled, built, etc. Also it's easy to start coding or using the project cause all commands are centralized in just one tool, regardless the IDE each developer likes (eclipse, intellij, netbeans).
@xpenatan is making a great progress over gdx backend and I'd like so much we make use of a lot of code he has made. I think we need to organize which implementations are in charge each one, doing this we can make progress in parallel, and make partial contributions to a bigger project, instead of make the same implementation twice.
So I think we could go like these steps:

1. Transfer gdx-dragome (@czyzby) to dragome-sdk github organization.
2. I can help @xpenatan to refactor some parts of his code to match dragome and gdx conventions (code and structure).
3. Delegate implementation of different missing features and different gdx specific implementation to each participant, for example I have to take annotations stuff, webgl wrappers, typed array mappers, etc.
4. Make successive PRs to integrate new changes.

What do you think guys?

[czyzby]

Agreed.

1. You might have to make a fork of this repository on @dragome account, so I can transfer it. Already sent transfer request. Transferred.
2. You should divide the code into LibGDX-specific features (like GL20 implementation) and JS wrappers (like WebGL and typed arrays support). I think the latter should be in a separate dragome-webgl module, rather than LibGDX extension.
3. Since @xpenatan focused on Graphics, Files and GL20, he can focus on merging these at first. We'll assign existing issues to each participant.