One of the things I have been doing is creating uber-jars. This is mighty nice in that that you can just do something like
java -jar uber.jar and everything just starts, whether it be a client application (i.e. GUI) or a service. In my case, the application/service is also the installer. If everything is already installed it just starts, otherwise it installs the missing pieces and then starts. It is nice in that it is self healing. The problem is my uber.jar can get huge as it also a FAT binary. Ideally you could create start.jar that just contains your specific code, and the maven-based launcher, for example java -jar start.jar that would install the maven technology if necessary, and then bootstrap itself up until everything is installed and running. If you prefer the conventional separation between the installer and the application/service you might use java -jar setup.jar // to install java -jar start.jar // to run the application or service My particular goal is to keep things as simple as possible for the person installing or running the software (which is often me), relying as much as possible on convention over configuration. I like Roy's point about security and traceability. I also like Pascal's point about a Garbage Collector. Looks like I will have to register for the webinar next week :-) Cheers, Eric On Thu, Jun 21, 2012 at 1:41 PM, Pascal Rapicault <[email protected]>wrote: > The approach you are describing is akin to what the Eclipse provisioning > platform (aka p2) provides with its concept of bundle pool (equivalent of > GAC). > > From experience, while this works in practice (for example a commercial > distro of Eclipse called Yoxos ships like this (I'm not affiliated with > them)), depending on the sort of applications you are delivering, it > happens that consumers like being able to have access to an all-in-one > download for ease of consumption and avoid uncertainties at install time. > After all it is much easier for someone to validate the checksum of a zip > rather than the proper behaviour of an installer. > > The other thing to consider in this space is the ever growing size of the > cache. While in Maven this is quite easily handled by just deleting the .m2 > folder, this approach would not work for such a cache, and then requires > some GC to be put in place. > > All in all I think it is definitely a space to look into where the > simplicity of expressing dependencies and metadata with maven coupled to > the runtime characteristics of p2 (thread safe local repo, transactional > install, GC) could really allow to put together a solution quite rapidly. > > On 2012-06-21, at 3:53 PM, Eric Kolotyluk wrote: > > > I have brought this notion up before, but I have been thinking about it > a bit more. > > > > Would it make sense to use Maven technology for software deployment and > installation as opposed to just builds? > > > > What I envision is something akin to the Global Assembly Cache in .NET, > but for Maven artifacts. In particular, the local repository would act like > a GAC, but you might want to separate a system local repository from the > user local repositories. > > > > The basic idea is that when deploying/installing software you would not > bundle all your dependent artifact into your installer, rather you would > just bundle their coordinates. At installation time you would install the > Maven Installer if it was not already there, then your installer would work > in conjunction with the Maven Installer. Basically the Maven Installer > subsystem would simply download the dependent artifacts from Maven Central > or elsewhere, and put them in the System Repository (similar to the GAC). > > > > One benefit of this is that if you have a lot of software that all > reference the same artifacts, they can share copies. Other benefits would > be similar to those for the .NET GAC, although hopefully we could avoid > some of the problems the GAC has created. > > > > Another benefit is that installers could be smaller by not bundling in > dependent artifacts. Installation could be faster in that if dependent > artifacts are already in the System Repository downloading and installing > them is unnecessary. > > > > So am I just thinking crazy, or is there any potential benefit to this > idea? > > > > Cheers, Eric > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
