Jme-alloc project

I restructured the project to include an android example application that implements the output jar jme3-alloc-examples and runs the StressLauncher example (tests all the memory capabilities), here are some logs:

I/TestNativeBufferUtils: **************** com.jme3.alloc.examples.TestNativeBufferUtils****************
I/System.out: java.nio.DirectByteBuffer[pos=4 lim=1000 cap=1000]
I/System.out: Buffer Data: 200
I/System.out: java.nio.DirectByteBuffer[pos=4 lim=1000 cap=1000]
I/System.out: Buffer Data: 200
I/TestNativeBufferUtils: **************** com.jme3.alloc.examples.TestNativeBufferUtils****************
I/TestDirtyMultithreading: **************** com.jme3.alloc.examples.TestDirtyMultithreading****************
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000 cap=2000000]
I/System.out: Buffer Data: 3000
I/TestDirtyMultithreading: **************** com.jme3.alloc.examples.TestDirtyMultithreading****************
I/android.exampl: ProcessProfilingInfo new_methods=0 is saved saved_to_disk=0 resolve_classes_delay=8000
I/TestMemoryCopy: **************** com.jme3.alloc.examples.TestMemoryCopy****************
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000000 cap=2000000000]
I/System.out: Buffer Data: 200000
I/System.out: java.nio.DirectByteBuffer[pos=0 lim=2000000000 cap=2000000000]
I/System.out: Buffer Data: 0
I/System.out: java.nio.DirectByteBuffer[pos=0 lim=2000000000 cap=2000000000]
I/System.out: Buffer Data: 200000
I/System.out: java.nio.DirectByteBuffer[pos=0 lim=2000000000 cap=2000000000]
I/System.out: Buffer Data: 200000
I/TestMemoryCopy: **************** com.jme3.alloc.examples.TestMemoryCopy****************
I/TestMemorySet: **************** com.jme3.alloc.examples.TestMemorySet****************
I/System.out: java.nio.DirectByteBuffer[pos=0 lim=2000000000 cap=2000000000]
I/System.out: Buffer Data: 0
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000000 cap=2000000000]
I/System.out: Buffer Data: 2500
I/System.out: java.nio.DirectByteBuffer[pos=8 lim=2000000000 cap=2000000000]
I/System.out: Buffer Data: 0
I/TestMemorySet: **************** com.jme3.alloc.examples.TestMemorySet****************
W/System.err: Stopped

And the application profiler shows a good performance…
The last W/System.err: Stopped is triggered from a Button to stop the thread running the examples (because backend memory allocations shouldn’t run on Ui thread).

2 Likes

I did a basic javadoc and nativedoc generators based on the javadoc.jmonkeyengine.org, but the generation is all dynamic through GitHub actions and will be based on the version of the release tag.

The current website is a prototype test for the core Gradle tasks, the Gradle tasks accept the output javadoc version to be deployed:

2 Likes

I plan to extend the use of this API to more advanced concepts in the future, for example, editing the already created buffers by partitioning them and reusing some parts or mixing buffers, this could be used to edit a soundtrack or an image for example, What else?

This issue will be a future milestone for this extension:

Hi @Pavl_G

Nice job!

When are you considering to release it on maven central?

2 Likes

I am currently working on the maven-publish Gradle plugin, I already provided some of the requirements, such as the javadoc and source jars.

Do you plan to fix the issue related to this and integrate into the new engine release ?

2 Likes

Sure for 3.7, but might be worth considering this for 3.6.1 too (I will do the 3.6.1 release when LWJGL 3.3.2 is out that should fix 1778) but I must consult this with other team members first.

2 Likes

Brilliant, I will try to produce a release during days from now, but idk how much time it will take, I want to get the automation right, this is the most hardest part.

2 Likes

I’ve done some release automation. Perhaps I can help?

1 Like

Thank you, I am not familiar with the maven-publish Gradle plugin, I am studying the plugin parts to consider what to do next, but I am currently more deviated toward using Bash scripts and linking them to the UnixScriptRunner task, it’s already a part of the project buildSrc, however, If you have a better suggestion, let me know, I haven’t decided yet on a specific design for the publishing code.

1 Like

SiO2 (and several of my other projects) use gradle to publish to maven central. The build is really straight-forward:

…using the buildSrc stuff. Properly setup, it’s a one-shot command to build and upload everything. Then I just need to go walk it through approval on the sonatype site.

2 Likes

Thanks @pspeed, I am willing to link the publishing to GitHub-Actions on-release event, I will take a look into your SiO2 building scripts for the maven-publish plugin utilization.

The documentation says I should log into nexus-manager, but it doesn’t accept my Jira credentials " Login Error Incorrect username, password or no permission to use the Nexus User Interface. Try again. Forbidden".

I saw some similar issues on the Jira platform, there were issues with the password, so I changed the password, but it didn’t work, Has anyone faced this issue before?

I tend to agree with @pspeed: use Gradle’s ‘maven-publish’ and ‘signing’ plugins.

1 Like

Has anyone faced this issue before?

Occasionaly it shows me as logged in but won’t accept my commands. Then I have to log out and log back in. I think this is a recent issue.

1 Like

Great, I will go with the maven-publish plugin, it looks straightforward, but one thing I am curious about, is where does it look for the actual artifacts to release on maven-central? Does it use the current latest GitHub release?

1 Like

image

Hmm, seems it only publishes the primary jar, but only one jar? That might need some custom build.

Jme-alloc has 2 artifacts, an android jar, and a desktop jar.

1 Like

where does it look for the actual artifacts to release on maven-central?

When you run the “publishMavenPublicationToOSSRHRepository” task, Gradle uploads the artifacts you specify, typically from your build directory, to a SonaType server.

When you click on the “Close” button in the Sonatype web interface, the server copies the uploaded files to a “staging” repository.

When you click on the “Release” button in the Sonatype web interface, the server promotes artifacts from the staging repository to Maven Central. The process usually takes about half an hour. I don’t know any way to automate that part of the process or speed it up.

The JME Wiki includes a detailed description of these steps:

it only publishes the primary jar, but only one jar?

I suggest creating a Gradle sub-project for each artifact you plan to publish. For instance, the j-ogg-all project publishes 2 library artifacts, each of which has its own sub-project:

  • a “library” sub-project for artifacts with the “j-ogg-all” ID
  • a “vorbis” sub-project for artifacts with the “j-ogg-vorbis” ID

The “jmonkeyengine” repo is also structured this way.

An alternative is to pass a parameter to Gradle (using a “-P” command-line argument) to specify which build you want. That’s how the Minie project publishes different build flavors (“-droid”, “-debug”, and so on) without a bunch of subprojects. It proved a bit cumbersome, so I’ve gone and wrapped a shell script around it:

1 Like

Thank you, I am already structuring the project into sub-projects “jme3-alloc” and “jme3-alloc-native” as main modules, but the build that is java compatible (jars) is produced at the “jme3-alloc”, so if it will end up writing a lot of publishing code that might not work at the end of the day, it will be better to use the maven sign-deploy-file command-line plugin, I wrote a code similar to it before on Serial4j-maven-publish for GitHub packages.

I am satisfied with the manual Bash script, it seems easier to write and integrate with GitHub actions, thanks for the help, I studied the documentation and Paul’s script, but I found it hard to integrate the Gradle maven-publish plugin with GitHub actions…

Here is the PR:

As for my credentials error on the nexus-manager, I filed an issue, one maintainer replied that the problem may arise from using special characters within usernames and so I am now waiting for them to change my username to remove the special characters and grant the permissions of the current account to it.

2 Likes

I currently have an incompatibility error on the github-ubuntu-latest runner image:

It was happening also on my local Linux machine and I noticed something about this error in the release notes for maven-3.9.1:

Maven 2.x was auto-injecting an ancient version of plexus-utils dependency into the plugin classpath, and Maven 3.x continued doing this to preserve backward compatibility. Starting with Maven 3.9, it does not happen anymore. This change may lead to plugin breakage. The fix for affected plugin maintainers is to explicitly declare a dependency on plexus-utils. The workaround for affected plugin users is to add this dependency to plugin dependencies until issue is fixed by the affected plugin maintainer. See MNG-6965.

They say that this doesn’t happen with Maven 3.9! And the original maven shipped with ubuntu git image is Maven 3.8 which presumably affected!

I did a simple workaround by installing Maven-3.9 and using it directly, it works on my local machine and I can see the released packages on the Staging Repositories, but it didn’t for GitHub runner…

Totally unexpected!

I recommend you to switch to maven wrapper: Apache Maven Wrapper – Maven Wrapper
So you the build doesn’t depend on the environment (as much).

1 Like