Maven central repository

[siegebell]

Your main page says that moving to the central repository is a "work in progress", but the request has been accepted for a while now (almost 4 years) and is waiting for you (jzy3d) to make a release. In my situation, it is much easier to access the central repository than jzy3d's self-hosted repo (see #12).

[jzy3d]

Sorry about that, it was easier for me to publish on jzy3d's ftp, but I understand central repos are better :)

Would you have little time to try it on your side? You can retrieve 1.0 branch, edit it to publish to sonatype, and push back the configuration?

[chhh]

@jzy3d I can do it. In fact, the major headache is not the "configuration" of which there is not much needed, but rather the process of registering with Sonatype, confirming that you're the owner of the library, setting up encryption keys etc. From there it's mostly maven deploy -Prelease. Is this issue still relevant?

[swatalla]

I would be ecstatic if this found its way onto a central repo. I am not sure what's going on but the .jars are refusing to fetch through maven; the same "file could not be resolved" problem every time. I am a researcher with a little programming knowledge, so troubleshooting this is way out of my league... But this is such an amazing package for the type of visualization I do that I would hate to have to move away from it because of a repo issue.

[freddy33]

I'll love to help with this. @chhh Any progress on your side?

[chhh]

well, someone from jzy3d needs to register at sonatype, and prove they own this repo/website. I did take the time to write a complete guide: https://dmtavt.com/post/2017-01-25-publishing-to-maven-central/

[jzy3d]

Thanks for the tutorial @chhh. Just started to apply and simply wonder if it is possible to upload snapshot versions? Will I be able to simply invoke mvn deploy without passing through mvn release:*? Your tutorial let me think I will have to release a version as soon as I want to deploy.

[chhh]

@jzy3d It's been a while since I did it, but they 100% have snapshot repos. Just for development you won't need to change anything, it will get installed or deployed as normal, all the config configuration for pushing jars to Maven Central is kept in the "release" maven profile (or call it whatever). So "mvn deploy" should still do what it currently does for you, unless you add "-Prelease"

Also, releasing to Central is pretty quick, they will first put it to staging area, run the tests, then put it online. "search.maven.org" will only pick it up in a few hours though.

[freddy33]

You can also use this: https://jfrog.com/artifactory/saas-gcp/

[jzy3d]

Work in progress : snapshot version of 1.0.3 is here https://oss.sonatype.org/content/groups/public/org/jzy3d/

[chhh]

I also highly recommend you to add another readme file with a reminder for yourself how to release

[jzy3d]

Work in progress : staging version of 1.0.2 release is here https://oss.sonatype.org/service/local/staging/deploy/maven2/

[hageldave]

does this mean the artifact(s) are staged but not released? https://help.sonatype.com/repomanager2/staging-releases/managing-staging-repositories#ManagingStagingRepositories-ReleasingaStagingRepository

[calvertdw]

Any update on this?

[HannesWell]

For another project I set up GH workflows to continuously deploy snapshots to OSSRH on each change on the master branch and to provide a one-click releases process that creates the usual two release-cycle commits of the maven-release-plugin, updates the release-notes (which can be crafted manually during the development process) and creates a GH release entry.

You can find them here: https://github.com/axkr/symja_android_library/tree/master/.github/workflows Since you already have a Sonatype account and claimed your groupId the only missing prerequist is propably the creation and publication of GPG/PGP (Public)Keys as described here: https://central.sonatype.org/publish/requirements/gpg/#distributing-your-public-key

You could then basically copy the workflows listed above.

[jzy3d]

Thanks! The problem on this now becomes that JOGL 2.4-rc4 should be deployed first. This release is something I did by myself, and the previous 2.4-rc wasn't publish on maven as well. I will think about it.

[HannesWell]

Thanks! The problem on this now becomes that JOGL 2.4-rc4 should be deployed first. This release is something I did by myself, and the previous 2.4-rc wasn't publish on maven as well. I will think about it.

That is indeed a blocker for publishing on Maven-Central. All dependencies should be available on Maven-Central as well for good reasons. I also noticed sadly the declining activity in the JogAMP/JOGL project. Have you ever considered respectively would it be possible (without great effort) to change to LWJGL instead? I don't know very much about the difference (and OpenGL in general) but I found it in a short search for alternatives, but didn't had the time yet to have a deeper look at it. Maybe you can give some advice about the differences.

At least LWJGL seems to be quite active, is available from Maven-Central and even offers a very handy Maven-dependency configurator: https://www.lwjgl.org/customize

[jzy3d]

Yes, I have been thinking about using LWJGL instead and there is even a room for it since the IPainter interface in Jzy3D allows using different libraries implementing the OpenGL API. However when trying LWJGL, I found that the community is similar to JOGL (a single commiter doing almost everything, few satellite commiters involved for a few month but not on the long term). I was also a bit disappointed by lot of crashing demos on my macOS... but this does not mean they're still instable. It would be worth adding LWJGL as an alternative rendering backend to Jzy3D.

Other alternatives to JOGL and LWJGL are

• EmulGL, already integrated in Jzy3D since 2.0. Not using native OpenGL is great for compatibility.
• PanamaGL, mainly a POC up to now. The idea is to use JExtract as of JDK17 to access native OpenGL. The prototype is promising, but there is still a bit of work to do.

[HannesWell]

Thanks for your assessment. Having only one main maintainer is indeed not ideal, but at least there is one that seems to be active. For JOGL I did not have that impression in the past, but I only have a look at it occasionally so I cannot really tell. Maybe it is just because JOGL's project infrastructure is a bit hidden and not on Github. But I noticed you also participate in JOGL and try to keep it running. :)

* [PanamaGL](https://github.com/jzy3d/panama-gl), mainly a POC up to now. The idea is to use JExtract as of JDK17 to access native OpenGL. The prototype is promising, but there is still [a bit of work to do](https://github.com/jzy3d/panama-gl/issues/6).

I already found that repo of ours a while ago when it was mentioned on the Panama mailing list and starred it right away. I'm glad it is promising. In general I'm very interested in Project-Panama as a technology because we have multiple native library (OpenGL, VTK, OpenCascade, ...) for which we need java-wrappers/bindings and at the moment it is a quite time-consuming/expensive process to update them and also does not work reliably in all situations (e.g. Exceptions in C++ code can crash the VM if not handled manually in the wrappers). Therefore I have high hopes that Panama makes this easier, although C++ is not yet supported, but hopefully will be in the future. Unfortunately I did not yet have the time to look into the details and to tried it out, but I plan to have a more detailed look into your repo to learn it better. I think it is best to have a real-world show-case were one is at least a bit familiar with.

[hageldave]

For LWJGL there is also a project for integrating it into the AWT environment. https://github.com/LWJGLX/lwjgl3-awt

I'm using this as part of my plotting lib and have contributed to it. This project is also mainly maintained by 1 or 2 persons and progresses slowly. Tbh, I think these projects need participation in case you want something implemented or fixed. Especially MacOS support.

[HannesWell]

Thanks for the link.

Tbh, I think these projects need participation in case you want something implemented or fixed. Especially MacOS support.

Yes of course I cannot expect that in an open-source projects somebody else fixes my issues or implements the feature I need for free and quickly. It sometimes happens if it is a general issue or a feature beneficial for the project in general, which is very nice then but I cannot and do not expect that.

But it is simpler to contribute to a project if it is easily accessible, which is definitely the case if it is hosted on a highly frequented platform like github. This is IMHO a plus for LWJGL. I intended once to ask a question in the JOGAmp forum but failed because it seemed relatively complicated to even created an account to ask a question. I have to admit I did not tried really hard, but it was complicated enough to turn me away. The simplicity for contributions was for example one reason why the entire Eclipse Platform was migrated to github recently (from Bugzilla+self-hosted-git+Gerrit).

But I assume (or better hope) that in general the need for binding providing projects like lwjgl/jogl will decrease in the future with the means provided by Project Panama (foreign function/memory access API and jextract), at least for those that are interested only in the 'bare metal' OpenGL and don't need higher-level wrappers or don't want to create those bindings by themself.

[jzy3d]

Thank you @hageldave, I will evaluate LWJGL for AWT here if you are interested.

I agree with @HannesWell that using Github is handy. That's why I made my work on JOGL on a Github mirror. The status of the latest version I have worked on is best described by this ticket. The hard point with JOGL is mainly building it. Github Actions is great for running tests (I can run Jzy3D tests on my Windows/Linux/MacOS hardwares - very handy!), but dealing with multi-repo project is not easy (at least for me). JOGL needs a fresh build of GLUEGEN to build, so it would probably require to merge them in the same mono-repo to make things easier. There is then a bit of work to publish / deploy the jars somewhere but this doable with Github Actions. I don't know how hard it is to trigger new builds in LWJGL, but the pain to build JOGL (mainly due to its native & multi-os part) makes Panama/JExtract very appealing. I think changing 1 line in JOGL requires 1-2 weeks to create a new release!

@HannesWell since you mention VTK, you will probably be interested by https://github.com/jzy3d/vtk-java-wrapper. My work on JOGL was motivated by running VTK on macOS (which was broken some time ago) and more recently to add Apple M1. I wish to pack VTK natives in Jars and make them available on my Maven repo for other java developers.

I do not forget that everyone is interested by having Jzy3D and JOGL-2.4 on Maven Central. Hope I can do this soon!