RE: Maven for Software Installation
The sticky wicket of .NET Framework and native builds I just talked someone in GB out of using .NET Framework and GAC for the reason when you load an assembly into GAC you will have to hook that assembly to a native binary There are so many variations of native builds for each OS and with .NET you would need to permutate that array with every conceivable .NET assembly version(e.g. 1.x,2.x,3x) the plugin that would manage this NativeBuild-DotNetFramework matrix (maven-nar-plugin) would be stressed to the limit finally who would store all these binaries (and assemblies) thoughts? Martin __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > From: mar...@headcrashing.eu > To: users@maven.apache.org > Subject: RE: Maven for Software Installation > Date: Fri, 22 Jun 2012 22:40:53 +0200 > > Ideally for this, Maven (and such, the JVM) would be contained as an itegral > part of the popular operating systems like Windows, MacOS and Linux. What a > perfect world. ;-) > > > -Original Message- > > From: Eric Kolotyluk [mailto:eric.koloty...@gmail.com] > > Sent: Donnerstag, 21. Juni 2012 21:54 > > To: Maven Users List > > Subject: Maven for Software Installation > > > > 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: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
RE: Maven for Software Installation
Ideally for this, Maven (and such, the JVM) would be contained as an itegral part of the popular operating systems like Windows, MacOS and Linux. What a perfect world. ;-) > -Original Message- > From: Eric Kolotyluk [mailto:eric.koloty...@gmail.com] > Sent: Donnerstag, 21. Juni 2012 21:54 > To: Maven Users List > Subject: Maven for Software Installation > > 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for Software Installation
On 21 Jun 2012, at 20:53, 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? It definitely makes sense, and can be (and has been) done now without any modification to maven code or Apis. I designed a computation cluster for someone a few years ago that used a standard maven repo and part of the maven API to automatically resolve, download and install the nodes that ran the cluster. The client would say to the cluster, "dear cluster, please calculate this for me, using version x.y.z of model Z", and the cluster would download the code it needed where necessary. We no longer needed to upgrade or downgrade code, the cluster just did the right thing automatically. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for Software Installation
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 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: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven for Software Installation
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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven for Software Installation
I have thought about this as well, but thinking that perhaps a pom with dependencies and then using the assembly plugin to create the final distribution would be good... but then I realized that it would be better in a corporate environment to provide them in a single tested archive or deployment automation package. You can be certain in such an environment that nothing has been tampered with, and that all required pieces are actually available. The idea is neat, but it has certain traceability drawbacks. I've been a little more interested in the possibility of deployment using 'git'. The ease of upgrade with a fetch/pull and rollback with a simple checkout command has me intrigued. It also has great anti-tamper and traceability built in. I suppose all of these concerns are more pertinent in a server deployment environment as opposed to an end user client application experience though... I can see where a distribution through maven would be nice there, although if that trended you may find that central repos wouldn't be too happy about an uptick in traffic. -Original Message- From: Eric Kolotyluk [mailto:eric.koloty...@gmail.com] Sent: Thursday, June 21, 2012 2:54 PM To: Maven Users List Subject: Maven for Software Installation 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
