Maven $%#$%#

[Carsten]

I am very excited about PlayN. Still, I think chosing Maven is a big
mistake. Git is also somewhat peculiar but at least you just need to
install it once and check out the code. Maven however is at the core
and center of PlayN. It is just this big black box that is wonderful
if it works but horrible if it doesn't. PlayN is already complex
enough as it is to wrap your head around. You don't need to add an
extra layer of horrible to scare people off.

I know Maven is powerful and fun and all that but I promise you that
over 50% of the people who stop using PlayN do it because of Maven.
You are right the world should be a different one and developers
should make time to learn Maven since it is really pretty. Still, the
reality is that most devs don't use Maven. Period. It's like the Gimp
devs insisting for years that having multiple windows is better while
the rest of the world already settled the issue and used single-window
Photoshop.

Sorry for the rant. But PlayN has so much potential and Maven makes me
not want to use it.

[Alex Ferreira]

I agree.

2012/4/23 Carsten <carsten...@googlemail.com>

[Serhat Aydin]

+1

[Caner Altinbasak]

+1

[Michael Bayne]

On Mon, Apr 23, 2012 at 11:40 AM, Carsten
<carsten...@googlemail.com> wrote:
> Sorry for the rant. But PlayN has so much potential and Maven makes me
> not want to use it.

Do you have a better proposal for accommodating the provincial
idiosyncrasies of the five different platforms that we're trying to
support, as well as the vast array of different IDEs that random Java
developers turn up with and expect to have supported?

I hate Maven more than you do, I am absolutely certain. I've even
written a multipart series of blog posts about why Maven sucks, just
to relieve my own frustration with using it. However, it's still the
best way to accomplish the *extremely* complex stuff that PlayN has to
do to "just work" for building Java, Android, GWT, iOS, and Flash
games.

There is no alternative that will be less complex than Maven, nor that
will work for a larger percentage of the people who show up wanting to
use PlayN.

It's like democracy: it's the worst form of government except for all
of the others that have been tried.

-- m...@samskivert.com

[Ray Cromwell]

The only alternative to Maven (or ant+ivy which is maven) is the far
far worse solution of checking every dependency into the repository as
a binary artifact. And then you have the issue that my IDE (IntelliJ)
reads Maven POMs very well and sets up projects based on them, but
using a manual ant build process would cost me 10-15 minutes of
configuration per project setting up all the dependencies.

-Ray

[Michael Bayne]

On Mon, Apr 23, 2012 at 11:40 AM, Carsten
<carsten...@googlemail.com> wrote:

> Sorry for the rant. But PlayN has so much potential and Maven makes me
> not want to use it.

Incidentally, I maintain a parallel build system based on SBT (which I
hate almost as much as I hate Maven, but slightly less, therefore it's
an improvement). I also maintain a build system for the samples based
on Ant (which I hate about as much as I hate Maven). I (and others)
also work pretty hard to keep things working out of the box for
Eclipse users.

Everything uses Maven to resolve dependencies because there is no
alternative (other that the one Ray pointed out which I hope we can
all agree is an extremely bad idea).

So we're spending a heck of a lot of effort to shield people from the
complexities of the build system, and to support whatever favorite
build system or IDE someone shows up with. Sometimes the rough edges
poke out, but there's nothing we can do about that other than to
notice when that happens and sand them down, like we always do.

-- m...@samskivert.com

[Carsten]

I tried Processing for Java Desktop / Android / HTML5 the other day:
http://wiki.processing.org/w/Android

They are in alpha stage and you have to download the Android SDK. In
the post-Alpha release they will package the Android SDK with
Processing...just like they do with the JDK already. They have about
50 examples and they all just work. And it is fast. You should really
try out their user experience.

I am just telling this story that the people behind PlayN will see how
it could be. Instead it is the opposite now with Maven. You are
driving people away from the project :(

[Matt Mastracci]

What if we were to ship a proper playn-all.jar that's basically all of the dependencies jarjar'd into a single archive that devs can suck into a lib/ directory in their projects? This makes starting a "hello world" project in Eclipse or IntelliJ three steps:

1) Download playn-all.jar

2) Create a project, drop the jar in lib/

3) Create your skeleton Java game entry point

For those who choose to go the non-Maven route, we could have a set of recipes for building for various platforms based on the standard recipes for that platform.

Matt Mastracci

mat...@mastracci.com 

Twitter: @mmastrac

Blog: grack.com

[Ray Cromwell]

I don't think that works, when you go to deploy it, you end up with
this giant jar. Android gets gwt dependencies in the APK, your
web-inf/lib has non-Web dependeices.

Also, for Flash, because of classpath shadowing, there may be other
issues. It's an option we could do, we could add a jarjar rule to
maven to make it for those folks.

My experience with GWT, is that GWT-dev which uses the jar-jar
approach has been a big problem, and we're actually looking at
splitting it up into smaller functional pieces.

-Ray

[Richard Corsale]

As a Gimp user and a Maven hater, I second this shit.

--

~ Seize the moment

[Carsten]

No doubt, GWT is a beast all by itself. Android, iOS and Flash are
very complex too. I doubt anybody here fully understands all the
complexity of any of these platforms. Mix it all together and you have
something even more complex than the sum of its ingredients.
Okay. In summary. We have this super-complex thing. It is a huge
problem. Who at this point would say: "Let's add Maven into the mix."

Anyways...I have no solution. I don't know PlayN well enough yet.
Still just using Ant alone with ALL the dependencies shipped would be
a real help compared to Maven.

> > <carsten.schm...@googlemail.com> wrote:
>
> > Sorry for the rant. But PlayN has so much potential and Maven makes me
>
> > not want to use it.
>
> > Do you have a better proposal for accommodating the provincial
>
> > idiosyncrasies of the five different platforms that we're trying to
>
> > support, as well as the vast array of different IDEs that random Java
>
> > developers turn up with and expect to have supported?
>
> > I hate Maven more than you do, I am absolutely certain. I've even
>
> > written a multipart series of blog posts about why Maven sucks, just
>
> > to relieve my own frustration with using it. However, it's still the
>
> > best way to accomplish the *extremely* complex stuff that PlayN has to
>
> > do to "just work" for building Java, Android, GWT, iOS, and Flash
>
> > games.
>
> > There is no alternative that will be less complex than Maven, nor that
>
> > will work for a larger percentage of the people who show up wanting to
>
> > use PlayN.
>
> > It's like democracy: it's the worst form of government except for all
>
> > of the others that have been tried.
>
> > -- m...@samskivert.com
>
> > Matt Mastracci

> > matt...@mastracci.com
> > Twitter: @mmastrac
> > Blog: grack.com

[Richard Corsale]

There's always the android API way of doing it. We could get a custom
UI to setup the project and keep it synced. I wonder if there's a
maven plugin for that :). I don't hate maven, I just hate using it. So
fool me into thinking it's not behind the curtain.

-- Richard

--

~ Seize the moment

[Dieter]

Some people, when confronted with a problem, think “I know, I'll use
regular expressions.” Now they have two problems.


PlayN can solve the complexity problem like GWT.
GWT says we have this development mode. It is pure Java. GWT makes a
promise. If it works in the dev mode in pure Java we will do the rest
and you won't have to worry. We have these 'builders' (compiler magic)
that create the Javascript for every browser out there and you don't
even have to test it (unless you use your own JSNI code).


PlayN should have a development mode too. Let's choose Desktop Java.
It should only ship with Desktop Java and nothing else. PlayN should
make a promise: if it runs in this 'Desktop Java' development mode
environment, it will 'compile' with those 'builders/compilers' we ship
for other platforms: Android, iOS, HTML5, Flash, etc.
Those builders would be monolithic zip files you would download later
once you are happy with your app in Desktop Java mode and are ready to
deploy to those platforms. Then you would download your builder of
choice and simply add a one-liner to your Ant script that calls the
builder.

Obviously the PlayN development mode would need to check that you only
use classes in your PlayN game that won't break any of the builders
later. But this is very easy to do.

I think we all agree that PlayN just with Desktop Java is anything
easy to understand and use. And you wouldn't need Maven ;)

Cheers,
Dieter

[Matt Mastracci]

The "giant jar" problem is definitely a negative to this approach, although I think it's possible to fix with judicious use of ProGuard on Android. It's not really a big deal on HTML or Flash - the Flash super-source stuff can be hidden in its own separate folder so it isn't used in HTML mode. It might be for the Java platform if someone actually wanted to ship a desktop game using that. I haven't used mdb's iOS platform yet, so I'm not sure if this would be an issue on that platform.

Meeting half-way in the middle (this approach might be better, now that I think about it), we could ship all deps aggregated per-platform too:

playn-java-all.jar

playn-html-all.jar

playn-android-all.jar

playn-flash-all.jar

etc...

This might require shipping a trimmed-down playn-api.jar (ie: playn-core without JSON or GL) for end-users that want to have a platform-free common project.

[Darrin Thompson]

On Mon, Apr 23, 2012 at 3:25 PM, Carsten <carsten...@googlemail.com> wrote:

> Anyways...I have no solution. I don't know PlayN well enough yet.
> Still just using Ant alone with ALL the dependencies shipped would be
> a real help compared to Maven.
>

If someone is willing to write a maven plugin to build a working
"all-deps-shipped" distro then we have an alternative for the
non-maven folks. Yay! That still has to be maintained though and it's
going to be wretched thankless work.

The rationale for the current state of things was explained by Michael
Bayne in response to a different question from me:

QUOTE:
On Fri, Apr 13, 2012 at 10:24 AM, Darrin Thompson <darr...@gmail.com> wrote:
> What do you use instead? How much better does it work?

I use Maven to define the project metadata. Then I use Maven to do the
actual builds when I want reproducible builds that generate artifacts
(i.e. jars) that are tagged with the appropriate metadata and shipped
to a Maven repository (either local or corporate or public/Maven
Central) so that they can be used in other projects with zero manual
steps.

I use SBT (for which I've written plugins to read Maven project
metadata) for fast incremental building and testing.

I strongly believe that building a project should not be coupled to
editing the source code and IDEs are perpetrating a terrible crime by
combining these things. I happen to use Emacs, but it should not
matter what editor I want to use. I should be able to build and run a
project without getting any sort of IDE or code editor involved. This
is especially important when "I" am a continuous build server.

...
...
/QUOTE

There's more in the thread named: "GL ES 2.0 progress / access"

I really don't mind Maven myself. I can see why some people hate it,
and some of my co-workers are Maven problem magnets. But the bottom
line is that my day job project would be much harder without it.

Another possiblity might be adding a maven plugin to validate the
user's build environment. Are their android papers in order? Is the
GWT compiler properly unpacked for use (or is that a GAE thing)? Is
IKVM around?

It would work sort of like an Autotools configure script (now there's
a "now you have two problems" solution) except it wouldn't have to
output anything. It would just fail fast with usable information for
the user.

--
Darrin

[Michael Bayne]

On Mon, Apr 23, 2012 at 11:53 AM, Carsten
<carsten...@googlemail.com> wrote:
> I tried Processing for Java Desktop / Android / HTML5 the other day:
> http://wiki.processing.org/w/Android
>
> They are in alpha stage and you have to download the Android SDK. In
> the post-Alpha release they will package the Android SDK with
> Processing...just like they do with the JDK already. They have about
> 50 examples and they all just work. And it is fast. You should really
> try out their user experience.

The Processing app is very nice. Maybe you should build your game
using Processing instead of PlayN.

Processing is not Java. Processing developers are not Java developers.
For better or worse, we're trying to support Java developers and that
means supporting Java IDEs and providing a way to fit into as many
Java developers' build environments as we can. I could point to a
dozen reasons why Processing can take its integrated IDE approach and
why that won't work (or would be a *huge* effort) for PlayN. I could
also point to the 11 years that they've been working on processing,
and say "check back in ten years and let me know how you like PlayN's
build system then."

Furthermore, there's not even a "we" when I say "we're trying to
support Java developers". I'm working on PlayN because it seems like
the most expedient way for me and my colleagues at Three Rings to
create cross-platform games. I'm making all of my (not insubstantial
work) available for the rest of the world because I'm a nice person.

When I dragged PlayN out of the "you can build your game using
anything you like as long as it's Eclipse" ghetto it was in when I
arrived, Maven was the most viable choice for building projects that
targeted PlayN's profusion of backends. There's a GWT plugin for
Maven, there's an Android plugin for Maven, there's now an IKVM (iOS)
plugin for Maven (because I wrote it), there's a Google App Engine
plugin for Maven if you want to deploy your game to GAE. Not only
that, but Eclipse (and IntelliJ and NetBeans and any other IDE that
wants to remain relevant) had already added support for building Maven
projects or was in the process of doing so. The Java world is
standardizing on Maven POMs as a build metadata system that allows the
huge number of different build tools to interoperate reasonably well.
Why would we choose to spurn the benefits of that standard and roll
our own tools to build and deploy GWT apps, to build and deploy
Android apps, to build and deploy apps to GAE? Why would I write a
tool to build and deploy an iOS PlayN game that would have zero chance
of working with anyone's IDE when I could write the tool as a Maven
plugin and know that an Eclipse user could invoke it with a right
click, an IntelliJ user could use it by just pressing the standard
build button?

I'm working on PlayN because I want to write awesome games and deliver
them to users who will enjoy them via iOS or Android or HTML5 or
whatever comes down the road a few years from now. I'm not doing it
because I want to spend thousands of man hours making a nice IDE and
simple one click build system so that lazy people can play around on
the weekend without having to expend any effort. Those people can go
use Processing.

Try integrating Processing into an automated build server. Try having
six developers work on a single Processing project which depends on a
few hundred thousand lines of third-party library code which sometimes
needs to be locally patched and made available to those developers.
Try fixing a bug in the Processing platform or adding a feature to the
Processing platform and making use of that yourself or making those
fixes or enhancements available to the aforementioned six person team.
Hell, just try writing a two hundred KLOC game in Processing in the
first place.

> I am just telling this story that the people behind PlayN will see how
> it could be. Instead it is the opposite now with Maven. You are
> driving people away from the project :(

I'm not the "owner" of PlayN (if it could be said to have such a
thing), so take my opinion with a grain of salt and for what it is: my
opinion. I'm glad those people aren't here. I already see enough
stupid questions that could be answered with five minutes of Googling.

What PlayN does is a small miracle (allow you to deploy the same code
to JavaScript/HTML5, Java/Android, ActionScript/Flash and ARM
assembly/iOS), and there's such a tremendous amount of exceptional
engineering that goes into making that happen (the GWT project, Ray's
ActionScript code generator for GWT, IKVM, Mono and MonoTouch) that it
brings a tear to my eye. If you can't be bothered to upgrade your
Android SDK, or install the latest version of Eclipse, or overcome
some tiny road bump that stands in the way of benefiting from these
millions of man hours of engineering that went into making all of this
possible, then you have some wacky priorities.

I've done as much as I can tolerate to make using PlayN easy to use
for new developers (and I have a high tolerance). If someone else
wants to invest even a tenth as much effort as I have into improving
the new user experience, or the process by which a PlayN game is made,
the red carpet is rolled out to them. Or maybe some very clever person
can figure out how to convert all the energy that's been spent
complaining about the PlayN build system into energy spent toward
improving it. That would be a truly amazing feat.

-- m...@samskivert.com

[Ray Cromwell]

I would advocate patience. As Michael said, PlayN started out as very
rough. It was foisted on the world as a prototype that we used for
Angry Birds, and the community (with a HUGE help from Michael) has
taken it very far. It's no Unity3D, and so if you want an
all-inclusive environment, I'd look into that. But if enough people
can hold their nose over time, it will get better and better.

Stuff will be annoying for awhile. Eventually, the out of box
experience will be more pleasurable.

Anyway who wants to contribute crazy alternative build scripts, I
think we'll all open to it. They can live parallel with maven.

-Ray

[Ilkka Halila]

I work with PlayN daily and I'd like to voice my support for using Maven. Sure, Maven isn't perfect and in the beginning it felt like a black box that just does something, but once you learn to use it it becomes very useful. Like was already mentioned, setting up a continuous build on a server is trivial. The way Maven handles dependencies especially is great.

Also the fact that I can check out a project and just tell IntelliJ to read pom.xml and everything works is very helpful and time-saving. Eclipse nearly works like that as well, but that's an issue with Eclipse and not Maven.

Figuring out Maven isn't some herculean task, it's far less work than designing and implementing an actual game properly. Also like Ray said, I doubt anyone would complain loudly if someone wanted to implement (and most importantly maintain!) an alternative build system.

--
Ilkka Halila

Web Game Programmer

Rovio Entertainment Ltd.

ilkka....@rovio.com

+358 50 544 6086

[Mickael Barbeaux]

Same there.

As a professional JEE developer, I know and use Maven daily since years at work or for my own business, and sure it is quite hard to configure and understand for beginners, but once it's done, Maven is the best tool available with that kind of generic build and compile process.

The main problem I think is Eclipse and its maven integration. I stopped using the Eclipse M2E plugin since months. It's buggy and non-trivial to understand.

As an alternative, I only use Eclipse to "code" (my PlayN projects are just imported as standard Java projects, not Maven projects) and I use the linux terminal console to launch the maven executables. It's the best way I found in order to get everything work correctly.

Sometime ago, I tried Netbeans, which offers a better maven integration than Eclipse, maybe it could be a good alternative.

Mickael

[Ricardo Illescas]

Maven is a good tool, of course isnt perfect. As Mickael said I have found that the best way to work my playN projects is to code in any ide, editor and compile with maven in a terminal.

[Quan]

I'm definitely pro maven. And furthermore I want to say a huge thank
you to all the people who are working on PlayN. I really appreciate
your work, PlayN saverd me a lot of time and made it really easy for
me to develop games. So keep doing your thing :)

On Apr 24, 5:43 pm, Ricardo Illescas <rikarudoiresuk...@gmail.com>
wrote:

> Maven is a good tool, of course isnt perfect. As Mickael said I have found
> that the best way to work my playN projects is to code in any ide, editor
> and compile with maven in a terminal.

> >> On Tue, Apr 24, 2012 at 2:22 AM, Ray Cromwell <cromwell...@google.com>wrote:
>
> >>> I would advocate patience. As Michael said, PlayN started out as very
> >>> rough. It was foisted on the world as a prototype that we used for
> >>> Angry Birds, and the community (with a HUGE help from Michael) has
> >>> taken it very far. It's no Unity3D, and so if you want an
> >>> all-inclusive environment, I'd look into that. But if enough people
> >>> can hold their nose over time, it will get better and better.
>
> >>> Stuff will be annoying for awhile. Eventually, the out of box
> >>> experience will be more pleasurable.
>
> >>> Anyway who wants to contribute crazy alternative build scripts, I
> >>> think we'll all open to it. They can live parallel with maven.
>
> >>> -Ray
>
> >>> On Mon, Apr 23, 2012 at 3:29 PM, Michael Bayne <m...@samskivert.com>
> >>> wrote:
> >>> > On Mon, Apr 23, 2012 at 11:53 AM, Carsten

> >>> > <carsten.schmied@googlemail.**com <carsten.schm...@googlemail.com>>

> >>> wrote:
> >>> >> I tried Processing for Java Desktop / Android / HTML5 the other day:

> >>> >>http://wiki.processing.org/w/**Android<http://wiki.processing.org/w/Android>

> >> *Ilkka Halila*

> >> Web Game Programmer
> >> Rovio Entertainment Ltd.

> >> ilkka.hal...@rovio.com
> >> +358 50 544 6086

[Mike Fleischauer]

I am no fan of Maven either, although like Mickael said, I think the
root of most problems is actually M2E ( Eclipse ), not maven itself.
That creates a weird catch-22 though, as Maven for Eclipse makes Maven
more accessible to newbies... when it works. When it doesn't ( which
seems to be far to often ), it's like a gigantic train wreck. I wrote
an installer a while back ( http://gamefromscratch.com/post/2011/11/06/PlayN-automated-installer.aspx
) that automates almost all of the complexity away ( including
installing the JDK, Maven and Ant ), and perhaps that is the route we
want to push new users? It's horrifically inefficient, but it works
the majority of the time.

I will say, I contribute nothing to the core of Eclipse ( the code
base / build process ) is too daunting at this stage, as well as Java
being like my 3rd or 4th native language. So I have tried to help on
the usability / installation front, which seems to be the place where
most people get hung up. As a result I have fielded quite a few
emails and I will say the *VAST* majority are around Eclipse/Maven.


I would suggest one of two approaches...

1- formalize the installer approach as a "getting started" path
or
2- do what Deiter recommended. It may be technically infeasible, but
is the build complexity not a direct result of the cross platform
support? I hate to say it, but many people just starting out really
don't give a damn. I mean, somewhere down the road they want the
ability to port to different platforms obviously, thats the big appeal
of PlayN, but in just starting out I bet 99% of people just want to
evaluate PlayN as a development library. If you provided a "Desktop
Edition" or "Evaluation edition" or however you want to brand it, that
is PlayN for Java only, or PlayN for Android only, people could jump
in and get started with PlayN right away, then tackle the complexity
of supporting multiple platforms when they get to that bridge. Then
you could just provide a single Jar every few months on the PlayN
website, hopefully creating no more work for PlayN's developers, but
greatly increasing accessibility to new devs.

[bootstraponline]

Maven makes PlayN a delight to work with in Eclipse. I hope the random
people who showed up to bash the build system while offering no
solutions are able to contribute in a constructive way.

[Neil Voskeritchian]

If anyone using Eclipse is willing to make a jump to another IDE,  I've been using Netbeans for years and it works very well with Maven.  I've never had any issues with building PlayN with it.  I've tried many times to go to Eclipse over the last 5 years because so many people seem to be using it and so many integrated plugins seem to be developed for it, but it doesn't take long for me to get frustrated and ditch it.  I originally started evaluating PlayN with Eclipse and had nothing but trouble.  I then moved back to Netbeans and everything just worked.

[bootstraponline]

I like NetBeans also and it's great that Maven enables one to select the
IDE they enjoy the most.

[Darrin Thompson]

I can get Maven and Eclipse to work ok but I've never achieved
"delight." For instance, I have a little Linux desktop dev machine
with an i3 processor and 4GB of ram. I find that my turnaround time
from edit to run is sluggish. And for edit to debug I need to click
around in eclipse to remote attach, which feels like just more
movement between me and my result.

If somebody like you who "gets" maven+eclipse showed somehow what
minute to minute development looks like when you know what you are
doing, I would totally watch that and express gratefulness profusely.

--
Darrin

[bootstraponline]

I run 64 bit Ubuntu with 16 gigs of RAM and a SSD. The first change I
make after installing Eclipse is to bump up MaxPermSize, Xms, and Xmx in
eclipse.ini. Eclipse on slow hardware is not fun.

In terms of development, it's much faster to work on Desktop Java.
Importing a Maven pom which automatically sets up the project, all
dependencies, and attaches sources is a huge time savings.

At the moment my "minute to minute development" is unremarkable because
PlayN works correctly out of the box. I'm not doing anything special
that's not explained in the GettingStarted wiki page.

[Darrin Thompson]

On Thu, Apr 26, 2012 at 3:01 PM, bootstraponline
<ca...@bootstraponline.com> wrote:
> I run 64 bit Ubuntu with 16 gigs of RAM and a SSD. The first change I make
> after installing Eclipse is to bump up MaxPermSize, Xms, and Xmx in
> eclipse.ini. Eclipse on slow hardware is not fun.
>

I never thought to tune Eclipse that way.

And buy a faster compy.

Simple. Thanks!

--
Darrin

[badlog...@gmail.com]

Been a lurker for some time and am not using PlayN for obvious reasons [1] :) A little input from my end if i may.

If there's one thing i regret about the thing i'm working on, it's that i didn't go with Maven from the beginning. Manually setting up the dependencies for 4 different sub-projects is a huge pain in the ass and scares away beginners more than installing Maven does. We now have a nice UI that sets up everything, but it does so in an Eclipse dependent way. That's bad, people should be allowed to use whatever dev environment they like.

Furthermore, it hinders adoption by non-hobbyists. Deployment to a local artifact repo is usually a very bad idea as it adds additional maintainance. And if you have external project partners that work on the same source, it gets even worse.

In our case it was mostly the native components that kept me from mavenizing the project. PlayN does not have that burden yet (well, it kinda has with the IKVM backend). Going with Maven was the right choice imo.

TL;DR: Maven is the way to go.

[1] http://libgdx.badlogicgames.com

[Dieter]

I wouldn't change the Maven setup. It is great if you want to deploy
to multiple platforms. I don't like that I don't feel like I have 100%
control and understand everything Maven is doing behind the curtains
but I guess I have to live with it for now.

However, I would suggest to release a single zip file that contains a
single Eclipse-project, the PlayN core and java jars and a few example
games. It should just deploy for Java-Desktop. Nothing else. A dead-
simple Getting-Started guide speaking about PlayN and not Maven would
make it perfect.

It should be fairly easy to wrap this zip file automatically using the
latest stable PlayN release.

Once people are familiar with PlayN and want to 'deploy' their Java-
Desktop game to other platforms they could start working with Maven.

As I said, it is just a suggestion because I am very comfortable with
Maven but I think that a lot of new users are put off since it is all
too much when they just want to explore PlayN.

Cheers,
Dieter

On Apr 26, 5:56 pm, Mike Fleischauer <retur...@gmail.com> wrote:
> I am no fan of Maven either, although like Mickael said, I think the
> root of most problems is actually M2E ( Eclipse ), not maven itself.
> That creates a weird catch-22 though, as Maven for Eclipse makes Maven
> more accessible to newbies... when it works.  When it doesn't ( which
> seems to be far to often ), it's like a gigantic train wreck.  I wrote

> an installer a while back (http://gamefromscratch.com/post/2011/11/06/PlayN-automated-installer....

[Giovanni Luca Scuderi]

PlayN is a complex project, that performs complex task to achieve to a
simple Goal: Multiplatform Game that is a very complex task.
Maven add complexity but allow to do all that needs to deploy a playn project.
Without maven could be more complex manage dependency, multi platform
build, prototype project, etc.
A scripted depend system could be an alternative to maven but it is
not a standard way and could be worse if project became too big.
I've started using maven with PlayN, and it was very difficult, but if
you start to understand it could be funny. I must say that I hate it
BUT Maven is very powerfull; more you step inside to maven more power
you can find! It has a very high learning curve because introduce many
concepts. Maven is necessary ( imho ) to automate "large amount of
task".

BUT

If you want to develop a simple multiplatform game:
Maven is a "background technology" like git. You don't care about it.
All is automated, and all that you need is follow step to step guide.
You don't need to understand what a plugin is or what a push is (
refered to git ).
I want to say too:
"More complex and big is your goal, more you need to dirty your hands
... this is a rule. "
PlayN or not PlayN ... if you are using Unity3d, Mono, OpenGL , .Net,
Java3d, Blender, or other framework ... you must go in advanced
features. In PlayN means: understand GWT and Maven, in Drupal
understand hooks-module system, in opengl/c++
pragma-stl-boost--autotools, in blender game engine-python + c++ bind
etc, etc. etc.

PlayN is not ready to be a popular framework to develop a game because
is sitll complex to use, but i'm pretty sure that will be simplier.

If you need to develop a multplatform game
(java.html5,ios,flash,Android) in java... i think that it is easiest
way ...( that i know ... )



--
Ing. (B.Eng.) Scuderi Giovanni Luca
I.C.T. Developer, Web Developer, I.C.T. Engineer, Freelancer, Coder.
Tel +39 3289746482
GTalk: gls...@gmail.com
Skype: bl4ckd3v1l82
MSN: blackde...@hotmail.it
Member of: Zencoders Group (http://zencoders.org/)
My Github: https://github.com/Lebby
NickName: Lebby
Job Status: unemployed - attempting to finish I.T. Master's degree

[ap...@avsdevstudio.com]

The choice of Maven is great. Starting from a clean GIT clone, I
managed to run the java and html version of showcase in about 20
minutes.

I like Netbeans, some folks like Eclipse, some still like VI/Emacs,
and release engineers love their Hudson/Jenkins. It's an absolutely
correct decision to decouple source code editing/navigating from
project organization/management structure.

[ap...@avsdevstudio.com]

The playn project could not have been simpler to setup.  Total time
from git clone of playn, build and test java/html versions of showcase
 to setting up, building, and testing my own project , probably 30
minutes.

And, yes, thanks playn folks for putting this project together -- real
nice stuff!