Eclipse Community Forums: Java Development Tools (JDT) » Modular project: How add dependency to other project only on runtime to solve cyclic dependency?

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? )

Show: Today's Messages :: Show Polls :: Message Navigator

Modular project: How add dependency to other project only on runtime to solve cyclic dependency? [message #1781239]

Sun, 04 February 2018 15:26

Robert Koszewski

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?

Report message to a moderator

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

Ed Merks

Messages: 33141
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.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

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

Robert Koszewski

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.

Report message to a moderator

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

Ed Willink

Messages: 7655
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

Report message to a moderator

Previous Topic:	IProgressMonitor missing
Next Topic:	How to load a formatter profile to a workspace configuration

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 03:02:26 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter