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