Gradle support

[czyzby]

gdx-setup generates Gradle projects capable of deploying the application to multiple platforms. Most of LibGDX developers will not be willing to switch to Maven for a single platform, especially since browser hardly ever seems to be the main target. Dragome LibGDX backend has to provide Gradle tasks allowing to compile, run, debug and deploy the JS game - and a simple tutorial how to integrate it into existing projects. Compiled client must be standalone (HTML+JS only, the only requirement should be a HTTP server).

[fpetrola]

I think that dragome-sdk could keep maven mechanism and gdx-dragome use dragome-sdk from gradle, as far as I know gradle can handle maven dependencies, is this possible?

[czyzby]

It can handle Maven dependencies just right, but I'm not so sure about Maven tasks. An official Dragome Gradle plugin would be nice. We should look into converting Maven build into Gradle.

[czyzby]

See https://github.com/czyzby/dragome-sdk/tree/master/dragome-gradle-plugin

Gradle seems to somehow add more jars and classes than Maven, which results in unknown classes errors. I think @fpetrola should look into the plugin and compare the behavior with Maven; I can help with strictly Gradle-related issues.

[fpetrola]

Could you modify dragome-gradle-plugin to invoke standalone js generator to avoid current invocation method?:

task generateStandalone(type:JavaExec) {
   main = "com.dragome.web.helpers.serverside.StandaloneDragomeAppGenerator"
   classpath = sourceSets.main.runtimeClasspath
   args = [
   "./dist",
   "./webapp",
   "true",
   "true"
   ].toList()
}

[czyzby]

Sure, I'll convert the plugin to use the new generator. A new tooling API was exactly the thing I was waiting for.

[nicolaichuk]

@czyzby i do that write on this page https://github.com/czyzby/dragome-sdk/tree/master/dragome-gradle-plugin but gradle write message: "Could not find com.dragome:dragome-gradle-plugin:0.96-beta2-SNAPSHOT."

Is it still supported?

[czyzby]

I think you have to build the plugin manually and upload it to your Maven Local repository. I never had the rights to upload Dragome artifacts, so my plugin snapshots were not released. Note that my branch is probably outdated.

[Namek]

@nicolaichuk @czyzby Didn't tried with this project but usually this helps to avoid using local maven repo: https://jitpack.io/

[czyzby]

The thing is - this is not my project. I implemented the plugin, but it never got merged. I hardly have any rights to push Dragome artifacts to any repository.

[fpetrola]

Hi @czyzby , I don't understand some things about this. You say it is not your project? You started this gdx-backend one year ago, and you were in charge of it all the time, creating all the issues and all the code was committed by yourself. You ask me to add it to github 'dragome organization' and I agree. I don't remember any request for merging any code, or release any version of your software, neither any request for giving rights for pushing code. Besides this, is that piece of software running? did you test it? Last commit is from May 30, 2016, is this project active?

[czyzby]

Correct me if I'm mistaken, but I think we were discussing the Gradle plugin. I meant that the Dragome itself is not my project. Gradle plugin for Dragome is not a part of gdx-dragome, and I don't have the rights to push the Gradle plugin as an official Dragome artifact - I think the branch with the plugin was never merged into the official repo. That's what I was trying to say in the previous comment.

Anyway, I don't have the time to finish this project - I barely do any LibGDX contributions due to my work. Sorry.

To be honest, I really don't like how the whole thing with xpenatan repository turned out - we should have merged our work right from the start and focus on one repo, instead of having you encourage us both to basically do the same thing twice. At this point, xpenatan's LibGDX backend is more complete and you should consider adopting it into your organization.

https://github.com/xpenatan/gdx-dragome-backend

[fpetrola]

As I mentioned, I can't remember any request for merging this plugin to official repo nor any request for pushing it as a Dragome artifact. If you are now requesting it there is no problem, but we should evaluate how complete and useful is the current implementation state.

About @xpenatan project, you both started your own gdx backend and you did not agree about the way each one wanted to implement the backend. I can help any of you to make progress on your own backend but you have to solve by yourselves if you want to contribute to the same code base or you have two separated implementations. I'm not an active contributor of @xpenatan backend, I've just been solving Dragome bugs related to its execution. Please talk each other, if you want, about how to make an unified effort or if each one will progress on different parts, for example you can work on gradle plugin and @xpenatan on backend.

[czyzby]

Yeah, my mistake, I implemented Gradle plugin on my branch and basically left it there due to some issues with Dragome API which might have been resolved since then. I never opened a pull request since there were some weird classpath errors, if I remember correctly. You're welcome to go through the Gradle-related code, if you still need it. https://github.com/czyzby/dragome-sdk/tree/master/dragome-gradle-plugin https://github.com/czyzby/dragome-sdk/tree/master/dragome-gradle-plugin/src/main/java/com/dragome/gradle

I can help any of you to make progress on your own backend but you have to solve by yourselves if you want to contribute to the same code base or you have two separated implementations.

See, that's the whole problem. From your emails, I got the impression that this will be the official repository and you'll try to convince xpe to work together. It was a huge turnoff that not only did he refused to merge the repos, but you also encouraged us both to work on the same thing at the same time. Not cool.

As the main Dragome maintainer, who knew about both of our projects basically since their beginnings, you could have easily resolved this issue before any code was published. I started working on gdx-dragome before xpe pushed any code to his repository - if I knew we were both implementing this, I would have never started this project in the first place.

At this point, xpenatan project is obviously more mature, so I suggest replacing this repository with his. I don't mind deprecating/closing/deleting this repository in its current state. Really sorry how this turned out. If you want to continue this discussion, I suggest we do this by email.

[fpetrola]

I think it was pretty clear on this conversation: https://github.com/dragome/gdx-dragome/issues/13 , that took place after both of you already committed each code base. So excuse me but I did not encourage to do anything, you already implemented it before that conversation, in fact @xpenatan commit was one day before yours..

https://github.com/xpenatan/gdx-dragome-backend/commit/d0af66305ead8fbea4a81a8139700e39363efd95 @xpenatan committed on Mar 4, 2016 https://github.com/dragome/gdx-dragome/commit/4d7476ad22cc47e4c56e5fbaf1d40cc3a0ba1754 @czyzby committed on Mar 5, 2016

It's true I'd like both of you to join forces to use just one code base, but it's up to you both to agree on this not mine.

[czyzby]

You didn't scroll to the end of the commits list. The first commit to this repository was on Mar 2: https://github.com/dragome/gdx-dragome/commit/fbdac4ddf299f2ebdf0da66d88585c91b662308f.

[fpetrola]

The commits I mentioned are the ones where backend base were pushed on both project (where main code were committed), for example DragomeGraphics, DragomeAplication, etc are on both commits for the first time.

[czyzby]

I'm not denying that he started first. He most certainly did. The thing is - he did most of the initial work locally; he certainly did not push any code when I started. I couldn't find any info on LibGDX/Dragome integration before starting this project. A simple "hey, this guy is already doing this" would save us all some time.

Also, I discarded his initial contributions, as he chose to basically copy the LibGDX GWT backend code (which, well, lacks quality). If at the time you compared the GWT code with his project file by file, these huge commits might not look so impressive anymore. Back when I was working on this, there was nothing in his repository that I couldn't find in the LibGDX GWT codebase, except maybe a few "native" code bridges.

I think that my approach of incrementally refactoring and rewriting the ugly parts of GWT code and actually caring about code standards could result in a project both easier to maintain and more pleasant to use in the long run. But then again, his project works, so I'm glad it turned out OK.

As I've said, I hardly have any time for LibGDX contributions lately, so I must refuse to help. To be honest, I left mostly because of the numerous bugs and missing features in Dragome, and the weird feeling that I'm being played and you've got 2 guys doing the work for you. On the bright side, xpenatan might not need my help at all at this point, to be honest. I can help you integrating Dragome into my gdx-setup though, so you could generate LibGDX projects using Dragome backend.

I really don't want to argue anymore. I'm really sorry how this turned out. You have my full permission to do anything with the code, including merging it with xpe project or completely deleting from this repository. Take care.

[fpetrola]

No problem, I agree that copying code from GWT version is not the best approach to start the project with good practices. But in the other hand if it's easier to port and to have a running version quickly we can refactor the code in a future, using running demos as a test suite for regression tests, if there is no test suite provided by libgdx for backends.