search

averbraeck / djunits

Delft Java UNIT System for using strongly-typed quantities and units
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

Break the circular dependency between djunits and djutils #18

Closed averbraeck closed 1 year ago

averbraeck commented 1 year ago

The djunits project was made dependent on djutils, to avoid code duplication for the Throw, Try, URLResource and NumberParser classes. Also, the tinylog Logger and CategoryLogger can be used by djunits now.

On the other hand, djutils is dependent on djunits for the djutils-cli, djutils-data, djutils-eval, and djutils-serialization modules that all use djunits.

The problem is that we now cannot make a new release of djunits that uses the latest version of djutils while releasing the latest version of djutils that is dependent on the latest version of djunits. One of them will always use the one-but-last version...

There are three (and possible more) solutions. @WJSchakel and @OTSim : seeking your input on this.

  1. As before, copy the few classes that djunits needs into djunits. To make it more clear, we could even give the classes the path org.djutils. When changes in djutils occur, just copy the verbatim code into djunits. This way, djunits also stays 'clean' and is dependent on as few other packages as possible. Advantage: easy, and no overhead taken into djunits. Disadvantage: code duplication and possible inconsistencies between projects.
  2. Separate out the base djutils package as a separate project. This way, both djunits and the rest of djutils can be dependent on this project. Advantage: clean solution without code duplication. Disadvantage: more projects to maintain, and losing the tight integration n the djutils ecosystem.
  3. Combine djunits and djutils into one project, and make djunits a module of the djutils project. This can be done while keeping the org.djunits package name -- it will just be dependent on a djutils-parent pom file, and versioning will have to stay consistent with djutils (this causes an immediate problem, since djunits is at v 5.1.1 while djutils is at v 2.1.9. We should bump djutils to v 6.0.0 to avoid version clashes for djunits. Advantage: tight integration between djunits changes and its usage in djutils. Disadvantage: very different projects combined (djunits has also generators and a demo project -- what to do with them?), more complex project to maintain, versioning issues.

For now, I am thinking about a quick solution using (1) above, but should that also be the long-term solution?

WJSchakel commented 1 year ago

My preference would be option 2, at least in the long term. The name could be djutils-base.

djutils-base < djunits < djutils

The main reason is confusion, e.g. when importing classes, in option 1. To me option 3 ruins how clean djunits is. It has very little to do with almost everything in djutils.

I would add the tinylog functionality in djutils-base so it can be used in djunits.

WJSchakel commented 1 year ago

The disadvantage "the tight integration in the djutils ecosystem" is not very clear to me. Djutils is a bag of useful things, some of which use each other. But I see no logical reason why it has to stay one bag. Two smaller bags, where one (indirectly) depends on the other seems fine to me.

averbraeck commented 1 year ago

About the 'ecosystem' remark: right now, djutils-base (aka djutils) is a module inside the djutils project, together with the other modules. Versions for all modules are updated at the same time, since all other modules in the djutils project are tightly dependent on the djutils-base project.

One disadvantage of moving djutils-base out is that it becomes a separate project in github, with its own pom file and dependencies to maintain, so it will get its own upgrades, its own new releases, its own registration of the project in Maven Central, etc. All maintenance efforts will have to be done on two projects instead of one. Since it typically takes a few hours to sometimes 1-2 days of work to make a new release that incorporates all kinds of upgrades (where lots of issues have to be resolved), this will now have to be done two times...

But I do agree. It's the only clean option... No code duplication, no useless integration between two independent projects. And we DO need to be able to release djutils-base (or just 'djutils') separately from the rest of djutils and djunits.

averbraeck commented 1 year ago

The separation of the djutils-base project has been described in issue https://github.com/averbraeck/djutils/issues/24 in the djutils project.

averbraeck commented 1 year ago

djunits has been made dependent on the separate project djutils-base, breaking the circular dependency. This allows full usage of the classes and data structures in djutils-base (Throw, Try, UrlResource, CategoryLogger, immutable collections, etc.).