Lwjgl3: LWJGL's download options

[dustContributor]

Hi! This is a tiny suggestion, I think it'd be nice if the downloader did two things:

Instead of naming the file "lwjgl.zip", it could name it with the version/build, like:

lwjgl-3.0.1-b04.zip

ie, LWJGL 3.0.1 build 4. Much like how OpenJDK names their builds.

Inside that zip, it'd be nice to have a root folder first that had this same naming, so the directory tree after extracting the tree would look like:

lwjgl-3.0.1-b04/lwjgl
lwjgl-3.0.1-b04/lwjgl-opengl
lwjgl-3.0.1-b04/lwjgl-jemalloc

And so on.

What do you think?

[apostolos]

We already append build type and build version for custom builds. The build number part is not easy to do because we have to get this information from another server. I'll look into into it.

Unfortunately, for the full pre-built bundles we hit a browser security feature. We cannot programmatically change the download's filename because we initialize the download from a different origin (hostname). Browsers ignore the filename we want to use and just use the original file's name.

[SilverTiger]

Another suggestion:
It would be nice if you could add a mode for Ant Ivy for generating an ivy.xml for the users who are using Ant for building instead of Gradle and Maven.

[Spasi]

It would be nice if you could add a mode for Ant Ivy for generating an ivy.xml for the users who are using Ant for building instead of Gradle and Maven.

Will do.

[dustContributor]

We cannot programmatically change the download's filename because we initialize the download from a different origin

Ahh I understand. What about the root folder inside the zip then?

[Spasi]

@SilverTiger: Support for Ivy has been added with https://github.com/LWJGL/lwjgl3-www/commit/27bacff7c23bb4892dc348196c67be089d647084.

I'm not at all sure whether it's useful in practice though. If you or anyone else has any comments or suggestions on how to improve the current implementation, please let me know. It seems to be working in my local tests, but here's a list of things I find troubling:

• It requires editing 3 separate files (ivy.xml, ivysettings.xml and build.xml).
• I have no idea what is the best way to add the sonatype snapshots repository for the nightly build. What I have now works (although slow for some reason...), but I don't know if changing the defaultResolver is practical in a real project.
• Is there a better way to set lwjgl.natives other than using Ant for it?
• Is there a better way to define custom artifacts for a dependency? Specifically, it seems that by default Ivy downloads the classes jar as well as the sources and javadoc. If custom artifacts are defined, it stops downloading sources/javadoc.
• Is there a better way to define the natives artifacts other than using m:classifier?

[SilverTiger]

Just tried the ivy.xml Generation. Seems good so far. Here are some notes:

• That's no problem in my opinion. The version properties can also be placed inside the ant.xml. And if you aren't using a snapshot build, one has to import the default ivysettings.xml or else it won't find the default resolver if a local ivysettings.xml is present.
• I think you have to change the defaultResolver. But you run into problems if you are using a snaphot build and a release build (for example LWJGL 3.1.1-SNAPSHOT and JOML 1.9.0). In that case it may be advisable to use a chain resolver, like described here in combination with the default resolver from the default ivysettings.xml.
• I'm fine with getting the natives with Ant, as you have to use both, Ant and Ivy. Just out of curiosity: For Windows you are using os family="windows, but for Linux and Mac it generates os name="Linux" and os name="Mac OS X". In that case you could also use os family="unix" and os family="mac", or is there a specific reason?
• I'm not sure about that, but the solution for this could be custom configurations.
• This may also get solved with custom configurations.

[Spasi]

I think you have to change the defaultResolver. But you run into problems if you are using a snaphot build and a release build (for example LWJGL 3.1.1-SNAPSHOT and JOML 1.9.0). In that case it may be advisable to use a chain resolver, like described here in combination with the default resolver from the default ivysettings.xml.

Thanks! Fixed with https://github.com/LWJGL/lwjgl3-www/commit/f802e4d29b470a3cf9b52699a19290a4b5ac6893.

I'm fine with getting the natives with Ant, as you have to use both, Ant and Ivy. Just out of curiosity: For Windows you are using os family="windows, but for Linux and Mac it generates os name="Linux" and os name="Mac OS X". In that case you could also use os family="unix" and os family="mac", or is there a specific reason?

It's the same conditions used in the LWJGL Ant build. Note that family="unix" cannot be used, there are multiple Unix-based operating systems (that LWJGL does not support) and Linux is just one of them. family="unix" also matches on macOS. The conditions will probably change as we add support for more platforms, but I'll make sure any changes are synced to the dependency scripts.

[SilverTiger]

Although this issue is closed, this may be interesting for adding to the download page. I tested a bit with Ivy configurations and now I have a solution for downloading javadoc and sources independently.

First you have to add this to ivy.xml:

<configurations defaultconfmapping="default">
    <conf name="default"/>
    <conf name="javadoc"/>
    <conf name="sources"/>
</configurations>

The default mapping will download the jar and the native files. The configurations for javadoc and sources have to be added for each dependency as a new dependency. For example the core dependency will be like this:

<dependency org="org.lwjgl" name="lwjgl" rev="${lwjgl.version}">
    <artifact name="lwjgl" type="jar"/>
    <artifact name="lwjgl" type="jar" m:classifier="${lwjgl.natives}"/>
</dependency>
<dependency org="org.lwjgl" name="lwjgl" rev="${lwjgl.version}" conf="javadoc;sources"/>

The first dependency doesn't need to set a conf because it will get the defaultconfmapping automatically. After that you need to download the dependencies in build.xml via:

<ivy:retrieve conf="default"/>

And if you also want to get the javadoc and/or sources you can change that line to (alternatively if you won't specify a conf everything will get downloaded):

<ivy:retrieve conf="default,javadoc,sources"/>