0

My application has 4 Java packages. 

com.me.utilities 
com.me.widget 
com.me.analysis 
com.me.interface

All packages depend upon the utilities. The widget package depends upon the interface package.

The utilities might be valuable to other applications so it ought to be a package of its own. The analysis does not depend upon the widget and the interface so analysis ought to be a package of its own. The interface might change because the organization that it interfaces to might go out of business so the interface ought to be a package of its own.

This is just one application that produces one executable.

On the basis of this organization I do commits on each package but not on the executable. I want to start to commit the executable. One way would be to commit the executable in a new git archive without any connection to the source but that sounds reckless to have an executable and no formal way to tie it to source code.

Another way, which sounds a little inefficient, would be to simply start a new git archive that "adds" the source code of all 4 Java packages, each of which has many Java files, and also "add" the executable. This seems a little strange because it fails to respect the 4 existing git archives that already know about their respective collections of source code.

What is the right way to tie these 4 packages together with their common executable?

I use SmartGit for routine commits and I use command line git for reverting. I am willing to stop using SmartGit if the solution to this inquiry necessitates it.

H2ONaCl
  • 10,644
  • 14
  • 70
  • 114
  • I don't understand what you're asking. For example: *it ought to be a package of its own*. It is a package already, so what's the problem? *I do commits on each package but not on the executable*: what does that mean. An executable is an artifact produced by building the application from the sources. Why would you "commit on the executable"? What is the problem you're trying to solve? – JB Nizet Oct 28 '18 at 07:00
  • @JBNizet I am justifying or explaining the organization when I say "it ought to be a package". I want to commit the executable because I believe consecutive builds with zero changes to source code do not result in the same executable if you do a binary compare if I recall correctly. It's also more convenient to have access to old executables. – H2ONaCl Oct 28 '18 at 07:03
  • Then you should fix your build. They should result in the same executable. Except maybe for a property containing the build time itself or something like that. And producing the exact same binary doesn't really matter. What matters is that all the binaries produced from the same sources behave the same way. If you want to version the jar file produced at each release, then store that in an artifact repository (nexus, artifactory, etc.). But not in your git repo. – JB Nizet Oct 28 '18 at 07:07
  • @JBNizet If the build time is in the executable it might be hard to get rid of it. – H2ONaCl Oct 28 '18 at 07:08
  • But what exactly is the problem with two artifacts that are not equal byte-to-byte, but behave exactly the same way? – JB Nizet Oct 28 '18 at 07:10
  • @JBNizet I cannot prove two executables behave the same through testing (because the set of tests that exist will always be a small faction of the set of tests that are possible to create). It's better to get an old executable without building. – H2ONaCl Oct 28 '18 at 07:13
  • Then archive the artifacts in an artifact repository. That's what they're for. – JB Nizet Oct 28 '18 at 07:13
  • @JBNizet, if "artifact repository" is a good answer may be you will write it as an answer. – H2ONaCl Oct 28 '18 at 07:17

1 Answers1

0

It looks like what you're looking for is an artifact repository, like Nexus, Artifactory, JCenter, etc.

That's where you typically publish the artifacts produced by a build every time you do a release.

That's also what allows build tools and IDEs to get artifacts for the libraries a project uses. So if you end up turning your utilities package into a separate library, used by several different projects, you'll need to publish it in such an artifact repository. Both Gradle and Maven get their artifacts, but also allow publishing artifacts, to such artifact repositories.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255