Maven wrangling
Michael Bayne
public Maven repository:
jlayer:jlayer:1.0.1
This isn't in Maven Central, but I've emailed the authors of the
library and am going to try to get them to either upload it themselves
or allow me to upload it.
allen_sauer:gwt-log:1.0.r613
allen_sauer:gwt-voices:1.0.r421
Fred, if you want to add me as a committer, I'll take care of setting
up a Maven repo on those projects and publishing the latest versions
of the libraries to it. :)
com.google.gwt:gwt-flash:1.0
It would be great if this became a Google Code project as well, and
hosted its own Maven repository. But since it at least doesn't change
much, we could continue to host it in a Maven repository hosted by the
PlayN project. We'll need to create an additional Git repository
(right now we have default and wiki, perhaps the new one should be
called maven?), and then I can install the appropriate bits into the
repository and add the right configuration to our POM so that the
gwt-flash artifact is automatically downloaded when building PlayN.
andres
samples work? (in Eclipse, imported as per instructions on the wiki)
Thanks
Michael Bayne
> In the meantime, is there a way to make the project compile and
> samples work? (in Eclipse, imported as per instructions on the wiki)
Yep, just run the following:
% cd playn
% mvn install:install-file -DgroupId=jlayer -DartifactId=jlayer
-Dversion=1.0.1 -Dpackaging=jar
-Dfile=core/lib/JLayer1.0.1/jl1.0.1.jar
% mvn install:install-file -DgroupId=allen_sauer -DartifactId=gwt-log
-Dversion=3.1.4 -Dpackaging=jar -Dfile=core/lib/gwt-log-3.1.4.jar
% mvn install:install-file -DgroupId=allen_sauer
-DartifactId=gwt-voices -Dversion=2.1.2 -Dpackaging=jar
-Dfile=core/lib/gwt-voices-2.1.2.jar
% mvn install:install-file -DgroupId=com.google.gwt
-DartifactId=gwt-flash -Dversion=1.0 -Dpackaging=jar
-Dfile=core/lib/gwtflash.jar
I noticed that the core/pom.xml file was way out of date with the
gwt-voices and gwt-log dependencies, so I updated those and you'll
need to "git pull" to get the latest POM.
Jon Gill
Andres Martinez Quijano
Archive for required library:
'sample/m2/snapshots/com/googlecode/playn/forplay-hello-core-archetype/1.0-SNAPSHOT/forplay-hello-core-archetype-1.0-20110722.062032-1.jar'
in project 'playn' cannot be read or is not a valid ZIP file
and that jar doesn't match it's md5sum, I'm the only one?
Jon Gill
Dorian Manning
Agreed.
Ray Cromwell
project-pom
subproject1
subproject2
subproject-pom
subsubproject
subsubproject
Adhering to maven conventions actually makes working with it really
nice, but it may foul up some people's IDEs, although it seems
IntelliJ and Eclipse both know how to deal with this setup now.
Michael Bayne
> I'm still getting an error in the Android project complaining that I'm
> missing allen_sauer/gwt-log/1.0.r613.jar.
That's an error in the Android POM. Clearly Android does not depend on
GWT code. It's fixed and pushed, try pulling one more time and you
should be good to go.
Jon Gill
Michael Bayne
> Do you know how to set up and run the Android samples from these projects?
> I can't work it out for the life of me, and I need to be able to run them
> in order to test and develop the Android code.
None of the android samples had POM files created before (or the
playn/android project itself until I created it). I will create POM
files for the android samples presently and we can figure out what
additional bits are needed to get Eclipse to magically wire up the
necessary Google Plugin Android bits.
Jon Gill
Jon Gill
Michael Bayne
> There _is_ a
> Maven plugin for Android, but I'm not sure what actual functionality that
> provides.
I've been wrangling with various combinations of m2eclipse and the
Maven Android plugin and the Eclipse Android plugin. I'm deep in the
seventh circle of hell, but I think I'm getting close to something
that might eventually work.
One thing I'm discovering though, is that the way the POMs are
structured, an Android project ends up depending on half a dozen
GWT-related libraries which causes Proguard to blow the heap trying to
determine that none of that stuff is needed for an Android project.
I think this is going to ultimately require that I restructure the
main project so that we have playn-core, playn-java, playn-html (which
will include the Flash stuff), and playn-android. It's a little
unfortunate to have to split the other backends out of core, but
actually this is probably for the best. It would be nice if each
backend jar file only actually depended on the things it really
needed.
Anyhow, that's going to require a code review and whatnot, so if you
have things working temporarily with a bit of hackery, then I can rest
a bit easier that I'm not blocking your progress.
Ray Cromwell
separated. That's how it was originally organized a long time ago, but
it got lumped together at one point because it was easier for some
customers to work iteratively with everything within the same source
roots, but IIRC, this was only done for expediency because no one
wanted to take the time to set it up the correct way, and some of the
people who needed help setting up eclipse were in Europe complicating
things further for collaboration.
Is that your understand Joel? Your original project structure had
dependency chains like this:
FooGameCore -> ForPlayCore
FooGameHtml -> FooGameCore + ForPlayHtml -> ForPlayCore
FooGameAndroid -> FooGameCore + ForPlayAndroid -> ForPlayCore
etc
-Ray
Jon Gill
>
> I've been wrangling with various combinations of m2eclipse and the
> Maven Android plugin and the Eclipse Android plugin. I'm deep in the
> seventh circle of hell, but I think I'm getting close to something
> that might eventually work.
>
That sounds truly hellish. My condolences.
On the Android side, it would actually be preferable to split up all
the platforms from core. Right now the APK is getting packed with a
lot of unnecessary classes from the other platforms.
Michael Bayne
> FooGameCore -> ForPlayCore
> FooGameHtml -> FooGameCore + ForPlayHtml -> ForPlayCore
> FooGameAndroid -> FooGameCore + ForPlayAndroid -> ForPlayCore
That's essentially where I ended up, and working with the split
projects is actually pretty straightforward now in Eclipse because
m2eclipse wires up all the subproject dependencies properly, making it
easy to test the HTML or Android version periodically as you do your
main work in Core.
Michael Bayne
> On the Android side, it would actually be preferable to split up all
> the platforms from core. Right now the APK is getting packed with a
> lot of unnecessary classes from the other platforms.
This has also been achieved:
1064 -rw-rw-r-- 1 mdb staff 532K Aug 18 10:32
playn-hello-android-1.0-SNAPSHOT.apk
1544 -rw-rw-r-- 1 mdb staff 770K Aug 18 10:31
playn-cute-android-1.0-SNAPSHOT.apk
Reasonably svelte, especially considering hello contains ~265k of images.
Jon Gill
up fantastically. (I'll let someone else more familiar with Maven
actually review it, though.) Could you explain the issue with
including Pythagoras in Android projects, though? This is an issue we
will likely run into when dealing with the JOGL bindings JAR for
Android OpenGL, too, so I'd like to have a firmer understanding of the
problem.
--
Michael Bayne
> Could you explain the issue with
> including Pythagoras in Android projects, though? This is an issue we
> will likely run into when dealing with the JOGL bindings JAR for
> Android OpenGL, too, so I'd like to have a firmer understanding of the
> problem.
Basically, when building the APK in Eclipse, Eclipse seems to fail to
include transitive dependencies *unless* an Eclipse project exists for
those dependencies.
The Eclipse Maven support does some magic, whereby if it sees that
project A depends on, say, version 1.1 of project B (via its pom.xml
file), and it sees that there is an Eclipse project in the workspace
with a pom.xml file that reports that it vends version 1.1 of project
B, it will make the A Eclipse project depend on the B Eclipse project,
instead of obtaining a jar file for version 1.1 of B through Maven
(which is the default behavior).
So when someone imports PlayN into Eclipse, if they have Pythagoras
already imported, Eclipse will detect this and make PlayN Core depend
directly on the Pythagoras Eclipse project, instead of obtaining
pythagoras-1.1-SNAPSHOT.jar from Maven.
When the time comes to build an Android project, any dependencies that
are not Eclipse projects are not correctly incorporated into the APK.
Using Maven from the command line does not exhibit this problem. It
obtains Pythagoras (and indeed all of PlayN as well) via the jar
artifacts provided by Maven, and properly incorporates them into the
APK.
I did some cursory googling to try to find out whether this was a
known issue with the Eclipse Android plugin, but failed to find
anything. It's not an error that is easily googlable, so more
sustained investigation may bear fruit.
Jon Gill
Have you been able to successfully run the Android samples with the
new set-up, then? I haven't pulled your new Maven update yet, so this
could be a stupid question, but in the before Android was not packing
any resources in the core or game projects into the APK, so the asset
manager could not find any files (graphics, shaders, and the like)
that weren't manually copied into in the game-android project or the
playn.android one (which I am linking to as an Android library). Is
this no longer an issue?
--
Milutin Jovanović
Hi all,
I am not sure if this is the proper place to post this issue, but it does seem maven related. I've been following the "wrangling" threads and it is not clear to me how much wrangling is supposed to be here. All the discussions are about some Android problems... But to me the problem is of "nothing works" kind.
I went the simple Eclipse/Import Maven Project route. Wizard finds multiple project, then imports them. However all but webgl and server do not build due to missing dependencies, jlayer, voices, flash and log. OK, I did more searching and found recommendation to execute following lines to bring things into order:
% mvn install:install-file -DgroupId=jlayer -DartifactId=jlayer -Dversion=1.0.1 -Dpackaging=jar -Dfile=core/lib/JLayer1.0.1/jl1.0.1.jar
% mvn install:install-file -DgroupId=allen_sauer -DartifactId=gwt-log -Dversion=3.1.4 -Dpackaging=jar -Dfile=core/lib/gwt-log-3.1.4.jar
% mvn install:install-file -DgroupId=allen_sauer -DartifactId=gwt-voices -Dversion=2.1.2 -Dpackaging=jar -Dfile=core/lib/gwt-voices-2.1.2.jar
% mvn install:install-file -DgroupId=com.google.gwt -DartifactId=gwt-flash -Dversion=1.0 -Dpackaging=jar -Dfile=core/lib/gwtflash.jar
[INFO] Scanning for projects...
[ERROR] The build could not read 2 projects -> [Help 1]
[ERROR]
[ERROR] The project com.googlecode.playn:playn-test-core:1.0-SNAPSHOT (/Users/miki/projects/playn/test/core/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact com.googlecode.playn:playn-project:pom:1.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 4, column 11 -> [Help 2]
[ERROR]
[ERROR] The project com.googlecode.playn:playn-manualtests:1.0-SNAPSHOT (/Users/miki/projects/playn/test/manualtests/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact com.googlecode.playn:playn-project:pom:1.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 4, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
The error suggests a problem in the pom, which as a maven noob I know nothing about. So, is this the state of the project at the moment waiting for maven to be "unwrangled" or am I doing something wrong?
BTW, is your plan for the users of playn to have to know maven, or is it for playn development only?
Miki.
Dorian Manning
Yes, I was gonna wait until Michael Bayne's changes got reviewed to bring it up. But I have been wondering if maven I supposed to be necessary, for setting up new playn projects in the end?
Michael Bayne
> Yes, I was gonna wait until Michael Bayne's changes got reviewed to bring it
> up. But I have been wondering if maven I supposed to be necessary, for
> setting up new playn projects in the end?
It will be possible to build PlayN via Eclipse without using Maven
directly (other than importing the projects into Eclipse using its
Maven support).
And it will certainly be possible to build projects that use PlayN
without using Maven (though using Maven in some capacity will simplify
the process of obtaining the necessary dependencies). Most build
systems support obtaining dependencies from a Maven repository, so
whatever build system you use (or if you use no build system and just
use Eclipse) you should be able to steer clear of interacting directly
with Maven.
There is also the Maven "archetype" which helps with setting up a new
skeleton PlayN project, but you don't have to use that if you want to
avoid using Maven.
I have no particular love of Maven myself, but it is the most widely
supported project metadata format, and using it on PlayN allows us to
avoid having to maintain multiple independent sets of build
instructions. On a project as complex as PlayN, where we build Java
applications, GWT web applications and Android applications, not
having to duplicate your build instructions is very helpful.
Michael Bayne
> I am not sure if this is the proper place to post this issue, but it does
> seem maven related. I've been following the "wrangling" threads and it is
> not clear to me how much wrangling is supposed to be here. All the
> discussions are about some Android problems... But to me the problem is of
> "nothing works" kind.
As you've discovered, things are not working out of the box at the
moment. Between the fixes I have waiting to be reviewed and some
changes that I'll make and apply after those are in, I'll get
everything working out of the box for Eclipse users, ASAP. I'd like to
clean up these other hardcoded dependencies, but I don't want the
setup process for new users to involve painful manual steps while
we're figuring out how to resolve those issues.
Michael Bayne
> Have you been able to successfully run the Android samples with the
> new set-up, then?
I have.
> I haven't pulled your new Maven update yet, so this
> could be a stupid question, but in the before Android was not packing
> any resources in the core or game projects into the APK, so the asset
> manager could not find any files (graphics, shaders, and the like)
> that weren't manually copied into in the game-android project or the
> playn.android one (which I am linking to as an Android library). Is
> this no longer an issue?
It's no longer an issue if you deploy the app from the command line,
using Maven. If you deploy it via Eclipse, then the resources are not
copied automatically (perhaps for the same reason that the Pythagoras
dependencies are not copied automatically, I don't know).
I'm starting to suspect that the Eclipse Android plugin is not very
robust, or at least has not been used significantly on complex
projects with multiple dependencies. Though it seems strange that the
very straightforward process of copying resources into an APK would
not work in the Eclipse Android plugin. Oh, I guess there is one level
of indirection, since the game-android project depends on the
game-core project and the game-core project has the resources. So
perhaps that vexes Eclipse. As I mentioned, Maven handles it just
fine.
In any case, at least I haven't made things worse for Eclipse users on
this front. :) If you want to deploy from Eclipse, you still have to
copy the resources in manually. If anyone can figure out what the
problem is here, that would be great. But at least we have one working
mechanism for building and installing games on Android, even if it
does involve the use of the dreaded command line.
Milutin Jovanović
Just to be clear, is it possible to currently use playn even with manual steps?
Miki.
consiliens
>
> Just to be clear, is it possible to currently use playn even with manual
> steps?
>
> Miki.
I'd also like to know the answer to this. I just pulled from the git
repo and nothing works.
Jon Gill
Have you tried following Michael's suggestions from the start of this
thread?
--
Michael Bayne
> and nothing works.
Well, I'm possibly overstepping my bounds here, but I went ahead and
pushed my pending patches to the main repository, because it's getting
too annoying to hear about how nothing works for everyone while the
patches that fix all of those problems are sitting right there, ready
to solve everyone's problems.
So if you have checked out the main project, you should be able to
"git pull" and get the latest stuff and building with Maven should
work immediately. Eclipse users will need to remove their existing
Eclipse projects from their workspace and reimport PlayN because the
project names have all changed and new projects have been introduced.
People that have their own clone will need to pull the changes from
the upstream repository into their clone to get these fixes. I'll
assume cloners are git-savvy enough to know what I'm talking about,
but if anyone wants more specific instructions, just ask.
This reorganization should put us on a solid footing going forward,
and we should not need to do any more (major) subproject
reorganization, as it is now possible to cleanly build the Java,
HTML/Flash, and Android backends from either Maven or Eclipse. Eclipse
has some issues as I've been discussing with Jon on this thread, but
those issues should be addressable without major changes.
I apologize for the various inconveniences, but I promise that
everything is much nicer under the hood now, and will be easier to
deal with in the future. :)
consiliens
> I apologize for the various inconveniences, but I promise that
> everything is much nicer under the hood now, and will be easier to
> deal with in the future. :)
I appreciate all the work you're doing to mavanize PlayN.
Ray Cromwell
My only comment is that it might better to separate the html and
flash projects (right now, flash stuff is inside of html). In
particular, sometimes I need to stub out or override stuff from
gwt-user by putting a com/google/gwt/user/* package in the flash
project to shadow the default html implementation, and that might
conflict in the future with an HTML build.
-Ray
Michael Bayne
> My only comment is that it might better to separate the html and
> flash projects (right now, flash stuff is inside of html). In
> particular, sometimes I need to stub out or override stuff from
> gwt-user by putting a com/google/gwt/user/* package in the flash
> project to shadow the default html implementation, and that might
> conflict in the future with an HTML build.
Can do!
Michael Bayne
> Can do!
Done. People that recently reimported things into Eclipse will need to
pick up the playn-flash subproject (at a minimum, you may also want to
pick up the new flash sample subprojects). You can do that by simply
running "Import Maven Projects" in Eclipse with the top-level playn
directory and it will detect and import just the new projects.
Then shift-select all of the playn-* projects, and right click on them
and select Maven -> Update Project Configuration... from the
right-click menu, to ensure that the POM changes are propagated into
Eclipse-land (why it doesn't do this automatically, I don't know).
consiliens
Michael Bayne
> I pulled the latest changes and it works! Thank you Michael.
Music to my ears (that it works, though the thanks are also appreciated :).
Neil Voskeritchian
Dorian Manning
Ray Cromwell
latest Android SDK last night and it worked out of the box. Also, try
"mvn -U clean install" to have it force an update check for all of
your dependencies.
-Ray
Joel Webber
Michael Bayne
> ok, it had two errors involving Android/Dex, but they went away on refresh
I've seen those as well. They seem to sporadically show up and then go
away when I refresh. Hopefully Maven or the Eclipse plugin will get
fixed and that little annoyance will go away. I don't think it's a
configuration problem on our end.
Michael Bayne
I wrote a three-part blog post about how much Maven sucks, but I
realized a while ago that it was the best hope for a lingua franca
for, at least, specifying project dependencies.
I then pushed OOO, kicking and screaming, through a tortuous process
of Mavenizing all of our builds, and the other engineers now mostly
agree that it was a good idea. We still script our builds with Ant,
but they get dependency info from POMs via the Maven Ant tasks, and we
no longer have to maintain Eclipse metadata separate from our
Ant/Maven build system.
Quan
jlayer:jlayer:1.0.1
allen_sauer:gwt-log:1.0.r613
allen_sauer:gwt-voices:1.0.r421
com.google.gwt:gwt-flash:1.0
Michael Bayne
where I have added the needed versions of gwt-log and gwt-voices.
Dorian Manning
Thanks, It seems the problem was I hadn't set my ANDROID_HOME variable. However, now I have a new set of problems which are in summary due to my playn imports not being found.
I guess I should mention I am on win 7 64-bit and I know the instruction in the wiki for checkout were for linux, but at this point shouldn't it run on windows with eclipse as well?
Michael Bayne
> I guess I should mention I am on win 7 64-bit and I know the instruction in
> the wiki for checkout were for linux, but at this point shouldn't it run on
> windows with eclipse as well?
Indeed, it should work on Windows with no problems. I have nothing but
a Mac laptop until Thursday, so I can't try a clean import into
Eclipse on Windows, but maybe someone else on the list can check it
out.
Michael Bayne
BTW, where did you have to set that? We should probably add that to
the wiki, rather than assuming people will know that it's part of the
Android SDK/plugin install. Was that only a problem when building from
the command line, or did you need to set it to get things working in
Eclipse as well?
Dorian Manning
I set it as a windows enviornment variable under advanced system settings, following the tutorial for the android maven plug in. Then I had to restart the ide and clean and install to make those errors resolve. I haven't done any of this through commandline yet.
Milutin Jovanović
Miki.
Dorian Manning
Michael Bayne
> Any seen this before and/or know how I should go about fixing it?
I'm going to take a stab in the dark and suggest that you do the following:
% rm -rf ~/.m2/repository/com/google/gwt/gwt-flash
It's possible that you have the old version of gwt-flash cached in
your local Maven repository, and since I didn't update the version
when I copied Ray's update into the old ForPlay Maven repository,
Maven wouldn't know to redownload it.
I'll bump that version to 1.1 soon just to avoid any potential future
confusion for other people who have it cached.
If the above doesn't fix it, let me know and we can dig deeper into
what's going wrong.
Michael Bayne
> % rm -rf ~/.m2/repository/com/google/gwt/gwt-flash
Oh, from the looks of the log, you're running on Windows. The
directory you want to delete (along with all of its contents) is:
C:\Users\Dorian\.m2\repository\com\google\gwt-flash
Michael Bayne
> C:\Users\Dorian\.m2\repository\com\google\gwt-flash
Oops, I mean:
C:\Users\Dorian\.m2\repository\com\google\gwt\gwt-flash
Dorian Manning
Ray Cromwell
It may be due to the way it execs mxmlc flex compiler on windows. Ill try it on a windows box and see I can debug it.
Dorian Manning
Well I think I see why the bug happens but I assumed it was fixed in the next version. One of the flex directories seems to be constructed the wrong way, with slashes going in both directions.
Ray Cromwell
section to point use a backslash. I don't recall, but in maven, and
you do something like ${file.separatorChar} to have this substituted
on a platform by platform basis?
Michael Bayne
> Edit the sample/hello/flash/pom.xml file and change the <extraJvmArgs>
> section to point use a backslash. I don't recall, but in maven, and
> you do something like ${file.separatorChar} to have this substituted
> on a platform by platform basis?
Dorian Manning
Dorian Manning
Michael Bayne
I am resistant to adding this giant wodge of boilerplate to our POM
files. m2eclipse will hopefully fix that annoying bug, and in the
meanwhile it does not cause any problems. It just causes the annoying
warning in Eclipse.
> I am looking at another bug in the hello android project now with the
> message : Cannot add source folder: Duplicate files at the same path inside
> the APK
This generally happens when you build from both the command line and
Eclipse. If you run "mvn clean" then either build from Eclipse or
Maven, it should be fine.
In this case, it sounds like you're using the "Run as -> Maven ..."
targets. That's basically like building from the command line. I
wouldn't recommend using those if you're going to do your builds from
Eclipse. Just use Eclipse's native commands (e.g. "Run as -> Java
application"). Eclipse is already in there messing with things, so you
might as well let it run the whole show.
Michael Bayne
> <logLevel>INFO" -XdisableRunAsync -logLevel "INFO</logLevel>
I'll fix this. It looks like a giant hack, but we can at least avoid
tempting fate by using single quotes.
Ray Cromwell
arbitrary compiler arguments, and still doesn't support something like
<disableRunAsync>true</disableRunAsync>. We can file a bug in the
codehaus issue tracker, but in the meantime, this is an unfortunate
hack. I may be able to patch the flash compiler to not need this.
-Ray
Dorian Manning
Well, that is showing as an actual error in my ide, which also seems to be a problem in the cute and showcase poms. So if there's a way to keep it that way in my local project and keep getting the latest code, I don't mind at all.
As for the duplicates error, I figured out the bit about cleaning before building, but I also added this line to the maven android plugin in the pom:
<extractDuplicates>true</extractDuplicates>
based on what I read here about that problem: https://groups.google.com/forum/#!topic/maven-android-developers/QjbzoaC1Q3k
is this also a bad idea?
As for running maven inside eclipse, I was't sure how to go about to run this with all the option for running maven in eclipse, but I assumed I should at least initially run something a the root of the git repository and at the root of the playn project there are only the "Run as -> Maven ..." targets, so that's where I am at with building this.
Is there no need to run the pom at the root or does that happen automatically when you I run one of the native eclipse commands?
Dorian Manning
Michael Bayne
> Is there no need to run the pom at the root or does that happen
> automatically when you I run one of the native eclipse commands?
There's no need to run anything at the root. Eclipse will
automatically compile everything, and when you run something, you want
to be running one of the sample projects.
So you could, for example, right click on playn-showcase-core and
select Run as -> Java application, then double click on ShowcaseJava,
to run the Showcase sample.