Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Maven  (Read 3445 times)
0 Members and 1 Guest are viewing this topic.
Offline kevglass

JGO Kernel


Medals: 169
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Posted 2004-12-10 09:11:09 »

http://maven.apache.org/

Started a new job and everyone here is using Maven to manage their projects.. Anyone had any experience with it?

Kev

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2004-12-10 09:47:21 »

I haven't, but I've evaluated it a couple of times (and that's why I've never used it). Initial impressions were:

- it's another apache project that re-invents several wheels and provides an incomplete implementation of them
- ...and, just like many apache projects, "could be really good if they ever finished it"
- ...and, just like many apache projects, seems to have only two USP's: one: it uses XML extensively albeit naively (monolithic XML files), two: it is sort-of integrated with all the other apache projects

EDIT: this sounds more negative than intended. I'm not saying it's bad, just that I could find nothing to recommend it over what other options are out there. I'm a bit depressed that this happens often with Apache projects. Even more so that so many apache projects look really good, and then the longer you use them the more you discover how crap they truly are. The last 3 major Apache projects I used (not small things!) had bugs so severe they were almost unusable, or were missing some of their own major features. Basic stuff didn't work Sad.

To quote from their site:
"use of a central repository of JARs. Maven comes with a mechanism that your project's clients can use to download any JARs required for building your project from a central JAR repository much like Perl's CPAN. "
- Um. Guys. Why replace webstart with a CPAN-clone, given that CPAN was pretty crap? (although, when it first came out, a lot better than the alternative!)

" The biggest bang for you buck right now is the generation of your site documentation."
- what? That's *all*? Well, why not just use one of the dozen or so open-source project-mgmt apps that run on top of wiki's and integrate:
 - project schedules
 - documentation
 - ANT builds
 - public website
 - team-organization tools (discussion groups, mailing lists, etc)
...which all come with much nicer GUI's and usually more features too. And, with a Wiki (or similar) underlying them, powerful and easy to extend.

So, each time I evaluated it, I came away with the feeling:

  "It's re-inventing stuff that's already done just as well or better elsewhere, yet it's less mature, and it's ignoring the opportunity to integrate pre-existing components that could make it into something unique and wonderful. In the apache world, if a project you could have integrated with isn't part of jakarta, then it doesn't exist as far as you're concerned..."

I only ever tried the examples, went through the quickstart guides / whatever intro stuff I could see / etc. I'd love to know what it's like on a group of major projects, but I doubt it could make up for the massive drop in functionality if I ever moved away from Vesta Grin so I doubt it will ever grab me now.

malloc will be first against the wall when the revolution comes...
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #2 - Posted 2004-12-10 09:53:50 »

I'm using it daily.

It's ok, has some nice features, can generate a lot of useless things.

Needs a *lot* of infrastructure! Documentation is poor.

Zillions of plugins, goals and properties and conventions.

Very powerful but complex.

I like it and I dislike it.

Interaction with IDEs is quite good.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline phazer

Junior Member




Come get some


« Reply #3 - Posted 2004-12-10 12:56:05 »

I use Ant to build compile classes, build Jar files, generate Javadoc, copy source code etc. Are there any benefits of using Maven for such simple tasks? I don't need a central repository for Jar files. Smiley

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #4 - Posted 2004-12-12 14:34:37 »

Yeah, I've used it quite a bit - it's fantastic.  I see no value in writing Ant scripts these days - Maven takes care of all that for you.  I won't start any new J2EE application without using Maven; it saves a lot of time and hassle, and allows you a lot of flexibility for the future.

My only complaints:
  • Sun libraries aren't in the repository, due to licencing restrictions - a bit of a pain.
  • From my experience the devs aren't super-proactive in handling bug reports.
  • Doesn't currently come bundled with Eclipse.


But to counter these complaints:
  • It's really, really easy to set up a local repository with anything extra you want.
  • It's really stable - most of my bug reports were either RFEs or cosmetic problems.
  • Meh.  A little more work required to get things integrated.


Edit: Technically, I guess I'm a Maven contributor... I fixed their timezone-calculating JavaScript functions. Grin

Hellomynameis Charlie Dobbie.
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #5 - Posted 2004-12-12 14:39:29 »

Quote
I use Ant to build compile classes, build Jar files, generate Javadoc, copy source code etc. Are there any benefits of using Maven for such simple tasks? I don't need a central repository for Jar files. Smiley


If you've already got the scripts working, probably not.  Although I'm not sure why you're using Ant either - doesn't your IDE provide all that?

From my experience, Maven is best used on a project with multiple developers, that needs some kind of public presence (either for third-party developers or for project managers) - although I've even found it useful on a solo project where the deliverable was all that mattered.  YMMV and all that.

Hellomynameis Charlie Dobbie.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2004-12-12 14:47:33 »

Quote
I won't start any new J2EE application without using Maven; it saves a lot of time and hassle, and allows you a lot of flexibility for the future.


Exactly what/why/where does it save all this time and hassle?

Your followup post suggests it's the "maintaining the public image of the project" part. Is that the main selling point for you?

malloc will be first against the wall when the revolution comes...
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #7 - Posted 2004-12-12 22:26:03 »

Quote
Exactly what/why/where does it save all this time and hassle?


For me, Maven provides three things:

The automatic download and installation of dependent libraries means trivial setup of new build environments, it severely cuts down on versioning problems between developers, and means all versioning information is in one place (ever spent time trying to work out what version of Xerces you're running?)

The pre-written goals are almost certain to function properly (as many other people have already tested them), they sometimes make adding new technology to a project trivial (as someone has already written goals to handle it), and stop me from having to write yet another Ant script with yet another collection of filesets and classpaths that potentially need to be updated every time a resource moves or changes format, or a class changes package.

Automatic site documentation means I can very easily keep my Javadoc up-to-date, provides a complete web-browsable, hyperlinked, syntax-highlighted copy of the source code, and provides easy-to-read task lists, warnings lists etc.

Quote
Your followup post suggests it's the "maintaining the public image of the project" part. Is that the main selling point for you?


Depending on the project, company, and management style, project documentation may be utterly ignored, occasionally viewed, or rabidly sought after.  It's very handy that Maven can produce a huge amount of information, with very little effort.

Hellomynameis Charlie Dobbie.
Offline kevglass

JGO Kernel


Medals: 169
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2004-12-13 04:21:55 »

Having been here a week now I'm starting to understand what you're getting at. Across this company you get all sorts of IDEs (read VIM in some cases), different operating systems and plenty of machines.

Maven allows them to have a common format describing their projects and be able to morph it into what ever they need when they need it with minimal hassle.

Seems pretty neat so far..

Kev

Offline phazer

Junior Member




Come get some


« Reply #9 - Posted 2004-12-13 06:43:28 »

Quote


For me, Maven provides three things:

The automatic download and installation of dependent libraries means trivial setup of new build environments, it severely cuts down on versioning problems between developers, and means all versioning information is in one place (ever spent time trying to work out what version of Xerces you're running?)


How is this better than just pointing to the libraries using a classpath? I don't need automatic downloading of Jar files from the net.

My IDE can probably build and sign Jar files, create JavaDoc etc. but it's nice to have an Ant task that does all that for you in one run.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2004-12-13 07:49:59 »

Quote


For me, Maven provides three things:

The automatic download and installation of dependent libraries means trivial setup of new build environments, it severely cuts down on versioning problems between developers, and means all versioning information is in one place (ever spent time trying to work out what version of Xerces you're running?)


No, I haven't - because I have a decent build system to start off with, that ensures that's never ever a problem.

What you describe in this paragraph is the bread and butter of any build system, so assuming you are actually using one, it's not an issue.

Quote

The pre-written goals are almost certain to function properly


Could you explain a bit more about what these are?

Quote

Automatic site documentation means I can very easily keep my Javadoc up-to-date, provides a complete web-browsable, hyperlinked, syntax-highlighted copy of the source code, and provides easy-to-read task lists, warnings lists etc.


Javadoc does the docs in one line.

Showsrc does the syntax highlighting in one URL.

If you have a decent issue-tracking system then it will do much more powerful management of task lists. I wouldn't say Bugzilla is excellent, but it's decent and free and presumably a lot more widely tested than Maven?

This is what I meant when I said everything *seems* (to me as an outsider) to be done better already elsewhere. You seem to be painting a picture of the whole being more than the sum of the parts, but...I've never had difficulty integrating any of the things mentioned so far, except for build system + issue-tracking system (I would really like a trivial config option so that each build would automatically produce a list of the bugs/rfes/etc that were fixed in that build, and even output a summary a la Sun's JVM "bugs fixed in this JVM" list).

I'm pretty sure I can do that myself, I just need to write two scripts which I think I know everything I need for ... but, obviously, not having to do it at all would be rather nice!

Yet...Maven doesn't transparently plug in to other build systems, does it? And does it interface trivially with existing issue-trackers? I mean, there's no way I would sacrifice my build system (which kicks the pants of everything else that's free) nor would I move away from Bugzilla to anything free (there's a lot of non-free issue trackers that are considerably better than BZ, some as cheap as just a thousand dollars or so, but in the free world BZ gets all the dev time and is much more mature than the rest...).

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 169
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #11 - Posted 2004-12-13 09:34:06 »

The key difference in this respect seems to be the number of developers/platforms/IDEs/etc.. that are in use. Maven is really a framework to support everything.. does seem to be fairly useful although interestingly here (at work) the opinion seems to be split aswell.

Kev

Offline JasonB

Junior Member





« Reply #12 - Posted 2004-12-13 18:10:21 »

Opinion seems split everywhere...   Grin
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #13 - Posted 2004-12-14 08:02:40 »

Quote
How is this better than just pointing to the libraries using a classpath?


Well, if you want to upgrade a library, for instance, I guess you go to the library's website, download it, put it in the right place, possibly change your CLASSPATH env var or your build script to point to it etc.  Then you tell all your fellow developers to do the same (unless you've been a little more clever and have the libraries in version control).

In Maven you just change the version number in your project.xml.

Hellomynameis Charlie Dobbie.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #14 - Posted 2004-12-14 08:55:43 »

Quote


Then you tell all your fellow developers to do the same (unless you've been a little more clever and have the libraries in version control).

In Maven you just change the version number in your project.xml.


*exactly*: any decent build tool automates this to a two-step process (obtain files, alter build script).

What happens when the new version breaks existing code? Does it just mean that people's projects stop building, and they have to go and find out by hand which library was updated?

Can they "downgrade" the library just for their project?

(this is the kind of functionality built-in to a standard build tool, so I'm just checking if Maven keeps up Smiley)

malloc will be first against the wall when the revolution comes...
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #15 - Posted 2004-12-14 09:06:41 »

Quote
What you describe in this paragraph is the bread and butter of any build system, so assuming you are actually using one, it's not an issue.


Well, yes.  But how many people here are using build systems that keep track of things like library versions for them?  I think that's pretty advanced, really, considering most people here are probably either using Ant or their IDE.

Quote
[Pre-written goals] Could you explain a bit more about what these are?


Well, if you're setting up an Ant script to compile source code, you need to write a javac task, setting the right srcdir, destdir, classpath etc, working out the right dependencies etc.  Maven's already done this for you - you just type "maven java:compile".

Equally, goals have been written for all kinds of things.  Want to add a new tool to your build system?  Try typing "maven <tool>" and see what happens.  More often than not, I've found everything already in place.  Naturally, if you ask Maven to start working with a new tool, it'll go and acquire all the required libraries itself.

If it's a third-party tool, download the Maven plugin, chuck it in the plugins directory and start using it.  If that tool's libraries aren't in the central Maven repository, you might need to add an entry in your project.properties to point to the project's own repository.

Quote
Javadoc does the docs in one line.


Yes, but you need to type that line, and create a task for it, yadda yadda yadda.  Try typing "maven javadoc".

Quote
Showsrc does the syntax highlighting in one URL.


Non-hyperlinked, requires network access, and works on a per-file, per-request basis?  That's no comparison.  I think you're being difficult! Tongue

Isn't this a little more useful?

Quote
If you have a decent issue-tracking system then it will do much more powerful management of task lists. I wouldn't say Bugzilla is excellent, but it's decent and free and presumably a lot more widely tested than Maven?


Well, of couse you use Bugzilla as your issue tracking system - Maven is a build tool, it won't replace that.  However, Bugzilla won't go through all your code finding all the "TODO" comments and creating a readable list of them for the website.  Maven will.

Quote
I've never had difficulty integrating any of the things mentioned so far


Sure, but it's probably easier to just download Maven-1.0.2.exe and double click it. Wink

Quote
I mean, there's no way I would sacrifice my build system


Well, if you say you'll never sacrifice your build system, it seems a bit unnecessary to give that as a reason not to use a different build system...

Hellomynameis Charlie Dobbie.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #16 - Posted 2004-12-14 09:37:15 »

Quote

Well, yes.  But how many people here are using build systems that keep track of things like library versions for them?  I think that's pretty advanced


Point taken. But...ignorance of what else is available isn't a justification for adopting something inferior (*if* it's inferior...I'm talking theoretically here; jury's still out w.r.t. Maven as far as I'm concerned)

Quote

(goals)


Ah! See what you mean now. Sorry, just a difference in terminology. I should have guessed that myself.

Quote

Equally, goals have been written for all kinds of things.  Want to add a new tool to your build system?  Try typing "maven <tool>" and see what happens.  More often than not, I've found everything already in place.


Right. This is one of my long-standing bones of contention with the Apache/Jakarta projects. *if* this worked perfectly, it would be very useful and rather wonderful. It would, at the same time, be a holy pain in the arse for everyone involved because Apache's projects are not and never will be a global standard; however, it's perfectly possible that Sun would (again?) cherry pick bits to clone into java. They might even simply deal with the Maven people directly and work together to migrate it into Sun's "official" tehcnologies (e.g. elevated to the status of webstart).

However...the reality is that Apache projects keep trying to do this "we're Microsoft, we'll integrate everything in our own unique proprietary way, and make it 'open' and pretend to ourselves that tthat's all it takes for everyone in the world to adopt it", but...in reality, what happens is that adoption is mediocre. *on the surface* there are "thousands of plugins", but when you use them in anger you find that they're all the "minimal implementation theoretically possible" and are often completely useless: what they "integrate" is the stuff you could have done yourself in 5 minutes with a shell script *without* any of the apache stuff, yet what they completely sidestep is the complex, high-level integration of some feature or config that you desperately wanted to avoid having to do for yourself.

</rant></bitter>.

I have been bitten by this on more than one occasion. For an example, look at Log4J. They tout the huge number of plugins as a major reason for using it over alternatives; when you start trying to find plugins, you quickly shatter the illusion and discover that most of them do the same thing as each other and are toy projects. There's a *few* (literally: just a handful) of plugins that are genuinely and widely useful, but really they're just stuff that you assumed was going to be part of the core distribution anyway.

Quote

Yes, but you need to type that line, and create a task for it, yadda yadda yadda.  Try typing "maven javadoc".


Once. Once in your entire life. Is that so hard?

Quote

Non-hyperlinked, requires network access, and works on a per-file, per-request basis?


Point taken; it's been sufficient for my needs so I've never bothered to try finding a better one. It happened to be the only easy-to-use and feature rich one I knew off the top of my head, and I wanted to give real examples to make the point.

Quote

Well, of couse you use Bugzilla as your issue tracking system - Maven is a build tool, it won't replace that.


But...this is surely the raison d'etre of Maven: to integrate the disparate parts of the project tools suite?

Instead of saying "let's integrate the best of breed" they're saying "let's re-invent our own proprietary inferior clones of the existing tools, because then the work of integration is trivial". Which is silly: they're just shoving the "hard" task elsewhere (instead of integrating complex software, they're going to have to *write* complex software).

Quote

 However, Bugzilla won't go through all your code finding all the "TODO" comments and creating a readable list of them for the website.  Maven will.


FYI I find that deeply unimpressive. I could write code to do that myself in ... about 10 minutes, that could be used on any project (iterating through plain text files looking for lines with TODO on them is trivial, and then you pump it to XML, and can style and re-style it into HTML to your heart's content)

But...this http://jtidy.sourceforge.net/junit-report.html I find extremely useful. Although, what we're really looking at here is (or should be) a plugin for Junit (which has a plugin architecture to do this sort of thing), which could be used by anyone without using Maven.

Quote

Well, if you say you'll never sacrifice your build system, it seems a bit unnecessary to give that as a reason not to use a different build system...


Sorry. I meant "never sacrifice the features provided by my existing build system". I.e. I've got a good (maybe not best-of-breed, but certainly high quality, high performance, feature-rich, well maintained) build system - why  downgrade to something that is a lame clone without most of the useful features?

This is what I don't understand about apache projects: the insistence on using/re-inventing their own wheels all the time, when they could actually do the whole world a favour by re-using far far superior systems and integrating them. Huh

malloc will be first against the wall when the revolution comes...
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #17 - Posted 2004-12-14 09:44:37 »

Quote
What happens when the new version breaks existing code? Does it just mean that people's projects stop building, and they have to go and find out by hand which library was updated?

Can they "downgrade" the library just for their project?


Oh, blimey - no reason to do that.  All library versions are separate, you'll never stomp on someone else's project.  Otherwise how would you ever compile up an old version of the project from version control?

Hellomynameis Charlie Dobbie.
Offline jojoh

JGO Knight


Medals: 5
Projects: 7


games4j.com


« Reply #18 - Posted 2004-12-14 11:17:03 »

We have recently started to work with Maven at work, and I see a lot of both positive and negative in that. Previously we really didn't use any build tool other than what's provided by Eclipse, CVS and a few plugins. So for us it was quite necessary to use something.

At home on my private game dev, I still use IntelliJ and ANT and see no reason to change that. I have an ANT script-template that I use. I basically drop all src, libs and resource in a separate folder, change ANT script with the name of project and web dest of where I want to upload the webstartable stuff and that is pretty much it. A dbl-click and ANT will build, create java docs, make jar, obfuscate, backup src to zip-file, package deployment jar for offline/e-mail deployment, create webstart files and upload to web host (or just a subset of this), all with version number. Work overhead is very small, and I have a powerful enough build system.

At work we previously had a few e-mails every week saying "Add foo.jar and bar.jar to your classpath". Everybody had to do this update, and half of the time you forget it until your build don't work. With Maven, you will just add the necessary jar to our local repository, and specify that in a xml-file and commit to repository. When the rest of the team-mates updates anything dependent on that project or that project itself, the new/updated jar is automatically downloaded by maven!

With cruise-ctrl installed you will also be sent an e-mail stating that you messed up a build if you for example forgot to commit in a crucial file to CVS out of all the 50 you made updates to. Also typical thing that happened weekly before.

We also have several different modules that a customer may or may not want to have/buy. Maven helps with the management of all these different modules.

Other build tools can probably do the above, but maven seems to do it very well, even though I agree with some of the complaint mentioned previousley in thread.

These are just the key benefits for each approach for me. I would use ANT for one man small project, since it means no extra work for me and Maven for bigger projects with multiple coders, since it removes some of the problems that it involves.

Hope this was of some use

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #19 - Posted 2004-12-14 11:42:30 »

Quote

I have an ANT script-template that I use. I basically drop all src, libs


Howabout sharing that script? We'll have an area on JGF soon where you can share short chunks of source code around on a "you can do anything you like with this" license.

Quote

When the rest of the team-mates updates anything dependent on that project or that project itself, the new/updated jar is automatically downloaded by maven!


Sounds like what I was asking about, yet cfmdobbie said it didn't do that...?

Quote

you messed up a build if you for example forgot to commit in a crucial file to CVS out of all the 50 you made updates to. Also typical thing that happened weekly before.


Well...if you still use CVS then to be honest it's your own fault Tongue. Really, CVS is barely halfway to being an SCM, if that.

<smug>Of course, with vesta, when you check in it builds the code immediately (or vice versa), so you have to try quite hard to deliberately check in without compiling (or do a "partial check-in" which means "work in progress, but I'd like to checkpoint it temporarily"</smug>

Quote

Hope this was of some use


Yup. Testimonials with detailed post-mortem descriptions are the best way IMHO of evaluating any new dev tool.

malloc will be first against the wall when the revolution comes...
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #20 - Posted 2004-12-16 09:53:09 »

Quote

Quote
When the rest of the team-mates updates anything dependent on that project or that project itself, the new/updated jar is automatically downloaded by maven!

Sounds like what I was asking about, yet cfmdobbie said it didn't do that...?


Maybe I wasn't entirely clear...

Maven fully understands versioning of libraries, and expects that all libraries have a group name (company/team), a library name, and a version number.  In your project.xml you define dependencies in terms of these three criteria, and Maven (if necessary) fetches the appropiate jar, uses it in builds, bundles it in releases etc.

One project may depend on ORO 2.0.8; another project could be using ORO 2.0.7.  These don't conflict.  Maven acquires both of them (as and when necessary), and uses the appropiate one at the appropiate time.

If Developer A upgrades a project from 2.0.7 to 2.0.8, he updates the project.xml, and commits any code changes.  When Developer B runs an update, they receive the project.xml and the source code changes.  They then do something with the project - compiling, for instance; when Maven sets things up to use the right library versions, it notices that 2.0.8 isn't in Developer B's local repository, and acquires it.

At no time does a library change versions without the express intention to do so.  At no time does an old project break because of a new project.

Hellomynameis Charlie Dobbie.
Offline rreyelts

Junior Member




There is nothing Nu under the sun


« Reply #21 - Posted 2004-12-16 19:42:40 »

Quote
Across this company you get all sorts of IDEs (read VIM in some cases)

Heh, my editor of choice. Smiley

In terms of different IDEs and such, we're in the same boat here. We use VIM, Eclipse, Netbeans, Textpad, IDEA, etc... We seem to get by with Ant just fine.

God bless,
-Toby Reyelts

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (38 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (42 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (61 views)
2014-09-21 02:42:18

BurntPizza (31 views)
2014-09-21 01:30:30

moogie (36 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (53 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!