Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ctrueden opened this issue Apr 9, 2015 · 6 comments

Comments

Projects
None yet
2 participants
@ctrueden
Copy link
Contributor

commented Apr 9, 2015

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

This comment has been minimized.

Copy link
Owner

commented Apr 9, 2015

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
#17.

@ctrueden

This comment has been minimized.

Copy link
Contributor Author

commented Apr 9, 2015

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

This comment has been minimized.

Copy link
Owner

commented Apr 9, 2015

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

  1. Merging the two projects
  • incompatible licenses (well, kind of)
  • fedora would be willing to ship Java3d-core, but would not be wiling to
    ship java3d-utils
    so I'd vastly prefer any solution that makes java3d-utils sit on top of
    j3dcore without any
    circular dependency.
  1. 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)

  2. 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.

  3. 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
#14 properly until this
issue is resolved.


Reply to this email directly or view it on GitHub
#17 (comment)
.

@ctrueden

This comment has been minimized.

Copy link
Contributor Author

commented Apr 9, 2015

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.

  • This is a quick and dirty hack. The downside is that reflection brings class loading issues with it. You have to be very careful that things still work as expected when custom class loaders (e.g., OSGi) are being used.

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.

  • To do this, we'd have to settle on a reasonable services framework. Probably easiest to use Java's built-in ServiceLoader; this is how e.g. JSR-223 scripting languages are provided.

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 9, 2015

@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.

ctrueden added a commit to scijava/java3d-core that referenced this issue Nov 25, 2015

Font3D: use the GeometryService as appropriate
This avoids a dependency on j3d-core-utils's com.sun.j3d.utils.geometry
package. If j3d-core-utils is present on the classpath, it can provide
the same backing implementation as before, but the option is now open
to provide an alternative service implementation with clean licensing.

This addresses hharrison#17.

ctrueden added a commit to scijava/java3d-core that referenced this issue Nov 25, 2015

Font3D: use the GeometryService as appropriate
This avoids a dependency on j3d-core-utils's com.sun.j3d.utils.geometry
package. If j3d-core-utils is present on the classpath, it can provide
the same backing implementation as before, but the option is now open
to provide an alternative service implementation if desired.

This addresses hharrison#17.

ctrueden added a commit to scijava/java3d-utils that referenced this issue Nov 25, 2015

Add GeometryService implementation
This code was migrated from java3d-core's Font3D class,
in order to address hharrison/java3d-core#17.
@hharrison

This comment has been minimized.

Copy link
Owner

commented Jan 4, 2019

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

@hharrison hharrison closed this Jan 4, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.