search

hharrison / java3d-core

Fork of the javax.media.j3d package
GNU General Public License v2.0
85 stars 39 forks source link

Circular dependency between java3d-core and java3d-utils #17

Closed ctrueden closed 5 years ago

ctrueden commented 9 years ago

The class javax.media.j3d.Font3D of j3d-core imports classes from package com.sun.j3d.utils.geometry, which is part of j3d-core-utils. And the j3d-core-utils project imports many classes from j3d-core. This creates a circular dependency between artifacts.

My understanding is that the java3d-utils should depend on java3d-core, but not vice versa. Correct? If so, what is the best way to correct this issue?

hharrison commented 9 years ago

It has always been that way which is why you have to build java3d and java3d-utils together as one build currently.

There used to be more circular issues that I removed over time, this is the last one.

Harvey

On Thu, Apr 9, 2015 at 9:32 AM, Curtis Rueden notifications@github.com wrote:

The class javax.media.j3d.Font3D of java3d-core imports classes from package com.sun.j3d.utils.geometry, which is part of java3d-utils. And the java3d-utils project imports many classes from java3d-core. This creates a circular dependency between artifacts.

My understanding is that the java3d-utils should depend on java3d-core, but not vice versa. Correct? If so, what is the best way to correct this issue?

— Reply to this email directly or view it on GitHub https://github.com/hharrison/java3d-core/issues/17.

ctrueden commented 9 years ago

Thanks for the quick reply, @hharrison. The easiest way to fix it would be to just merge the two projects! But I understand if that is deemed somehow too disruptive of a change.

Do you have a preferred approach for eliminating the remaining circular references? There are several reasons it would be a really good idea to completely address this issue. For one thing, Maven does not support circular dependencies. So it will not be possible to address #14 properly until this issue is resolved.

hharrison commented 9 years ago

I'll try and give a brain dump of the issues involved while I have a few minutes.

1) Merging the two projects

2) The only remaining dependency is using the triangulator and normal generator from j3d-utils to break text characters into triangle arrays, if suitably licensed code could be writen/borrowed we could add that directly to java3d and be done with it. (I don't really have the time currently)

3) We could ask Oracle to release a plain BSD-licensed version of the files in question, import those to java3d-core and remove them from java3d-utils...but getting anyone over there to pay attention has been fruitless.

4) Clever option 4 that you come up with ;-)

Harvey

On Thu, Apr 9, 2015 at 9:40 AM, Curtis Rueden notifications@github.com wrote:

Thanks for the quick reply, @hharrison https://github.com/hharrison. The easiest way to fix it would be to just merge the two projects! But I understand if that is deemed somehow too disruptive of a change.

Do you have a preferred approach for eliminating the remaining circular references? There are several reasons it would be a really good idea to completely address this issue. For one thing, Maven does not support circular dependencies. So it will not be possible to address #14 https://github.com/hharrison/java3d-core/issues/14 properly until this issue is resolved.

— Reply to this email directly or view it on GitHub https://github.com/hharrison/java3d-core/issues/17#issuecomment-91286196 .

ctrueden commented 9 years ago

Here are some "option 4" possibilities:

4a) In Font3D, access GeometryInfo and NormalGenerator only via reflection. And if the classes are not found, then somehow fail gracefully, or throw an appropriate exception.

4b) Use dependency injection / service discovery. Specifically: add some kind of geometry service that declares the needed API, then call it from Font3D. Provide a stub implementation that simply throws exceptions in j3d-core. And in j3d-core-utils, provide a geometry service that calls into GeometryInfo and NormalGenerator to do the work.

4c) Split the projects into more pieces, to ensure the dependency graph has no cycles. This would also be disruptive, and have significant consequences, including making the project structure less intuitive. I list it here mainly for completeness.

If option 4a or 4b interests you, let me know and I can look into creating a patch set for it.

ctrueden commented 9 years ago

@hharrison OK, I took a crack at option 4b. Right now I implemented on top of my maven branch, since that was much easier for me (makes developing in Eclipse a breeze). But if you like the approach, I am willing to rebase it over master so that it works with the Ant-based build system. Just let me know.

hharrison commented 5 years ago

Merged your changes as-proposed into version 1.6.2, thanks a lot for the work and sorry for the wait!