Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (798)
Games in Android Showcase (234)
games submitted by our members
Games in WIP (865)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  Maven: Why bother, and How  (Read 11203 times)
0 Members and 1 Guest are viewing this topic.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 123
Projects: 15


★★★★★


« Reply #30 - Posted 2018-08-28 18:18:58 »

Personally i'm really liking the approach that Jonathan Blow is taking with his Jai Programming Language. The build process is actually part of the language (and written using the actual language). He argues that languages like C++ (and Java by extension) are actually under spec'ed (by not including the build process as part of the specification) and actually demonstrates several pretty cool usages of Jai building his current project using the integrated build process to produce a working executable (the build process even has the ability to specify a game icon for the executable).

A decent video summarising the above and why he took some of the decisions in designing Jai can be found here. He makes some interesting and controversial arguments including some of the problems he considers languages like C++ & Java have. Whether he actually succeeds or not remains to be seen.
Offline nsigma
« Reply #31 - Posted 2018-08-28 19:03:40 »

I think there is a huge difference between gradle, which allows you to write a very small piece of logic as a simple local function

I see you bothered to read the recommended usage guidelines before arguing there was a huge difference then!  Roll Eyes

you mean to configure your build in your own DSL...  Cool Wink

My first thought too!  Cheesy  Not that we're really talking DSLs anyway.  Although I think I like the idea.

@kappa - interesting link - bookmarked for later perusal.

 


Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline KevinWorkman

« JGO Plugged Duke »


Medals: 288
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #32 - Posted 2018-08-29 03:31:50 »

I don't understand what the deal is with Maven. What does it provide that Eclipse doesn't? (Please include some "simple, easy to understand" language before going into technical depth.)

I had similar thoughts when I was first learning Maven. I'm definitely not a Maven expert, but I can maybe provide a bit more context.

If your project does not use any libraries, or if you have an existing setup and nobody else needs to run your code, then Maven is probably overkill.

But if your project does use libraries, or if other people are going to run your code, or if you want to streamline your setup process, that's where Maven comes in handy.

Imagine this scenario: I have a project I've been working on by myself. I use about 10 different libraries, and I keep them all in a lib directory in my project. I'm not sure which version of the libraries I'm using, but that's okay, because whatever I have works. I also have a series of steps that I follow in Eclipse to export everything as an application.

But now I have a friend / coworker who wants to work on my project with me. How do I get them setup? I could just send them my lib directory, but that's not very scalable: what if I actually have 100 coworkers? What if one of the jar files is very large? So I give my friend a list of libraries to download: but wait, what version of the library was I using again? On top of that, how do I transfer over my export settings? Or what happens if I have a possible contributor who absolutely hates Eclipse and wants to use a different IDE?

Enter Maven. With Maven, I no longer need a lib directory full of jar files. Instead, I use a pom.xml file that lists dependencies, and Maven will fetch and add them to my classpath automatically. It will also track versions, so updating which version of a library I'm using is now a one-line change, and everybody will get the new version. I also no longer need to keep track of my Eclipse-specific way of deploying: I just put the build rule inside my pom.xml file, and Maven will take care of that. Now everybody on my team has the same deployment steps.

Here's a real-world example: if I have a web project that I deploy using Google App Engine, I actually need about 50 jar files, an Eclipse plugin, the Cloud SDK, and to run some tools inside the SDK when I want to deploy. Sharing that project is going to be super annoying. However, I can use Maven to keep track of all of that, and deploying is as simple as executing one Maven command.

If I use Maven, will I be giving up all the editing support Eclipse provides? I like my colored underlines and highlights and refactoring options and other goodies. Or is Maven something that one sets up to read from the source code structure that Eclipse also manages?

You can use Eclipse and Maven at the same time. Eclipse actually works very well with Maven. Maven isn't an editor. It's a tool that you can use alongside your editor.

That's actually one of its selling points. If your project is setup using Maven, then you can use any editor your want: Eclipse, Intellij, a basic text editor, whatever.

I have more questions, but will hold them for the moment.

I'm happy to talk about this stuff. I definitely remember being very confused about Maven when I started reading about it.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline h.pernpeintner

JGO Ninja


Medals: 107



« Reply #33 - Posted 2018-08-29 09:54:19 »

I think there is a huge difference between gradle, which allows you to write a very small piece of logic as a simple local function

I see you bothered to read the recommended usage guidelines before arguing there was a huge difference then!  Roll Eyes

Nah, I'm sorry, but I read this guide several times months before this discussion, as well as most other resources available about gradle. And my statements are totally conform to it. My statement was, that gradle allows you to chose the appropriate form and place to write your build logic. I (hopefully Tongue) never said that declarative should not be the very first choice. But I said that it's a fallacy to think that everything has to be a (separately distributed) plugin. In their first example, they show a conditional task definition. This is something that fits into a plugin.

One of their next examples is about minimizing stuff that is done in the configuration phase, with
1  
2  
3  
4  
5  
6  
task printArtifactNames {
    doLast {
        def libraryNames = configurations.compileClasspath.collect { it.name }
        logger.quiet libraryNames
    }
}


They use a local variable to store what they want to log. this is imperative, because the use of a local variable is totally suitable here. If the logic to gather the items to log would take two or three lines and could be reused by another task, there is nothing wrong about just extracting a script local function and reuse it.

In their example, they use the apply plugin syntax, which is not declarative either....that's what I meant with not everything is perfect in every regard, because with complex things, one can't do everything right everytime. And of course, people can misuse code in a build, just like literally everytihng can be abused, but pleease, please let's not talk about abusing features or when to have exceptions from a very strong rule.
Offline princec

« JGO Spiffy Duke »


Medals: 1107
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #34 - Posted 2018-08-29 10:25:53 »

But now I have a friend / coworker who wants to work on my project with me. How do I get them setup? I could just send them my lib directory, but that's not very scalable: what if I actually have 100 coworkers? What if one of the jar files is very large? So I give my friend a list of libraries to download: but wait, what version of the library was I using again? On top of that, how do I transfer over my export settings? Or what happens if I have a possible contributor who absolutely hates Eclipse and wants to use a different IDE?
No, no, no! You commit the lib directory that you use that you know works and that's all there is to it. It doesn't matter how many co-workers you have, or how big the libraries are. Those are irrelevant considerations. What is relevant is a repository that checks out in its entirety from a single location and works, 100% of the time, every time. There is nothing more annoying than trying to build some source code and some dicky network issue breaks the whole damned thing.

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 732



« Reply #35 - Posted 2018-08-29 10:36:09 »

You commit the lib directory that you use that you know works and that's all there is to it. It doesn't matter how many co-workers you have, or how big the libraries are. Those are irrelevant considerations. What is relevant is a repository that checks out in its entirety from a single location and works, 100% of the time, every time. There is nothing more annoying than trying to build some source code and some dicky network issue breaks the whole damned thing.
There is no such thing as 100% availability. No server provider will give you 100% uptime. And you obviously need an internet-accessible server (be it for SCM repository or Maven repository or whatever) when you collaborate with multiple people.
So, from a "get-a-working-build"-perspective, there is no difference between the SCM repository server being down or the Maven repository server being down. Just that the latter is muuuuch much less likely if we are talking about Maven Central. So even if you host your own SCM repo on your own server checking in all libraries, this will have a much worse uptime than a global Maven repository. Even if you take down your own VPS server with the SCM repository just for one minute because you need to install some OS update or whatever, from that moment on it will have a worse uptime than Maven Central.
For example, BitBucket (aka. AWS Cloud North America) has the f**kin' worst uptimes I have ever seen. I have a customer who hosts all their sources on BitBucket and it is a freakin' nightmare. There are outages or timeouts literally eeevery day...

So in the end: You are ALWAYS better off pulling your dependencies from a global Maven repository. And release versions there stay constant/immutable.
Offline princec

« JGO Spiffy Duke »


Medals: 1107
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #36 - Posted 2018-08-29 10:47:16 »

That's absolutely wrong. Our internal SVN servers are 100% reliable (in that even if they explode into flames we can simply restore the live backup onto a new instance - they are located on-site*). When we need to get a build done from scratch onto a clean machine (which happens a fair amount), we need go no further than our LAN. And then we know what is built today is exactly what was built yesterday.

I cannot believe any actual software development company would rely on external servers to be able to build their product? Like, for example Github. Mental. Who on Earth would trust their crown jewels to an external provider? Any sane CIO would be spitting feathers if he discovered it.

Cas Smiley

* Please don't get pedantic on this, we are entirely disaster-proof to my satisfaction

Offline princec

« JGO Spiffy Duke »


Medals: 1107
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #37 - Posted 2018-08-29 10:50:21 »

I've just realised having replied that there may be two entirely different kinds of developers here... there are those like me who work for a software company, whose business it is to make proprietary software and sell it, and we work in offices and have a LAN and trusted vLANs and so on to collaborate with the other offices around the world... and there are those that work on Github/Sourceforge etc sorts of places who are essentially building large collaborative open-source projects and nobody's paying for anything. And yes, I do get why you'd use Maven for that.

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 732



« Reply #38 - Posted 2018-08-29 11:00:55 »

I cannot believe any actual software development company would rely on external servers to be able to build their product? Like, for example Github. Mental. Who on Earth would trust their crown jewels to an external provider? Any sane CIO would be spitting feathers if he discovered it.
Actually, many companies do. First and foremost probably Netflix and Amazon. In this particular case however, it is an international company with many sub-companies around the globe which needed centralized access to a single source repository because it's a more-or-less unified software being worked on from multiple companies.
Hosting it in one company's location was not an option because of multiple reasons:
- no competence in how to professionally host, maintain and secure such a service
- costs would be higher if one did manage to provide such a server compared to using a service such as BitBucket
- people don't need a VPN connection (which is a hassle for most people)
But in the end, I still believe that properly securing and maintaining such a service should not rely on a handfull of IT crowds in a company. There are other services with people much more competent in doing this. And their jobs rely on them doing it well.
Offline cylab

JGO Kernel


Medals: 195



« Reply #39 - Posted 2018-08-29 11:48:40 »

No, no, no! You commit the lib directory that you use that you know works and that's all there is to it. It doesn't matter how many co-workers you have, or how big the libraries are. Those are irrelevant considerations. What is relevant is a repository that checks out in its entirety from a single location and works, 100% of the time, every time. There is nothing more annoying than trying to build some source code and some dicky network issue breaks the whole damned thing.
I am a little bit torn on this one. Getting a working lib directory without some kind of dependency management software like maven or gradle might be a tedious task in bigger projects, so I very much like the declarative style of managing dependencies (and their transitive dependencies). On the other hand I tried to work on a private project while travelling by train which I didn't work on my notebook before. It took me 2h to get it to compile, because I only could download dependencies while staying long enough in a train station :/

Also the size of binary files do matter for some setups. Plain git for example creates full copies of binary files on commit and to make matters worse it also checks out the complete repository inclusive history and all branches of a project on fresh clone. So even deleting a binary file (without deleting it's history) won't help much. I also worked as a DevOp for a very large german company and disk space was very expensive in their infrastructure.

I worked with both - lib folders and maven/gradle dependencies - in the past. Both work, but I usually prefer the dependency style over the lib folder. But since over the last 10 years I was the person that designed, audited and fixed build systems using ant, maven, gradle and jenkins (putting poorly written Jenkinsfiles in the mix is even more fun) for multiple dev teams, I am a bit biased.

Mathias - I Know What [you] Did Last Summer!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nsigma
« Reply #40 - Posted 2018-08-29 11:59:07 »

I've just realised having replied that there may be two entirely different kinds of developers here... there are those like me who work for a software company, whose business it is to make proprietary software and sell it, and we work in offices and have a LAN and trusted vLANs and so on to collaborate with the other offices around the world... and there are those that work on Github/Sourceforge etc sorts of places who are essentially building large collaborative open-source projects and nobody's paying for anything. And yes, I do get why you'd use Maven for that.

Use of Maven (or similar) is orthogonal to your argument.  If you need your dependencies on your own infrastructure then you host your own maven repository?!  Surely still an improvement over putting them in a source code repo.

Oh, and if you're using something like Sonatype, someone is probably paying quite a lot for things!  Wink

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline h.pernpeintner

JGO Ninja


Medals: 107



« Reply #41 - Posted 2018-08-29 13:09:45 »

Exactly @ nsigma.

One could even have every developer run a local repository (or a flat file repository) and one can still benefit from other things maven gives you - transitive dependencies ware already mentioned. Dependency management without descriptors and a tool that lets you do excludes and forced failure on version conflict is...yea..i dunno. Impossible, senseless, insane? In addition to the problems one gets with binaries in git repositories, as cylab already stated.
Offline princec

« JGO Spiffy Duke »


Medals: 1107
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #42 - Posted 2018-08-29 13:18:40 »

Another reason why Git is a bit shit compared to Subversion btw...

Cas Smiley

Offline h.pernpeintner

JGO Ninja


Medals: 107



« Reply #43 - Posted 2018-08-29 14:47:16 »

Sometimes I get the impression that hijacking threads with even more rants about totally unrelated topics is exactly your thing prince.

Git has other advantages over subversion that are more relevant for the vast majority of source code projects, where the only binary artifacts one cares about is dependencies. And if you store your binaries in your source code repository, you're doing it wrong, simply put (*). Dependency management is often about updating minor versions, having updates on patch versions of transitive dependencies, splitting things up code in modules. If you put every version of every dependency in your source code repository than... no... i don't know what to say if it's not clear by now.

Back to topic: Maven enables dependency management. Independently where and how your repositories are located. Dependency management is an undeniable requirement for nearly every software developing company out there for sure.

(*) Really no one on earth is interested in 0.0001% of developers that might have a few good reasons to be the special snowflake here.
Online jonjava
« Reply #44 - Posted 2018-08-29 16:08:36 »

I really hate bloated and complicated configuration tools. If you possibly can just stick to makefile's and the like.

Configuration hell is a thing and the favourite weapon of office warriors for political gerrymandering and filibustering. This can be especially bad in Enterprise projects where 80% of the time is spent doing nothing.

Love this quote: "If you don’t actively fight for simplicity in software, complexity will win.

…and it will suck."

Also @princec concerning git: lies!

Offline princec

« JGO Spiffy Duke »


Medals: 1107
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #45 - Posted 2018-08-29 16:24:42 »

Games development is not a special snowflake case (especially on this board!) and it's also the case that generally requires binary files that are several orders of magnitude larger than the source code. Git is a terrible choice for games development (which is why nobody in the industry uses it).

Cas Smiley

ps. I like rambling threads

Offline nsigma
« Reply #46 - Posted 2018-08-29 17:38:24 »

Games development is not a special snowflake case (especially on this board!) and it's also the case that generally requires binary files that are several orders of magnitude larger than the source code.

There are options for storing large binary files in (well, kind of with) Git.

That's kinda orthogonal (I'm liking that word today  Wink ) to the shit idea of putting dependencies in source control.  persecutioncomplex

ps. I like rambling threads

Well, that's lucky!  Grin

PS. all PraxisLIVE dependencies are currently in source control!

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1107
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #47 - Posted 2018-08-29 19:08:48 »

If you think of it instead as "project repository" rather than just "source" it makes a lot more sense. It's worked very, very well for us for the last 20-odd years making Java games, and latterly a Unity one.

Bringing this thread screechingly back on subject, we developed an Ant script or three that reliably builds all of our games on all of our target OSes for all of our target platforms. We even have JVM binaries in SVN, as well as NSIS binaries for Windows builds, etc. When confronted with a brand new development machine we only need to install the JDK and Eclipse and the Subversive plugin, check out the repo, and whack Ant and out comes everything ready to upload to Steam etc etc. without actually having to remember to do anything else. I really don't like the Ant build script, because it's a really daft way of saying "do this, then this, then this" and I'm not really sure why anyone would ever design such a system to work that way when they wanted to do a build. It reminds me of that old joke about the toaster, the king, a software engineer and a hardware engineer.

Scar really does seem to be a great solution to what should be a really, really trivial problem. It's not even complicated to have made - any one of us could have written Scar in its entirety in an afternoon - but there it is, already made. I think it's definitely worthy of investigation.

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 732



« Reply #48 - Posted 2018-08-29 19:17:30 »

Wouldn't it then be best to also check a JDK and Eclipse into Subversion to have a really reproducible development environment? I mean, how do you ensure that new developers get productive when oracle or eclipse.org are down? Tongue
Offline cylab

JGO Kernel


Medals: 195



« Reply #49 - Posted 2018-08-29 20:13:44 »

In case it wasn't brought up. A benefit of using gradle is that it is importable by any (decent) IDE out there.

Also gradle has the concept of a gradle wrapper script with a .gradle folder in your project, so you can self contain the whole buildsystem in your "project repository". You can also specify file dependencies or set up a flat files repository to look for your dependencies in a local (in-project) folder.

Another option would be to modify the gradle home directory using the -g option (e.g. in the gradlew script) to have the gradle cache inside your "project repository" as well, so you could have online bound dependencies that also work offline from a fresh checkout.

So if you want to have it the static way, you can have it with gradle, too - with the added benefit of being able to import the project to any IDE and being able to script some parts of the build in a "real" programming language...

Mathias - I Know What [you] Did Last Summer!
Offline ral0r2
« Reply #50 - Posted 2018-08-30 13:08:54 »

Games development is not a special snowflake case (especially on this board!) and it's also the case that generally requires binary files that are several orders of magnitude larger than the source code. Git is a terrible choice for games development (which is why nobody in the industry uses it).

Cas Smiley

ps. I like rambling threads

I think this article sums up some intresting points regarding this topic in case anyone is interested:
http://enemyhideout.com/2016/06/why-git-is-not-good-for-games/

Wouldn't it then be best to also check a JDK and Eclipse into Subversion to have a really reproducible development environment? I mean, how do you ensure that new developers get productive when oracle or eclipse.org are down? Tongue

In case anyone really wants to do this (regardless of seriousness of the quote) please make sure that you are using OpenJDK and not Oracle JDK because redistributing a modified Oracle JDK is violating their licence.

Take a look at section C which states:

“Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs…”
Source: http://www.oracle.com/technetwork/java/javase/terms/license/index.html

Take a look at the following link what you need to consider when redistributing Oracle JDK (example Java8):
http://www.oracle.com/technetwork/java/javase/jdk-8-readme-2095712.html#redistribution

PS: sorry for posting offtopic but I felt like shedding some light on this might be useful for anyone who did not know yet.
Offline h.pernpeintner

JGO Ninja


Medals: 107



« Reply #51 - Posted 2018-08-30 14:02:56 »

Thank you for being offtopic, the article you linked is very interesting!
Offline nsigma
« Reply #52 - Posted 2018-08-30 14:22:03 »

In case anyone really wants to do this (regardless of seriousness of the quote) please make sure that you are using OpenJDK and not Oracle JDK because redistributing a modified Oracle JDK is violating their licence.

Luckily soon to be a thing of the past!  Smiley  And even so, it depends what you mean by modified too - there's stuff you can modify (remove) within the terms of the license.  And there was the old SE 8 compact profiles.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline KevinWorkman

« JGO Plugged Duke »


Medals: 288
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #53 - Posted 2018-08-31 05:40:22 »

No, no, no! You commit the lib directory that you use that you know works and that's all there is to it. It doesn't matter how many co-workers you have, or how big the libraries are. Those are irrelevant considerations.

Like many things in programming, this comes down to context and preference. What makes sense for one person or team might not make sense for another person or team, or the same person or team at a different time.

It's not as simple as saying "Maven is always good" or "Maven is always bad". Maven is a tool with its own pros and cons, just like any other tool.

I've been in codebases where Maven was overkill. I've also been in codebases that used the "just use this folder of jars" approach to dependency management. The directory of jars might work for small projects, but if you have dozens of people working on it over 10+ years, eventually this becomes unwieldy.

"Okay time to deploy... wait why do we have two versions of this library in here? Which jar do I actually need? Oh great, that jar actually contains other libraries..."

Back to OP: like I said, if your setup works for you, then that's cool. Nobody is going to force you to use Maven. But if you want to understand how it works, I suggest using it with the next hello world program you put together. You might find out that you like that workflow better.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline philfrei
« Reply #54 - Posted 2018-08-31 06:16:10 »

Thanks Kevin!

For my own projects, at this stage, Eclipse is quite enough.

I suspect that letting AudioCue get mavenified on the GitHub site was not a good move. It is a small library. If someone wants to use it with Maven, I'm sure it would be quite easy for them to make the needed changes. Better that than for someone who is making smaller scale applications to wonder wtf do we need to have the code buried under 6 or 7 file folders. If I recall, TinySound hasn't been given the Maven treatment and it is still in use. I am debating whether to roll that back.

Reading all the digressions and conversation has been interesting. Am happy to have stimulated a good discussion even if a fair bit is over my head and slightly off-topic.

I'd like to put in that we keep in mind that there are Java coders at all sorts of levels and with all sorts of goals here. You don't have to be a super capable programmer to design and code a terrifically popular game or application (or maybe well-loved by a few but still worthwhile). There are other factors, many being quite mysterious. The code is a means to realize an idea, and Java remains quite sufficient, it seems to me.

music and music apps: http://adonax.com
Offline nsigma
« Reply #55 - Posted 2018-08-31 07:47:33 »

I suspect that letting AudioCue get mavenified on the GitHub site was not a good move. It is a small library. If someone wants to use it with Maven, I'm sure it would be quite easy for them to make the needed changes. Better that than for someone who is making smaller scale applications to wonder wtf do we need to have the code buried under 6 or 7 file folders.

Except there's a somewhat different question in there. Using and publishing to Maven Central is a useful way to distribute a library. And it doesn't stop people just grabbing the JAR or source. Of course, learning and configuring the publishing process is "fun". But that's also where the benefit of Mavenizing a library is.

Mind you, it actually appears to have been Gradle-ified!  Smiley

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline philfrei
« Reply #56 - Posted 2018-08-31 17:14:59 »

...

Mind you, it actually appears to have been Gradle-ified!  Smiley

Goes to show how removed I am from both, to get them mixed up like that.
 Clueless

music and music apps: http://adonax.com
Offline cygnus
« Reply #57 - Posted 2018-08-31 18:52:49 »

To provide a small amount of my own thoughts: for a long time, I just used the built in build system of IntelliJ IDEA. However, I wanted to add the kotlinx-coroutines library, and there was no easy way to download the jar file and put it in as a library. They suggested gradle, and so after a lot of playing around, I migrated everything. It has come in handy a few times--say I want to show off the latest build of my game, but I'm on a different computer. I just download the git repo and run ./gradlew build, and bam, it's up and running.

It's not the worst thing to avoid build systems, but they have a bunch of benefits and few downsides. The only thing I didn't like was moving everything to src/main/kotlin.
Offline princec

« JGO Spiffy Duke »


Medals: 1107
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #58 - Posted 2018-08-31 19:31:19 »

The thing I mostly hate is XML, closely followed by half-assed DSLs.

Cas Smiley

Offline cylab

JGO Kernel


Medals: 195



« Reply #59 - Posted 2018-09-01 08:31:27 »

The only thing I didn't like was moving everything to src/main/kotlin.
You don't have to do that. You can just specify the location of your sources via sourceSets.main.kotlin.srcDirs = [“some-path“]

Mathias - I Know What [you] Did Last Summer!
Pages: 1 [2] 3
  ignore  |  Print  
 
 

 
Riven (87 views)
2019-09-04 15:33:17

hadezbladez (4365 views)
2018-11-16 13:46:03

hadezbladez (1558 views)
2018-11-16 13:41:33

hadezbladez (4503 views)
2018-11-16 13:35:35

hadezbladez (876 views)
2018-11-16 13:32:03

EgonOlsen (4165 views)
2018-06-10 19:43:48

EgonOlsen (4870 views)
2018-06-10 19:43:44

EgonOlsen (2809 views)
2018-06-10 19:43:20

DesertCoockie (3715 views)
2018-05-13 18:23:11

nelsongames (4015 views)
2018-04-24 18:15:36
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45
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!