Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » Modular project: How add dependency to other project only on runtime to solve cyclic dependency? (Modular project: How add dependency to other project only on runtime to solve cyclic dependency? )
Modular project: How add dependency to other project only on runtime to solve cyclic dependency? [message #1781239] Sun, 04 February 2018 15:26 Go to next message
Robert Koszewski is currently offline Robert KoszewskiFriend
Messages: 2
Registered: February 2018
Junior Member
Hi,

I have a project that basically consists of 2 modules. I have a Eclipse workspace and 2 projects which represent those two modules.

To go a bit more in depth:
- Project 1: Core Module (Has Core Implementation and API Interfaces)
- Project 2: Auxiliary Module (A Server)

Project 2 requires to have Project 1 as Dependency in order to access the API Interfaces during compile time. But the problem is that Project 1 requires Project 2 in order to work properly (This is only a runtime requirement though).

So when I add in each project the other project as dependency a cyclic dependency is shown, as Eclipse doesn't knows in which order to compile the classes.

The way I managed to make this work is that I added the "bin" folder from Project 2 as dependency to Project 1 as also all of Project 2 dependencies (Which are maven based). This though makes the whole project completely bound to my system, as all paths are adjusted to my computer setup.

Is there any proper way to specify another project to be dependency only on "runtime", and not on "compile" and avoid the cyclic redundancy?
Re: Modular project: How add dependency to other project only on runtime to solve cyclic dependency? [message #1781433 is a reply to message #1781239] Wed, 07 February 2018 10:08 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29589
Registered: July 2009
Senior Member
This page suggests that cycle should be diagnosed as an error:

https://wiki.eclipse.org/Java9/Examples

Forgive me if it sounds arrogant, but I don't think you should try to make the tool solve this problem. You should try to avoid the problem entirely with a better design. Whatever the Core Module needs, it should use some type of service mechanism to get access to what it needs, so that it can be supplied by other implementations of that extension or service. Google for "java 9 services" to find articles about this.



Re: Modular project: How add dependency to other project only on runtime to solve cyclic dependency? [message #1781436 is a reply to message #1781433] Wed, 07 February 2018 10:36 Go to previous messageGo to next message
Robert Koszewski is currently offline Robert KoszewskiFriend
Messages: 2
Registered: February 2018
Junior Member
Thanks for the suggestion. I am using a service like approach but using reflection. The dependency from Project 1 to Project 2 is during development only. The idea is to have Project 2 to be swappable with different implementations.

I finally found a way how to make it work by creating a third project which has as dependency Project 1 and Project 2 and simply launches Project 1 which then has Project 2 on its classpath and works correctly.

I'll give the Java 9 approach a try tough too.
Greetings.
Re: Modular project: How add dependency to other project only on runtime to solve cyclic dependency? [message #1781439 is a reply to message #1781436] Wed, 07 February 2018 10:49 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6066
Registered: July 2009
Senior Member
Hi

A traditional solution is to break the cycle by using an interface/implementation barrier.

Eclipse plugins have horrendous cyclic dependencies, but we don't care. The extension point mechanism means that the cycle is broken by depending on the extension point declaration rather than its many possible implementations.

In Java you may depend on an interface/service/registration that is resolved at run-time.

In your case with Project 2 swappable, all Project 2 variants could refine AbstractProject 2 APIs that do not depend on Project 1. Project 1 then depends only on AbstractProject 2. No cycle.

Regards

Ed Willink
Previous Topic:IProgressMonitor missing
Next Topic:How to load a formatter profile to a workspace configuration
Goto Forum:
  


Current Time: Tue Oct 16 22:51:33 GMT 2018

Powered by FUDForum. Page generated in 0.02098 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top