The new update should make the install process even easier. The process still works the same, just now with less annoying warnings and work around required. Also, the Java (target) has been split out as an individual sub-project, a move which makes lots of sense. I would describe why, but frankly the original author Michael Bayne did a good job already.
Howdy everyone,
I just released PlayN 1.0.1 to Maven Central (and the mirroring to the
public servers is complete).This release corrects a bunch of pesky errors relating to building
PlayN that crept into the 1.0 release in the eleventh hour.It should now be possible to import the PlayN sample projects and to
create a new PlayN project using the Maven Archetype without
encountering a single error or mysterious weirdness in Eclipse. I
would have liked to be able to say "warning or error," but annoyingly
my Eclipse complains that certain XML files lack a DTD specification,
which seems excessively anal to me, but that’s how they like to roll
over there at Eclipse HQ.One other important change was introduced in this release. The PlayN
archetype now generates a separate "java" submodule which contains the
Java backend entry point file (FooGameJava) and which has a dependency
on playn-java. The core submodule now only depends on playn-core.Prior to this change, the core submodule depended on playn-java (and
by transitivity playn-core) and the Java entry point was in the core
submodule. This eventually causes problems, because all of the other
submodules (html, android) depend on the core submodule, and if one
added some Java-only dependency to their code submodule so that they
could use it when testing with the Java backend, it would show up in
the html and android submodules and cause problems. Now the core
submodule can remain "pure" with only PlayN-safe dependencies, and if
you need additional dependencies for your Java backend, you add them
to the java submodule where they won’t cause problems with the other
submodules.Because the Java entry point is in a separate project, it is now
necessary to test the Java backend via Maven in a different way.
Instead of "mvn compile exec:java" in the core submodule directory,
one now invokes "mvn test -Ptest-java" in the top-level project
directory. This is more consistent with the way the HTML backend
works, so that’s nice. It’s also unfortunately a little slower, and
when you’re rapidly edit/compile/debugging, every millisecond counts.
The "ant run-java" target still works great in this new setup, and
remains very fast, so I recommend that command line users use that to
iteratively build and test their project. Eclipse users will now "Run
As -> Java Application" on the mygame-java project instead of the
mygame-core project, but otherwise everything is the same.Due to current-working-directory related issues exacerbated by the
creation of the java submodule, I rewrote the Java asset manager to
load assets from the classpath (robust) instead of loading them
directly from the file system (fragile). This means that you’ll need
to make a change to your Java entry point. Where you probably had
something like:platform.assetManager().setPathPrefix("src/main/java/playn/showcase/resourc es");
you should now use:
platform.assetManager().setPathPrefix("playn/showcase/resources");
As a fringe benefit, this was one of the main challenges preventing
the packaging of the Java backend up for use as a Java applet. Now
that this has been fixed, there are probably only a few niggling bits
that need fixing, and PlayN games can be deployed as Java applets by
anyone crazy enough to want to do so. 🙂Also, for those of you using sound in your games, the Java backend
used to require that you maintain separate .wav versions of your sound
resources. The HTML backend used .mp3 versions of said resources. The
Java version has been updated so that it uses the .mp3 versions as
well, so you no longer need to maintain .wav versions of your sounds.
Sounds on the Android backend remain largely untested (meaning they’re
probably broken), but when I get a chance, I’ll make sure that they
also work properly with .mp3 files, so that things remain consistent
across platforms.Between these and other small improvements to the archetype, it is
probably worth the small bit of trouble to regenerate your project
from the latest archetype, and move your sources and resources into
the new project, just to be sure that all the little fixes that have
made it into the archetype templates are applied to your project.
Alternatively, you could generate a new project using the latest
archetype with specifications equivalent to your project and then diff
the files that were generated against those in your project and
migrate any fixes you find into your project. Whether one or the other
is easier will depend on how much you’ve customized your poms.The flash submodule has been completely disabled in the latest
archetype. If the Flash backend is made functional again, it will be
reinstated.
The other key things to note is the removal of the Flash target ( which was apparently quite a ways from ready for prime time, and was breaking the build ). Anyways, good job to the PlayN team.