Building PlayN apps with Gradle

[James Williams]

For those of us who have a love-hate relationship with Ant/Maven, I've
worked out how to build PlayN apps with Gradle (a build tool popular
with the Groovy ecosystem). One of the plusses of Gradle is that you
create tasks in code, not with XML.

Anyways, I've got the first bit to build the playn-samples hello app
for Java documented here: http://jameswilliams.be/blog/entry/2011/11/28/Building+PlayN+applications+with+Gradle

Gradle only needs a few tweaks to the directory structure of a PlayN,
and that's only because I didn't feel like telling it where to find
resources and wanted to rely on Maven conventions.

Am working on the GWT/HTML5 bits next. You can check my progress here:
http://code.google.com/r/jameslwilliams-playnsamples-gradle/source/browse/#git%2Fhello

[James Williams]

Posted a follow-up building the HTML5/GWT target:
http://jameswilliams.be/blog/entry/2011/11/30/Building+HTML5+PlayN+Apps+with+Gradle

Android probably won't happen for a while, the Gradle Android plugin
(maintained by others) seems a bit wonky atm.

On Nov 28, 3:20 pm, James Williams <james.l.willi...@gmail.com> wrote:
> For those of us who have a love-hate relationship with Ant/Maven, I've
> worked out how to build PlayN apps with Gradle (a build tool popular
> with the Groovy ecosystem). One of the plusses of Gradle is that you
> create tasks in code, not with XML.
>
> Anyways, I've got the first bit to build the playn-samples hello app

> for Java documented here:http://jameswilliams.be/blog/entry/2011/11/28/Building+PlayN+applicat...

>
> Gradle only needs a few tweaks to the directory structure of a PlayN,
> and that's only because I didn't feel like telling it where to find
> resources and wanted to rely on Maven conventions.
>

> Am working on the GWT/HTML5 bits next. You can check my progress here:http://code.google.com/r/jameslwilliams-playnsamples-gradle/source/br...

[shawnd...@gmail.com]

I just wanted to say it would be nice if gradle became the standard instead of ant and maven. A lot of projects are going that way. You get the best of both worlds without all the XML.

Sent from my iPad

[Joel Webber]

James,

I must confess ignorance to the precise differences between maven and gradle, but as long as the systems can be made to work side-by-side, I of course have no objection to anyone working on this. I do have some concerns, however, if it leads to anyone working on the core libraries having to update two build specifications whenever they make a change (not sure if this would be the case or not).

The way I look at it, almost all build systems are roughly equally evil (you should see the one we have to use internally at Google!). I don't care too much for maven (because I frequently get hung up on strange errors when it breaks, even though it's usually my own fault), but I like it a lot more than *not* having maven and having to manage dependencies and build Eclipse/IntelliJ projects by hand.

The biggest impediment to using a different system, even if it's demonstrably better in some way, is that we have several companies depending upon the maven specifications in existing commercial projects. For them to switch build systems would be a significant burden, and doubtful one that they could justify.

All that said, perhaps there's some sane way to make these things coexist. I'll leave that as an exercise for the reader, as I'm not a big fan of mucking with build systems :)

Cheers,

joel.

[Fred Sauer]

For context: We currently have both maven and ant build files, although when I tried the ant build last week it broke, so clearly it's not as up to date as the maven side of the house.

To summarize my thoughts:

• the current "official" build system for PlayN is maven
• maven is the only one that appears to be working at this time
• we have at least one other build system (ant) in place, which worked very recently, and which can probably be made to work with a little TLC
• the playn project is still changing (in sometimes significant) ways, which mean any/all build scripts will need a regular caretaker/owner
• I have no objects to another build script existing in the main repository, with the caveat that no one -other than those wishing it to work- be responsible for keeping it up to date with the "official" build system
• if over time it becomes clear that some other build system is not being maintained and is continuously broken, it will likely be ejected :)

In other words, if you have a gradle script or whatever, feel free to provide a playn patch in the usual way (i.e. create a clone, and include a link to the commit).

Fred

--

Fred Sauer

Developer Advocate

Google Inc.

1600 Amphitheatre Parkway

Mountain View, CA 94043
fre...@google.com

[James Williams]

Fred,

I had a little more work to do to get it to be totally compatible with
the assumptions the maven build has as well as adding a task to create
a file.

It wasn't my goal in writing the posts to have gradle supplant Maven
or be a part of the official build but I'm happy to patch and maintain
it.

jw

On Dec 5, 2:01 pm, Fred Sauer <fre...@google.com> wrote:
> For context: We currently have both maven and ant build files, although
> when I tried the ant build last week it broke, so clearly it's not as up to
> date as the maven side of the house.
>
> To summarize my thoughts:
>

>    - the current "official" build system for PlayN is maven
>    - maven is the only one that appears to be working at this time
>    - we have at least one other build system (ant) in place, which worked

>    very recently, and which can probably be made to work with a little TLC

>    - the playn project is still changing (in sometimes significant) ways,

>    which mean any/all build scripts will need a regular caretaker/owner

>    - I have no objects to another build script existing in the main

>    repository, with the caveat that no one -other than those wishing it to
>    work- be responsible for keeping it up to date with the "official" build
>    system

>    - if over time it becomes clear that some other build system is not

> > Le 3 décembre 2011 13:12, shawndgar...@gmail.com <shawndgar...@gmail.com>a écrit :
>
> > I just wanted to say it would be nice if gradle became the standard
> >> instead of ant and maven. A lot of projects are going that way.  You get
> >> the best of both worlds without all the XML.
>
> >> Sent from my iPad
>

> >> On Nov 30, 2011, at 2:50 PM, James Williams <james.l.willi...@gmail.com>

> >> wrote:
>
> >> > Posted a follow-up building the HTML5/GWT target:
>

> >>http://jameswilliams.be/blog/entry/2011/11/30/Building+HTML5+PlayN+Ap...

[Fred Sauer]

Thanks. Let me know when you have a *.gradle file or whatever.

[Daniel Gerson]

I'm reviving this 1.5 year old thread.

So I've been watching Google IO vids and as an Eclipse+Maven user I now get that queasy feeling that I have to learn some new foundation tools.

I know that PlayN isn't Android specific, but I imagine that since Ray Cromwell is so influential in GWT, and that he is a big IntelliJ fan, it looks like Android, GWT, soon Google and likely PlayN will all be going Gradle + IntelliJ.

Do the PlayN gurus have thoughts/plans/roadmaps on this? What changes should we expect?

The Android release is a pretty big part of our plans if all goes well, so needless to say this is all of interest regarding future-proofing.

Thanx

DMG

[Michael Bayne]

On Wed, May 22, 2013 at 11:46 AM, Daniel Gerson <daniel...@gmail.com> wrote:

I know that PlayN isn't Android specific, but I imagine that since Ray Cromwell is so influential in GWT, and that he is a big IntelliJ fan, it looks like Android, GWT, soon Google and likely PlayN will all be going Gradle + IntelliJ.

PlayN hasn't been maintained by Google engineers for a long time.

PlayN also attempts, as much as possible, to be IDE agnostic by doing everything via Maven and relying on the various IDE's ability to properly handle Mavenized projects (which could be better, but mostly works).

There are no plans to convert PlayN's build system over to Gradle, nor to marry it to IntelliJ. The Android IntelliJ fork works *only* for Android projects and thus could not possibly function as a useful IDE for PlayN projects, which by design, target multiple platforms.

Apparently a new version of the IntelliJ community edition will be coming out soon that will have most of the Android features built into it. That IDE may be a good choice for PlayN game developers that want to use an IDE, though it's probably not any better than the current version of IntelliJ.

PlayN projects do not make use of the vast majority of Android-specific features, and the special support in the Android fork of IntelliJ are targeted at supporting those Android-specific features. PlayN projects are explicitly designed to be plain-old-Java-projects to a first approximation so that you can rapidly develop and test them using *any* standard Java development environment (be it integrated or not).

That will always remain the case, because it is both one of the fundamental benefits of building a game on PlayN (rapid development on the desktop), and a necessary consequence of PlayN's cross-platformness. PlayN could not start using a bunch of Android-specific features without becoming useless on N-1 platforms, or emulating them on N-1 platforms, which would be a gargantuan engineering effort for not much gain.

-- m...@samskivert.com

[Michael Bayne]

On Wed, May 22, 2013 at 12:02 PM, Michael Bayne <m...@samskivert.com> wrote:

There are no plans to convert PlayN's build system over to Gradle

That said, you can probably build a PlayN game with Gradle if you like Gradle and want to use it. I use SBT to do a lot of PlayN game development, though I then just use Maven to build and deploy to Android/iOS (which are the two most complex platforms to target).

-- m...@samskivert.com

[James Williams]

As the initiator of the original thread, I'll add my 2 cents here.

In my original tests with it, I hand coded the Gradle files after creating the template with Maven. At the time, the Java target worked with minimal tweaking, lots of tweaking for the HTML5/GWT target IIRC and the Android target in Gradle was very buggy, no doubt due to the immaturity of the Gradle Android plugins at the time. The niche appeal of Gradle and lack of maturity was why I chose not to pursue it at the time.

Given Google's push into the Gradle space in Android, the Android plugin is undoubtedly more mature and Gradle as niche build system is no longer the case.

Hindsight being 20/20, in a new iteration, I'd probably focus on building out a PlayN template project versus tweaking the output of the Maven build.

If the core team is already looking into it or thinking about it, I'm happy to lend a hand. Ray, you know where to find me.

On Wed, May 22, 2013 at 11:46 AM, Daniel Gerson <daniel...@gmail.com> wrote:

--
 
---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Daniel Gerson]

Thanx for the quick response Michael and James.
Looks like it's business as per usual then, at least from a PlayN perspective.
In the IO talk they mentioned Gradle functionality project wise that apparently Eclipse can't support. That's what made me more nervous.

Hopefully it all just continues to work, there'll be some maven-gradle plugin that uses the Android-SDK with gradle only official build support, and I never have to look under the hood.
Fingers crossed :-)

(Not that I'm against changing if it's better/necessary)

DMG

[Paul Gestwicki]

On Wednesday, May 22, 2013 3:07:04 PM UTC-4, Michael Bayne wrote:

That said, you can probably build a PlayN game with Gradle if you like Gradle and want to use it. I use SBT to do a lot of PlayN game development, though I then just use Maven to build and deploy to Android/iOS (which are the two most complex platforms to target).

Could you share a little bit more about how you use SBT with PlayN? I am curious as to the conditions under which SBT works better for you than Maven. 

[Andres Martinez Quijano]

+1

[Michael Bayne]

On Sat, May 25, 2013 at 7:53 AM, Paul Gestwicki <paul.ge...@gmail.com> wrote:

Could you share a little bit more about how you use SBT with PlayN? I am curious as to the conditions under which SBT works better for you than Maven.

I use SBT for incremental development. I set it up so that I can build and run the Java backend and use that while I'm developing and testing (using the sbt-lwjgl-plugin). I also use some extensions to SBT that I wrote that allow it to interoperate with Maven, so SBT reads the project info from the POMs and there is very little SBT-specific metadata.

SBT provides incremental compilation and very fast app restarts (via its REPL), though I also use an SBT plugin that integrates JRebel so that I can see a lot of changes without restarting my game at all. One could easily use JRebel with Maven as well.

With Spellwood, the whole server component was written in Scala and deployed as a Google App Engine app, and I used the SBT app-engine plugin to handle testing and deployment of the server component.

I do not use SBT to build and deploy the Android and iOS backends of the game because it's easy enough to use Maven and it would be a complicated pain in the neck to recreate all the necessary build steps to make that work fully. But I do have SBT compile the Android backend code, just to be sure that it stayed in sync.

I'll set up an SBT build for the PlayN showcase sample just to demonstrate, since it's a useful approach for non-IDE users, of which there may be one or two still lurking in the wild. :) There's already an SBT build for PlayN itself, which you can see in the playn/project directory, but that's a bit different from the build for a game, since PlayN is just a library. The playn/tests sub-modules are a lot like a game though, so it uses many of the same integrations that I use for a normal PlayN game.

-- m...@samskivert.com