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] > >
