Command Line Interface (cli) starter app

[httpdigest]

The efforts being put into issue #100 to separate modules and provide repository services for them makes it also attractive to provide a simple cli application to scaffold LWJGL 3 applications.

This could be a simple standalone jar file (with corresponding batch/shell scripts to start). It would also provide the basis for the starter/initializr web application advertized in #100.
Commands could be issued on the command line to discover LWJGL 3 builds/modules and to resolve/download and scaffold a simple Eclipse, IntelliJ, NetBeans, Maven or Gradle project.

Example invocations:

lwjgl-cli --version=3.0.2 --profile=full --project=eclipse create myapp
This command could create a new folder "myapp", download all LWJGL3 modules in version 3.0.2 constituting the "full" application profile (i.e. all modules) and setup an Eclipse project with corresponding .classpath and .project files.

lwjgl-cli --version=latest --profile=full list-modules
This command could list all modules of the "latest" version of LWJGL 3 in the "full" profile.

lwjgl-cli --version=latest list-profiles
This command could list all profiles (curated bundles of modules) of the "latest" version of LWJGL 3.

[httpdigest]

As a first quick proof of concept: https://github.com/httpdigest/lwjgl3-cli

This currently only supports up to version 3.0.1-SNAPSHOT. Support for the new module system in #100 will be added once that is done.

[sriharshachilakapati]

What about creating maven of gradle scripts instead so to allow importing
into any supported IDEs?

On Sat, 18 Jun 2016 6:23 pm Kai Burjack, [email protected] wrote:

As a first proof of concept: https://github.com/httpdigest/lwjgl3-cli

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#200 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AEYWNCc_FrDq4kUhaXm3VEmInQHMKB4qks5qM-o7gaJpZM4I46YT
.

[httpdigest]

Creating Maven projects is already supported. Next step is native IntelliJ projects Gradle support.

[httpdigest]

Generating proper Maven, Gradle and Eclipse build files is in now. Currently, the set of needed artifact ids ("lwjgl" and "lwjgl-platform") are fixed, because there are currently no dependency management information in the deployed Maven pom.xml files. That is also the goal of #100 to provide these.
The Maven, Gradle and Eclipse build/project files have the needed jar and natives for the platform which the cli tool is invoked on.
In the future when #100 is properly implemented, the user will also have the ability to select all platforms to generate a project for.

[TheOnlySilverClaw]

Sorry, but I guess I fail to understand at what point your CLI would make things much easier. I can already just create a build.gradle, put those few lines of dependences in, run "gradle eclipse" and it works fine. I'll just go through the features in the readme:

• list all available versions of LWJGL 3

Okay, that's nice, but I do not really have a problem with checking the latest version manually every few weeks/months.

• create a Maven project from the latest or a given LWJGL 3 version with a working example file

Would "working example file" be what I suggested in #199 ? If yes, great, but that would be a typical job for a build tool.

• create a Gradle project with proper build.gradle file

That would be cool, but why no just stay in Gradle for that?

• create an Eclipse project with proper .classpath and .project files

Doesn't this already work?

To sum it up, I would not see the benefit of using an extra command line tool.
You already have this Download Page, put a proper, automatically updated, version history there. Then, a nice-to-have would be something that builds a build.gradle file from a set of checkboxes/dropdown lists, like "Version", "IDE", "Natives", "Modules", etc. Gradle's Maven Plugin could take care of creating Maven poms and stuff for those who want to use Maven instead.

[httpdigest]

Thanks for giving feedback!

I agree with you that there are ways to accomplish everything using existing tools, or requiring the user to look up a documentation. This is the case with every CLI tool for any framework I know of.
While your argumentation revolves mostly around using Gradle, I thought of users who don't like to do this. People who want to get going with LWJGL3 in the quickest way possible and basically only know about Eclipse or their IDE of choice.
To get those people going it likely means scaffolding an IDE project right away. No Gradle or Maven installation. The CLI tool targets this audience.

I do agree that using Maven and Gradle in the long run would be benefitial for everyone in any project. That's why the CLI tool also generates Maven and Gradle build scripts.

Indeed, the goal is to use the experience earned in developing that CLI tool for building the web application. And there on the backend, using the services Gradle provides is sure the better way, I agree.

I could also think about the CLI tool being a simple HTTP client for the web application in the future, only requesting the web application to generate a distribution and downloading that. Thus making it a true command line "interface", in the truest sense of the word, by interfacing the backend services, and not providing any services itself.

[TheOnlySilverClaw]

Okay, I see your point. I was one of those people who did not want to use a build tool for quite a long time and I haven't dug that deep into Gradle, yet. But even if the goal is to get those people running, wouldn't it be just as easy to pre-build a bunch of zip files until the real Initializr works?

I could also think about the CLI tool being a simple HTTP client for the web application in the future, only requesting the web application to generate a distribution and downloading that. Thus making it a true command line "interface", in the truest sense of the word, by interfacing the backend services, and not providing any services itself.

That would have been my next suggestion. But would it be feasible to use Gradle for that job, since it's basically Groovy and can be run as a script, anyway? I actually have no idea, but maybe it would be possible to cut out the intermediate layer?

[Spasi]

But would it be feasible to use Gradle for that job, since it's basically Groovy and can be run as a script, anyway? I actually have no idea, but maybe it would be possible to cut out the intermediate layer?

That would require Gradle to be available on the user's machine. The idea here is to not make any assumptions and to be flexible without any dependencies. A web app or a CLI tool that only requires Java to run, satisfy that goal.

[TheOnlySilverClaw]

Not on the end user's machine, but behind your initializer. The end user would just get a zip or something.

[httpdigest]

Stopped development of the cli, because LWJGL now has a nice download site.