4 ms·

Can't you put the whole app folder into one JAR? Also, you could put all the jacks and plugs into a a separate JAR. So, you have two JAR files to include into e

Can't you put the whole app folder into one JAR? Also, you could put all the jacks and plugs into a a separate JAR. So, you have two JAR files to include into each project. I think you could have each JAR have src/main/scala/[Obvious folders] type structure, so for your app.jar you could have src/main/scala/app and src/main/scala/external for the external.jar. You can make it as granular as you need, but the more you break things up, the more packaging overhead you'll incur.

ttiurani 14y ago
The problem with one JAR is that you will then have to configure runtime in production which delivery is used and also, if there are alternative plugs (or jacks), what set of plugs you activate. That would have to be done with an external config file or database row, command line parameters or some super GUI. The problem is that those are really dangerous configuration options, because changing any of them, results in catastrophic failure: e.g. someone might accidentally change a plug configuration option to another value, and your MySQL turns into MongoDB which you don't have. That makes you want to _not_ have one JAR and then keep your fingers crossed that it is configured right. Optimally things should just work (tm) in production without any configuration. (Not to mention if you try to sell your software, you can not sell just one package because just by changing the configuration from delivery1 to delivery2 you get the second product for free.) With dynamic languages what you presumably would want to do is just zip the right files and that's that (although you still need system tests that verify that the zip has the right stuff in it), but with static languages it's more tricky. One way to get that would be to have A-core.jar that has all code that is common to every installation, and then A-installation1.jar with the right delivery and plugs for the first installation, and A-installation2.jar for files for the second installation etc.. Because in the installation JARs there would be only one delivery, and only one plug per jack (and one jack per contract), things would work without any additional configuration. Now the problem with Maven is that you can't easily get many JARs from one src/main/scala. Or can but things get complicated when start releasing stuff to repositories. Which results in the really messy directory structure I outlined above, or then you would have to figure out some other directory structure that would work better. Of course the best would be to hack Maven to work around the "one JAR per src/main/scala" limitation. Or write a maven-obvious-plugin. :) The backstory here is that packaging tools easily mandate directory structure. Directory structure in turn directs source packages (inverted URL in Java), and source packages tend to influence the architecture. The cool thing in Obvious is that by making the directory structure itself reflect the architecture, code is automatically steered towards good practices. Of course you can create a great code architecture with any directory structure, but in many cases _where_ you can put stuff, influence _what_ you put in there. So in some cases, it's actually the supposedly trivial packaging of sources that is a culprit for bad decisions. Which IMO makes packaging also non-trivial from an architecture standpoint.

ttiurani 14y ago

The problem with one JAR is that you will then have to configure runtime in production which delivery is used and also, if there are alternative plugs (or jacks), what set of plugs you activate. That would have to be done with an external config file or database row, command line parameters or some super GUI. The problem is that those are really dangerous configuration options, because changing any of them, results in catastrophic failure: e.g. someone might accidentally change a plug configuration option to another value, and your MySQL turns into MongoDB which you don't have. That makes you want to _not_ have one JAR and then keep your fingers crossed that it is configured right. Optimally things should just work (tm) in production without any configuration. (Not to mention if you try to sell your software, you can not sell just one package because just by changing the configuration from delivery1 to delivery2 you get the second product for free.) With dynamic languages what you presumably would want to do is just zip the right files and that's that (although you still need system tests that verify that the zip has the right stuff in it), but with static languages it's more tricky. One way to get that would be to have A-core.jar that has all code that is common to every installation, and then A-installation1.jar with the right delivery and plugs for the first installation, and A-installation2.jar for files for the second installation etc.. Because in the installation JARs there would be only one delivery, and only one plug per jack (and one jack per contract), things would work without any additional configuration. Now the problem with Maven is that you can't easily get many JARs from one src/main/scala. Or can but things get complicated when start releasing stuff to repositories. Which results in the really messy directory structure I outlined above, or then you would have to figure out some other directory structure that would work better. Of course the best would be to hack Maven to work around the "one JAR per src/main/scala" limitation. Or write a maven-obvious-plugin. :) The backstory here is that packaging tools easily mandate directory structure. Directory structure in turn directs source packages (inverted URL in Java), and source packages tend to influence the architecture. The cool thing in Obvious is that by making the directory structure itself reflect the architecture, code is automatically steered towards good practices. Of course you can create a great code architecture with any directory structure, but in many cases _where_ you can put stuff, influence _what_ you put in there. So in some cases, it's actually the supposedly trivial packaging of sources that is a culprit for bad decisions. Which IMO makes packaging also non-trivial from an architecture standpoint.