diet4j is for production servers. It has no maven dependencies itself. It can run command-line applications as well. It could be fairly easily extended to cover other kinds of module systems as well — including simultaneously.
My goal is really to provide a few foundational building blocks so that Java modules aren’t forever 2nd (third, fourth?) class citizens on Linux distros. Few distros ship any Java modules, but lots of them ship perl modules and python and node and what have you. It’s my belief that diet4j could change that. P.S. I needed it for my own distro, UBOS: http://ubos.net/ <http://ubos.net/> but it is independent of that. > On Jun 2, 2015, at 14:19, Federico Bertola <[email protected]> > wrote: > > > Great, thanks for the effort! > > One question though: whats the difference between the exec:java or > <tomcat|jetty>:run MOJOs and diet4j? > > Federico. > > On 06/02/2015 08:28 PM, Johannes Ernst wrote: >> Maven is great for breaking gigantic code bases into many little modules, >> with identified dependencies. This allows incremental builds etc. >> >> And then, to run that code, we usually put all together again into a >> uber-mega-JAR or WAR, or with mile-long class paths. While sometimes this >> makes sense, often it does not. >> >> diet4j can run command-line apps, and Tomcat web apps, similarly to how >> maven builds projects: simply specify the name of the top project, and >> diet4j assembles all the other JARs automatically for the run. >> >> E.g. if your project hierarchy looks like this: >> Project A >> Project B >> Project C >> Project D >> >> you can say: >> >>> diet4j A >> which will read the POM in A.jar (in ~/.m2/repository, or a location of your >> choosing), determine run-time dependencies, then recursively look for B.jar, >> C.jar and D.jar, load them into separate ClassLoaders, hook up dependencies >> and jump on the main program (if it has one) of Project A. >> >> No jar-with-dependencies and stuff like that required. Usually no changes >> are required to maven projects or program structure. >> >> As I said, it may not be for all people, but it is for some who want to >> distribute changes incrementally, avoid rebuilding gigantic JARs every time >> some small change needs to happen, fit better into Linux-style package >> management etc. It’s also great for dynamically finding and loading modules >> without restarting the application. >> >> I’d love some feedback, it’s early days. >> >> http://diet4j.org/ <http://diet4j.org/> <http://diet4j.org/ >> <http://diet4j.org/>> >> >> Thank you, >> >> >> Johannes Ernst >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]>
