Re: m2 developers rfc: The assembly plugin ans thirdparty installation builders

[John Allen <jo...@hotmail.com>]

Vincent,

Thanks for your work on this, it works a treat :)

There's a trivial patch required to fix report download URLs but otherwise 
we're there.

Thanks again for your efforts.

Cheers,

John


WDYT about this http://jira.codehaus.org/browse/MNG-1643
Thanks.

Cheers,

Vincent

2005/11/19, Vincent Siveton <vi...@...>:
>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 <da...@...>:
> > 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 <jo...@...> 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: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> >
> >
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org