Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (775)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (856)
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 6053 times)
0 Members and 1 Guest are viewing this topic.
Offline philfrei
« Posted 2018-08-24 17:42:55 »

I have been doing okay with Eclipse, until the new modular Java arrived, for my projects. I'm assuming in 6 months or so (if they haven't already done so) the folks at Eclipse will catch up and things will be fine again.

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 posted a project on GitHub and a helpful Maven enthusiast added a bunch of file folders making the simple project have twice as many layers. I'd prefer not to let go of my backwards URL + projectname package structure as a way to reduce what seems to be needless folders. I let the change stand. But I don't understand the tradeoffs, and I am reluctant to devote however much time to learning yet another tool just to find out if I really need it or not.

Is Maven something that one uses along with Eclipse?
 
If someone convinces me Maven is better or worth switching to, are there some guidelines or suggestions about how to convert from one environment to another?

Call me clueless. That's okay. It's true about somethings, and not about others where I have put in considerable effort and have shared what I learned. (Continues to be in grumpy mood.)

Thanks in advance.
 Cool

music and music apps: http://adonax.com
Offline nsigma
« Reply #1 - Posted 2018-08-24 17:52:09 »

What does it provide that Eclipse doesn't?

What does Eclipse provide?  I'm assuming it doesn't have its own bespoke build system?!  I'm assuming Ant by default?

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

JGO Kernel


Medals: 637



« Reply #2 - Posted 2018-08-24 17:58:11 »

Nah, I am assuming @philfrei just clicks on Export > as Runnable Jar (+ extract build path dependencies into JAR), which is fine for all non-collaborative/non-continuous-built/non-continuous-integrated/non-continuous-deployed projects that also no one depends on as a library.

But as soon as you must omit the "non-" from any of the words above, a dedicated command-line-executable build system (which is not your IDE) becomes a necessity. In short: You do not want people to install Eclipse just to build your project. I always HATE it when I see GitHub projects checking in their .classpath/.project files with possibly absolute file path references to the Jar files in a C:\Users\SomeUser\Downloads\some.jar file.

But in short: When you ask why you need Maven and you need people to tell you the advantages, then you don't need it and you will run fine with Eclipse alone.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nsigma
« Reply #3 - Posted 2018-08-24 18:16:13 »

But as soon as you must omit the "non-" from any of the words above, a dedicated command-line-executable build system (which is not your IDE) becomes a necessity. In short: You do not want people to install Eclipse just to build your project. I always HATE it when I see GitHub projects checking in their .classpath/.project files with possibly absolute file path references to the Jar files in a C:\Users\SomeUser\Downloads\some.jar file.

Seriously, wtf?!  Shocked So, that's what those bloody files are about.  Never used Eclipse.  In NetBeans, the default build system is Ant.

Just because these things are CLI executable @philfrei doesn't mean you have to use the CLI - all main IDEs have UI support for Ant, Maven, Gradle, etc.

I would recommend using one - make your projects IDE agnostic - you never know when you or someone else will want to build your code in something else.

Maven is useful (and annoying!) for handling download of dependencies for you, amongst other things.

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

JGO Kernel


Medals: 637



« Reply #4 - Posted 2018-08-24 18:19:00 »

Eclipse has its own incremental Java Compiler (ecj). That's why you also do not need a JDK (only a JRE) when building Java applications with Eclipse. The "nice" thing is that ecj and javac behave very differently in a lot of very subtle ways: E.g. how to resolve the receiver class of an inherited static method call. Has caused some trouble in the past for me.
Offline nsigma
« Reply #5 - Posted 2018-08-24 18:21:08 »

Yes, I know it has its own compiler.  Had a few PRs for code that wouldn't compile in the past due to "inconsistencies"!  Cheesy  So I guess I shouldn't be surprised that it has its own bespoke build system - never really thought about it.

Incidentally, ecj isn't the only incremental compilation option.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline FabulousFellini
« Reply #6 - Posted 2018-08-24 18:22:52 »

Thank you for this question @philfrei.  I kept getting a warning with JInput and asked my co-worker who knows what he's talking about, how to fix it.  He said "just use Maven".  I tried and successfully failed, mainly because I had no idea what Maven was or how to use it.

-FabulousFellini
www.fabulousfellini.com
Offline philfrei
« Reply #7 - Posted 2018-08-24 20:09:03 »

Nah, I am assuming @philfrei just clicks on Export > as Runnable Jar (+ extract build path dependencies into JAR), which is fine for all non-collaborative/non-continuous-built/non-continuous-integrated/non-continuous-deployed projects that also no one depends on as a library.

But as soon as you must omit the "non-" from any of the words above, a dedicated command-line-executable build system (which is not your IDE) becomes a necessity. In short: You do not want people to install Eclipse just to build your project. I always HATE it when I see GitHub projects checking in their .classpath/.project files with possibly absolute file path references to the Jar files in a C:\Users\SomeUser\Downloads\some.jar file.

But in short: When you ask why you need Maven and you need people to tell you the advantages, then you don't need it and you will run fine with Eclipse alone.

Thank you for this.

What I do for compiling: Export -> JAR File, and then in the steps that follow, click additional sources (from other projects) for inclusion on an as-needed basis.

Also, the "Configure Build Path" function (via right-clicking on the project) allows one to specify any external jars or libraries or Eclipse projects that are needed for compiling the project.

I do not use Export -> Runnable JAR File. Maybe I should, but when I was first trying to figure out how to compile with Eclipse, I was unable to get that to work. I've put it out of my mind as an option given that the JAR File option works perfectly well.

Well, maybe not so perfectly at the moment. To create a jlink build, I am currently going through the steps I put in my "manual walkthrough" that was just posted a few days ago. I look forward to automating that process (now that I understand it better) with ANT but maybe I should be thinking about doing so with Maven instead? Either system is going to require a learning curve.

@KaiHH, Are you available for some more follow-up questions?

I thought Github was built to be a version control tool, built for collaborative projects. Individuals can each be connected to a collaborative project via a "fork" and develop using Eclipse locally. How does that reconcile with your statement about non-collaborative projects only? I assume I am missing something.

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?

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

music and music apps: http://adonax.com
Offline KaiHH

JGO Kernel


Medals: 637



« Reply #8 - Posted 2018-08-24 20:14:24 »

A lot of these questions will clear up when you read this:
- https://www.baeldung.com/maven
- https://maven.apache.org/guides/getting-started/

Just take an hour or two, read these two and possibly google more for "Maven tutorials" or "Maven howto" or "Maven getting started".
Offline gouessej
« Reply #9 - Posted 2018-08-24 20:28:39 »

I thought Github was built to be a version control tool, built for collaborative projects. Individuals can each be connected to a collaborative project via a "fork" and develop using Eclipse locally. How does that reconcile with your statement about non-collaborative projects only? I assume I am missing something.
I use Maven, Gradle and Ant in Eclipse.

When I use Maven in a project, I can develop in Eclipse, another contributor can develop in Netbeans, another one can develop in a simple text editor and build in command line, another one can use IntelliJ IDEA. Maven is able to generate IDE-specific files if needed, using a "good" build system allows me not to force developers to choose my favourite IDE and it has the numerous advantages KaiHH already mentioned. Each build tool or build system has its pros and its cons, I advise you to learn to use several of them. For example, Ant is very flexible but it forces you to write a lot of code to do everything, Maven is more concise but more strict, Gradle is somewhere between Ant and Maven.

Julien Gouesse | Personal blog | Website | Jogamp
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 637



« Reply #10 - Posted 2018-08-24 20:41:00 »

I thought Github was built to be a version control tool, built for collaborative projects. Individuals can each be connected to a collaborative project via a "fork" and develop using Eclipse locally. How does that reconcile with your statement about non-collaborative projects only? I assume I am missing something.

When you have a collaborative project, you usually want to also have some form of quality gate/control. This at the very least allows you to automatically check whether the project compiles successfully and usually should also include some form of tests (unit test, integration tests, ...), that are being run as part of a build, and for more sophistication also static code analysis tools (SonarQube, CheckStyle, FindBugs, ...) that check certain pre-defined quality metrics of your software.
In order to give quick feedback to contributors about what they are going to check in when they do a Pull Request, you want a continuous build system that performs those checks against the code automatically. One very popular continuous build system used in the open source world is Travis. But Travis is not a person clicking buttons on a graphical user interface in Eclipse. Travis needs to execute command line tools to do the job you want it to do. And one possibility to do all this mentioned above is Maven. Other possibilities, like @gouessej mentioned, is Ant or Gradle; or quite simple even Makefiles or plain shell scripts.
In those situations you simply need a command-line tool which automates most of the dependency-download, build, test, package, deploy (possibly to a public Maven repository so that other projects can use your build artifact immediately) pipeline of your project.
Source control and collaboration platforms like GitHub provide you with great support for all of this. GitHub will even show you whether a Pull Request of someone else passes all those quality gates before you can even merge it.

Eclipse provides you with a lot of the tasks as well:
- Configuring your compiletime and runtime build path (dependencies of your project in the form of Eclipse-only projects in your workspace and jar files)
- Assembling a jar file from your project's compiled class files and resource files
- Running JUnit/TestNG tests
- and there are plugins which provide more functionality (such as deploying a .war file to an application server)

The point is: The functionality an IDE provides you with requires a graphical user interface and requires a user clicking on buttons. This is NOT automation. And you want automation for all of this in a collaborative environment.
I myself consider it a great confidence boost when I see that little "this project builds just fine badge" on a project's readme file, because then I know: This project actually compiles fine and I can be quite confident that when I clone the project and let Maven build it and create an IDE configuration (mentioned by @gouessej ; think Eclipse's .classpath/.project files) that this will work without any problems out of the box and without me having to manually download missing jar files from somewhere and tediously configuring the wrongly configured build path.

I also recommend reading this: https://en.wikipedia.org/wiki/Continuous_integration
Offline Gornova
« Reply #11 - Posted 2018-08-25 07:31:56 »

My 2 cents on the topic:

1) read https://maven.apache.org/guides/getting-started/ really helps
2) selling points:
 - convention over configuration: if you use maven, you agree to use a set of conventions (for example source code in src/main/java) that speed up setup, build, test, etc.. If I want to build your source code for example and get the jar, I have only to run "mvn package" and I have the jar
 - transitive dependency: you declare in your pom.xml (basic maven file) what dependency you need and maven download all required libraries from open, free repositories (see https://mvnrepository.com/ ). Speed up update a library and dependencies, etc..
 - plugins: this is where maven rocks (IMHO). You have a lot of plugins that can be configured to attach to a particular phace (before build, after build, before test, etc.. ) a do a lot of things. Like for example build a site from your repository, run test and save results, run static analysis of your code etc..
 - IDE neutral: does not require anyone to use a particular IDE: Eclipse, Netbeans, shell ? Maven doesn't care
3) about Eclipse. Maven is "Apache Maven is a software project management and comprehension tool" and Eclipse is an "Integrated development environment". Both of them force you to work on a project in a particular way, Maven is more strict on project, file and directories organization, so other people can work on project more easily, applying patterns

Blog | Last game Drone Swarm
Offline ral0r2
« Reply #12 - Posted 2018-08-25 08:40:47 »

Personal biggest advantage Maven provides for me are:

+ all neccessary dependencies are summed up in the pom and are downloaded automatically and if you checkout your project (no need to browse for any .jar files)
+ it supports the build process a lot better than eclipse IDE
+ You have some nice additional plugins provided by maven
+ (not relevant for me right now but working collaborative Gradle or Maven is a must imo)
Offline nsigma
« Reply #13 - Posted 2018-08-25 18:15:10 »

+ (not relevant for me but working collaborative Gradle or Maven is a must imo)

Of those two, Maven every time!  Have a read of http://wiki.apidesign.org/wiki/Gradle (and the linked to https://timboudreau.com/blog/maven/read).  Agree wholeheartedly that a declarative build system, and one in which you (or your IDE) don't have to run the build to figure out what the build does, is massively better than an imperative build system.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline SHC
« Reply #14 - Posted 2018-08-25 19:00:35 »

Gradle wins for me over Maven because I hate XML format. Gradle uses Groovy or Kotlin, so I can use real code to build real code.

Offline nsigma
« Reply #15 - Posted 2018-08-25 21:48:14 »

Gradle wins for me over Maven because I hate XML format. Gradle uses Groovy or Kotlin, so I can use real code to build real code.

Haha. So I guess those blog posts are falling on deaf ears then!  Grin

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

JGO Kernel


Medals: 188



« Reply #16 - Posted 2018-08-26 19:43:47 »

This emphasis on declarative systems imho just makes them inflexible and impractical. In the end you need to do a lot of dirty and ugly tricks to do anything nonstandard or put in a lot of effort to do it cleanly. Therefor I take a proper programming language over a declarative system any day.

Maven is good to define a project and it's dependencies, but it's not a good build tool. I like gradle better.

I also can only partly agree with the argument, that in maven/declarative systems it's easier to determine what a build does without running it. You still need an understanding of the used plugins.

Also reading code and figuring out what it does should not be too hard for a developer. Wading through plugin documentations (if existant) to find out what a configuration does is not always simpler. At least for humans (but the eclipse and idea gradle plugins also work reasonable well)

Mathias - I Know What [you] Did Last Summer!
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2018-08-26 22:29:20 »

Used Ant for 15 years here to do all of Puppygames' stuff.
Ant is quite shit.
Maven looks similarly shit, so I've not bothered with it. Gradle pops up now and again and appears to be like Maven but they've changed the syntax of the shit a bit, but fundamentally, still seems to be a nuclear powered Leatherman to do the job of a knife and fork.

If only someone would make a simple Java API to do buildy things and then we could just use jshell.

Cas Smiley

 

Offline CommanderKeith
« Reply #18 - Posted 2018-08-27 01:30:00 »

Nate's SCAR library does just that- a java API to build Java projects.
https://github.com/EsotericSoftware/scar
But since it's not a standard, very few people are familiar with it so I suppose it doesn't help reduce the fixed cost of learning a new tool in addition to Ant, Maven or Gradle.
Since libgdx uses Gradle, that's probably the best thing to recommend to java game devs

Offline nsigma
« Reply #19 - Posted 2018-08-27 08:10:58 »

This emphasis on declarative systems imho just makes them inflexible and impractical.

Gradle is meant to be a declarative build system though! It's just that if you let people write "real code" ... Maybe most people are more disciplined and follow Gradle's guidelines more carefully, but the few times I've had to work with projects using it I've found it a bit messy.

Now, like @princec most of what I'm working on still uses Ant. Writing imperative code in a language meant for declarative use. Now that really is a warped idea!  Cheesy


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

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2018-08-27 16:03:58 »

In XML too, the syntax of the devil himself.

Cas Smiley

Offline Riven
Administrator

« JGO Overlord »


Medals: 1356
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #21 - Posted 2018-08-27 16:09:00 »

You simply have to consider how miserable development has gotten, when Maven and Gradle become the appropriate tools.

On the other hand... any successful programming language's ecosystem will become bloated to the point where things fall apart, and you need a full fledged toolchain to produce hello-world like applications. Take JavaScript for example, in the last decade it kinda escalated a teeny bit, to where the toolchains rival Java's.

When you program for big business, you'll find that you'll hardly ever write business logic anymore, it's all tying this framework to that, transforming an object to a slightly different object, and flinging it across the network in some shape or form, all abstracted behind 5-ish layers of abstraction, which you have to drill through ocassionally.

You know you've had an invigorating day at work, when you wrote a for-loop.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2018-08-27 18:49:46 »

Ok, so... Scar is great, and everyone needs to know about it.

Cas Smiley

Online h.pernpeintner

JGO Ninja


Medals: 106



« Reply #23 - Posted 2018-08-28 11:14:55 »

I'm really a bit confused of what kind of statements I have to read here from experienced people  Huh

First of all, there's a huge difference between your own private projects and professional software development.

In professional projects you need always ask the question if a decision makes sense from your company's point of view. There are also some foundations that one has to accept, no way around it (exceptions included, as always). For example there is the need to have a ci pipeline and a release automation. As well as a platform independent, reliable, build. Using eclipse -> export as jar depends on eclipse, which means most likely your ci can't build the project, means that your colleague with Netbeans can't build the project, means most likely that you have no platform independent build. Someone who does such a decision has (most likely) no place in a company and I hope I don't have to explain that.

In professional projects, one also has to take care of standards - if a tool that gets a job somehow acceptable done, and is an established standard, then it's okay to use it and benefit from a large job market, well known and established knowledge etc. Just like Java still exists Tongue

You simply have to consider how miserable development has gotten, when Maven and Gradle become the appropriate tools.

Ehm....okay. What's so worse about them? No seriously, don't start what those tools may not do completely right, I have 7 years experience with them. The thing is - there is always the need for a build tool (if you're not using scripts only), one way or the other. History told us, that we must not cripple what can be done in a build. Not every project is simple. Not every project has to be simple.
What a build tool has to do is, it has to expose those functionalities in a sensible manner. For example if you have a non-trivial build, maven's declarative approach fails miserably... when people want to execute their logic, they'll go and put it in a plugin - looks declarative, but ...yeah. When they want to fiddle their logic somewhere between two things, they start to shift maven phases. For those cases, gradle's approach is better: You can declaratively define your build graph with tasks. Once learned, everybody can understand that. You can write your build as code - script files in groovy or kotlin, logic in whatever JVM language you want to have (for example the same as your project's main language!). What could be negative about this approach, honestly? Of course, there are some things you have do read, because - surprise - if you want to solve a complex problem, the solution is most times not easy. For simple, small builds, gradle or maven files are very small and are very easy understandable...

Most complains I hear about gradle is from people not able to read even the simplest Groovy code, because...surprise, they are most often Java developers, claiming that they don't have to learn anything else.
Offline nsigma
« Reply #24 - Posted 2018-08-28 12:27:56 »

Not every project is simple. Not every project has to be simple.
What a build tool has to do is, it has to expose those functionalities in a sensible manner. For example if you have a non-trivial build, maven's declarative approach fails miserably... when people want to execute their logic, they'll go and put it in a plugin -

Which is no different to the recommended approach for using Gradle.

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

JGO Ninja


Medals: 106



« Reply #25 - Posted 2018-08-28 13:05:27 »

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 (as you would with code in your project too), and which allows you to write a medium sized piece of logic as a task or plugin directly in your project  (buildSrc) without the need to publish and maintain a seperate artifact, and mavens "you have to make a seperate plugin project for everything". In gradle, you can chose the appropriate way how to organize your build, just like your code.


One of my favorite examples is having a service you need for your tests running on a random port. It's a simple requirement that many projects have - In maven, the official way is to use the build-helper-maven-plugin, which requires you to write at least 22 lines xml for the plugin usage. Afterwards, you have to check the documentation in order to find out how to use the generated port(s) as a property (because it is not obvious and there is no standard for this). From my knowledge, it doesn't work with autocompletion in the IDE, despite this could be an XML based build's biggest advantage here.
In gradle, its really the most simple thing: a property. ext.myPort = new ServerSocket(0).getLocalPort(). Every Java/Groovy/JVM-developers knows this function, a property/variable is the standard way to do this in any programming language and it wins over XML with 1:22 lines. It is okayish supported by IDEs.

This is just one example of something that is daily business in builds. I'm not going to start how much simpler a single simple if-statement is compared to maven's complex profile logic (that really no one understands besides the maven users who got used to this pain). The foundations of maven prevent it from being an adequate solution for more complex builds.

And I really don't want to doom maven in any way, I maxed maven by myself: It's way better than nothing/eclipse/ant stuff, it is an established tool and it can handle medium sized/complex projects okayish. I would most times be totally happy to use it in production and in my spare time projects (which I still do sometimes). It's just that we have to be honest about "right tools for the right job" - and Maven is quite limited here.
Offline Riven
Administrator

« JGO Overlord »


Medals: 1356
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #26 - Posted 2018-08-28 14:02:44 »

Not sure why you're confused about the statements of experienced people here Smiley

First you say that these tools fit their purpose, then you list quite a few dreadful issues with these tools (which i could copy and paste from your informative posts).

Either way, it's certainly true that we couldn't work without these tools, but enough people in a typical dev-team turn your pom-file in this (excuse my french) clusterf**k, and maven is partially to blame here - the way they designed it, is not intuitive - newbies craft pom's with copy/paste and checking whether it works, senior developers... do the same... very few people in a team (if any) can actually design/maintain a proper hierarchy of pom-files. The design of the tool, and the terminology used is... not ideal. Surely you can agree on that. Smiley

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2018-08-28 14:17:15 »

As usual the problem is "let's design another DSL!" and that's where gradle and Maven and Ant are all exasperating. The dependence on external sites for builds is also massively vexing and calls into question the professional credentials of anyone using them ("sorry, can't do the build today, looks like crappylibrary.org is down again") but that's an orthogonal rant for another day.

I am considering forking Scar to add THJSON configuration support... hey ho.

Cas Smiley

Online h.pernpeintner

JGO Ninja


Medals: 106



« Reply #28 - Posted 2018-08-28 15:10:34 »

Quote from: Riven
First you say that these tools fit their purpose, then you list quite a few dreadful issues with these tools
Of course, I agree with everything you said Riven Smiley

I just tried to say that no tool is perfect in every regard - maven for example is not suited for complex projects. But it's an established standard, so foreign people will probably be able to handle your project very fast. And it is suited for use with ci pipelines, there are many many plugins that you don't have to implement by yourself. So it may be a proper choice for small enterprise projects. Of course there is some investment when one wants to use tools like gradle properly.
Saying that either Maven or gradle is devil's work and nobody needs build tools or that build shouldn't be that complex that you need gradle...those are statements I can't understand.

As usual the problem is "let's design another DSL!" and that's where gradle and Maven and Ant are all exasperating.
Na, I have to second that. The way Ant and Maven define a DSL is via XML schemas. Groovy itself as a language is sufficient for build scripts (or Kotlin, yay!), no need for extra constructs - what adds "DSL" for gradle is just how you use interfaces provided by gradle, like project, tasks, configurations etc. It's really more like using a framework than it's a DSL, because with gradle there is no DSL, it's just groovy with the gradle framework. It's just simpler to say "it's a DSL", because it writes like a DSL. The same for Scala and sbt (i think). So here's only a framework invented that for example can be used fantastically with Kotlin, or Java in a Java based plugin as well.

The dependence on external sites for builds is also massively vexing and calls into question the professional credentials of anyone using them ("sorry, can't do the build today, looks like crappylibrary.org is down again") but that's an orthogonal rant for another day.
I think you got it wrong - repository doesn't mean "external site". It means you can have different kinds of repositories...flat folder repositories, network shares, local artifactory instances caching the outside world. If you have problems with your build because external services aren't available, you're doing it wrong.

I am considering forking Scar to add THJSON configuration support... hey ho.
Have to admit that I don't know this tool, so feel free to show it to us in its own thread Smiley
Offline cylab

JGO Kernel


Medals: 188



« Reply #29 - Posted 2018-08-28 17:28:23 »

As usual the problem is "let's design another DSL!"

I am considering forking Scar to add THJSON configuration support... hey ho.

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

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

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

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

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

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

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

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

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

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

nelsongames (1412 views)
2018-04-24 18:15:36

nelsongames (2043 views)
2018-04-24 18:14:32
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

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
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!