WDYT about this http://jira.codehaus.org/browse/MNG-1643 Thanks.
Cheers, Vincent 2005/11/19, Vincent Siveton <[EMAIL PROTECTED]>: > Hi, > > I totally agree with Dan: an installer is a kind of archiver. > So, we need to create an InstallerArchiver class and implement > createArchive(). > > I think we could easily update the assembly plugin to support > installer feature. In the assembly descriptor, we just need to add new > format (eg nsi, innosetup...) and to update the AbstractAssemblyMojo > class to handle these new formats in the createArchiver() method. > > IMHO to create an installer, we need to : > * create a script: we could easily generate a script with > plexus-Velocity component. I imagine out-of box templates for NSIS and > InnoSetup. Of course, the user could define his own template and > template properties for a specific format (ie 'ownInstaller' format > instead of 'nsi' in the AbstractAssemblyMojo class). > * create the installer (I mean the .exe file). In fact, the user could > define the compiler path (ie C:/Program Files/NSIS/makensis.exe) and > the third party do the job. > > I'm pretty sure all this needs to be refined but it is a first step. > > WDYT? > > Cheers, > > Vincent > > > 2005/11/18, dan tran <[EMAIL PROTECTED]>: > > Hi John, I have special interest in making a assembly out of some type > > installer aswell. > > So I will answer base on what have worked on maven-assembly-plugin > > First, from my impression, plexus-archiver is interface we want to > > implement for installers > > ( it is just an another kind of archiver). So the user just need to setup > > the assembly > > and the nullsoft archiver will handle the rest. > > There is a jira that will make the assembly deployable, perhaps has its own > > lifecycle like you have stated. > > While waiting for more answer, I would suggest to implement > > deployable-assembly-plugin > > with its own lifecyle (package type). The plugin would issue a Commandline > > to exec mvn assembly:assembly. > > The lifecyle then take care of setting up the output of the assembly so that > > install and deploy can do the rest. > > However this implementation is limited since it can only hanle one archive > > type. > > -Dan > > > > On 11/18/05, John Allen <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > This is a reposting looking for comments from m2 developers. > > > > > > > > > I am in the process of writing a NullSoft Installer plugin and wish to > > > discuss its design and usage in respect to the assembler plugin. > > > > > > The assembly plugin has been designed to operate in a stand-alone fashion, > > > firing off the project's package build, rather than cooperate within an > > > existing lifecycle (@execute package declaration) > > > > > > This design choice confuses me a little as i would have thought that a > > > distribution assembled project should just be another lifecycle phase of a > > > project (admittedly a rather later one) and should be invoked by the > > > normal > > > project build control but I guess the thinking was that assembly was > > > something that you'd do rarely and would therefore would be best invoked > > > via > > > an explicit '#mvn assembly:assembly' invocation, and that the resulting > > > 'assembly-packaged' artefact(s) (directory/.zip/etc), would not be of any > > > use to any other build lifecycle component. > > > > > > However the assembly:directory plugin performs the very useful job of > > > preparing a distribution area which is exactly the kind of thing a > > > thirdparty installer will need done before they can generate a custom > > > distribution (i.e. a NSIS installer exe). > > > > > > Which leads me to the design questions regarding NSIS plugin. > > > > > > Should the assembly zip or tar be any different to the NSIS-exe archive? > > > Semantically they are the same, a package that is interpreted by an > > > external > > > agent (winzip/tar, or the OS in the case of an exe) > > > > > > I see the steps for building a distribution to be: > > > > > > *) build required distribution artefacts > > > *) prepare a distribution area (layout the directory structure, copy in > > > deps > > > etc) > > > *) generate distribution media (zip, bzip, NSIS-exe) > > > > > > If running assmbly:assembly is to remain the way of initiating the > > > distribution packaging for a project should the NSIS executable just be a > > > type of complex archiver that's configured as part of the assembly plugin? > > > > > > Or should assembly plugin be made to be lifecycle cooperating so it can be > > > integrated into wider 'distribution build' that would employ the assembly > > > followed by the NSIS packager? > > > > > > Or should a NSIS exe be a project packaging type in its own right, and a > > > separate project be used to assemble and generate the resulting exe (in > > > which case the assembly:directory functionality would still be required > > > but > > > that > > > can be easily done with some refactoring to the assembly mojos (MNG-1462 > > > has > > > done this)). > > > > > > So... whats the thinking behind the assembly plugin and its @execution > > > package design and how should assembly be integrated with other > > > distribution > > > packagers? > > > > > > Thanks for your time. > > > > > > John > > > > > > --------------------------------------------------------------------- > > > 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]
