Java 3D: Use Maven to build, and publish Maven artifacts

The Maven build seems to work very well :)

Sven suggested to choose "com.jogamp.java3d" as a replacement of "javax.media". This is the very last thing that I'll do with a few syntactic changes (use of generics for return type refinement).

gouessej wrote

The Maven build seems to work very well :)

Glad to hear it!

gouessej wrote

Sven suggested to choose "com.jogamp.java3d" as a replacement of "javax.media". This is the very last thing that I'll do with a few syntactic changes (use of generics for return type refinement).

For what it's worth, I did the renames (to org.scijava.java3d prefix) in these commits:

* https://github.com/scijava/vecmath/commit/f9291bcac1ad02ea7fde6698116280818e0928c1
* https://github.com/scijava/java3d-core/commit/925def36f84207ed78c9557522688f89dae3ec9e
* https://github.com/scijava/java3d-utils/commit/dbc441832672fbeddefd6014d9b43bbe703c5533

If it would help you, I could rewrite those commits to use org.jogamp.java3d instead, and file them as PRs. There are several "gotchas" to watch out for—especially in java3d-utils, which has some weirdo subpackages like com.sun.j3d.utils.scenegraph.io.state.javax.media.j3d.

ctrueden wrote

If it would help you, I could rewrite those commits to use org.jogamp.java3d instead, and file them as PRs.

I decided to just go ahead and do it, since I had the work 80+% completed already.

* https://github.com/gouessej/vecmath/pull/2
* https://github.com/gouessej/java3d-core/pull/3
* https://github.com/gouessej/java3d-utils/pull/3

I hope this helps!

Hi

Thank you for the excellent work but please can you use "com.jogamp.java3d" instead of "org.jogamp.java3d"? I would prefer moving the source code from src and src/main/java. I'm going to try to do it by myself now.

I don't want to ruin your stuff, let me know whether you want to do the changes suggested above by yourself.

Actually, your changes are more consistent than Sven's suggestion as we already use "org.jogamp" in some other places. I'll keep yours, let's go for "org.jogamp".

OK, thanks. And I like org.jogamp better anyway since JogAmp is not a for-profit company.

I agree with your point about using the standard Maven directory conventions, though. Since you seem eager, I'll back off so we don't step on each other's toes. Just let me know if you need any help with it.

I just do my job. When I maintain a project, I get the job done as soon as possible. I'm currently fixing java3d-utils.

The packages have been successfully relocated. Now, I'm trying to switch to the standard directory layout so that I can implement the Gradle build too, I'll have to edit .gitignore.

I have removed the default goals because we usually don't choose one in our projects. I try to keep the Maven builds of the engines as homogeneous as possible.

The layout is more standard now but there are a few GIF images and HTML files that should be moved into src/main/resources.

Feel free to make some other pull requests. I need to have a rest. Thank you for your precious help.

gouessej wrote

Feel free to make some other pull requests.

I believe these will sort out the remaining Maven-related path issues:

* https://github.com/gouessej/java3d-core/pull/4
* https://github.com/gouessej/java3d-utils/pull/4

gouessej wrote

Thank you for your precious help.

You're very welcome! Thank you again for keeping Java 3D alive!

The Gifs and html are from some of the custom javadoc-generation code that used to exist in the old ant build files, I never updated that part of the build procedure, and was the reason I kept the old version around for future reference.

Harvey

Sorry guys, i didn't follow recent discussions in the forum, but why on earth, do you really need to change package names???
This would prevent to easily switch between previous Java 3D implementations

As long as it's sustainable, I plan to keep Sweet Home 3D compatible with old PPC computers (yes, there are still some people using such computers), and the issue I reported still prevents me to use the latest version under Windows.

Hi

Manu wrote

Sorry guys, i didn't follow recent discussions in the forum, but why on earth, do you really need to change package names???
This would prevent to easily switch between previous Java 3D implementations

At first, we aren't allowed to use "javax" in our package names, what we did was illegal. We had to relocate the packages in JogAmp too.

Secondly, there are still recurring problems of name clashes under OS X, i.e an obsolete version of Java3D (1.3?) bundled with OS X is loaded in priority as an extension and there is no clean solution to solve this problem. All solutions except packages relocation are over-complicated and/or not reliable enough and/or difficult to maintain and/or have some nasty side effects:
- setting java.ext.dirs to "" breaks NIO 2
- we can't use Java 1.9 on very old Macs
- using some custom class loaders wouldn't work in some cases (containers & web servers?)
- modifying the class path at runtime would rely on some private APIs subject to changes

Thirdly, there is a new "security" feature driving harder to delete the obsolete libraries installed by default in OS X 10.11. If you can't skip those craps, it's hopeless, Java3D (1.3?) just crashes.

There is no other solution than changing the package names. The extension mechanism has been removed from Java in Java 1.9 but tons of people still use Java 1.8 and Java 1.7.

I understand the annoyance for you as you use both Java3D 1.5.2 and Java3D 1.6.0. However, there are only a very few contributors on Java3D, we can't maintain several versions of Java3D and it would be a bad idea anyway as it wouldn't solve the problem of name clash.

Manu wrote

As long as it's sustainable, I plan to keep Sweet Home 3D compatible with old PPC computers (yes, there are still some people using such computers), and the issue I reported still prevents me to use the latest version under Windows.

I don't want to bother anybody but I'd like to drop Java 1.6 support because there are still some people who want to use Java3D with Apple JRE whereas it's deprecated, no longer maintained and buggy. I can keep Java 1.6 support but Apple JRE will remain officially not supported. When a bug in AWT affects Java3D, if it occurs only with Apple JRE, I have no access to its code, I have no way to work around it.

Virtual Box only sees the Microsoft GDI renderer which supports only OpenGL 1.1 whereas Java3D has never supported immediate mode, it's based on retained mode since the very beginning. Supporting immediate mode would require to rewrite a huge part of the pipeline and numerous features wouldn't be supported, it's not worth it. I'm sure that it's possible to setup Virtual Box to see the real OpenGL driver provided by the official GPU manufacturer, it would solve your problem.

There is still a bug in Parallels, it's up to its maintainers to fix it, it doesn't come from JOGL. We already filled a bug against Parallels but they have done nothing as far as I know.

The previous Java3D implementations are unmaintained.

I'm sorry but I'm a bit surprised by your reaction ("why on earth", "???") as we explained a lot here why this change is required. Apple machines are designed to be difficult to repair and to become obsolete earlier than personal computers, I can still run JOGL on some PCs bought in 2004. As far as I know, OpenJDK on PowerPC supports Java 1.7 but JOGL 2 doesn't support OS X 10.4 and it's up to Apple to allow upgrades to more recent versions of OS X or not.

I do my best, I spent a lot of time in looking for another solution. I'm tired and a bit upset. We discussed a lot about this problem, I don't like breaking things. PowerPC G4 is still well supported under Debian, Ubuntu and Linux Mint.

Years ago, I found a solution to override the default Java 3D 1.3.1 libraries found by default under Mac OS X, using a custom classloader. It works very well with Java Web Start and applets, and for applications, you just have to set java.ext.dirs to change the priority of jar locations. I understand though that these solutions are not perfect and have some limitations you described. Too bad that things have to be broken. I guess I'll stick to Java 3D 1.5 and 1.6 as long as possible...

By the way, Parallels finally answered to my request. Do you think think it's helpful to fix Jogamp / Java3D or what should we recommend to Parallels?

Hi

Manu wrote

I guess I'll stick to Java 3D 1.5 and 1.6 as long as possible...

Please don't stick to Java3D 1.5 and 1.6. I won't backport the bug fixes. Only Java3D 1.7.0 will be maintained.

Manu wrote

By the way, Parallels finally answered to my request. Do you think think it's helpful to fix Jogamp / Java3D or what should we recommend to Parallels?

Actually, the OpenGL context is current on the thread when we can glColor4f. If it wasn't the case, tons of other drivers would complain too, even without using Parallels.

Where have you posted the logs? I'd like to ensure that the OpenGL context was created and current on the right thread. I have to prove that JOGL isn't responsible for the failure in the OpenGL context creation or in the very first OpenGL call. If I see that the OpenGL context was current, it will be up to Parallels to fix something.

Thanks for your answer

gouessej wrote

Please don't stick to Java3D 1.5 and 1.6. I won't backport the bug fixes. Only Java3D 1.7.0 will be maintained.

I know you won't maintain old versions, and fully understand why. But as long as Sweet Home 3D works correctly with older versions, I don't see the problem to keep them. At the moment, I would like to use Java 3D 1.6 under Windows too, in the hope it could fix issues that some Windows 10 users reported. But even in that case, it looks like that running the 32 bit version fixes the problem, so it's probably a problem in 64 bit drivers.

gouessej wrote

Where have you posted the logs?

It's here. Just tell me if you want the full log.
From this stack trace and resetImmediateRendering implementation, I'm not sure the call to glColor4f is the very first call to JOGL. Feel free to give any information that will help Parallels to fix this issue, if you get convinced that it's their fault. Thanks for your patience

The OpenGL context is made current before calling resetImmediateRendering() in Renderer.doWork(). Please enable all debug logs and test again. If I'm sure that it doesn't come from JOGL, we'll be able to give the maintainers of Parallels some information to fix this bug.