Geek Answers Handbook

Ivy best practice: split code into multiple projects or use a single project with multiple configurations?

At work, we have a number of projects that need to share some common code. Some code is completely universal, and part of the code is shared only by a subset of our projects. Should I split the common code into two separate projects or use two different ivy configurations for one project?

Option 1 - Two separate projects.

  • Proj 1 - Common published as standard
  • Proj 1 - Common-xml published as standard configuration

Potential problems: I need to have two separate projects: two separate assembly files and two separate ivy files.

Option 2 - one project, several ivy configurations for different artifacts

  • Artifact 1 - General published as primary
  • Artifact 2 - Generic xml published as core-xml

Potential problems. I may have to maintain separate source directories in the same project.

In any case, the generic xml component can rely on the generic core component.

So SF, what should I do to maintain my common code? What problems did I miss using two methods, and what are any other pros / cons or alternative solutions?

+4
source share
1 answer

Hmm, it really comes down to how you prefer to manage your source code. But first I'll ask you if you really need to split the source. The idea of ​​the commons project is to encapsulate code, classes, interfaces, etc., which can be used as a common toolkit by other projects. This does not mean that these projects should be used by everyone at Commons. They can use only a small part. This is great, and it can happen that splitting your Commons is effective over optimization.

Think about it - what happens if your next project uses a different subset of the Commons library? are you going to split again?

+1
source

More articles:


All Articles