m2 developers rfc: The assembly plugin ans thirdparty installation builders (REPOST)

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

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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

[Vincent Siveton <vi...@gmail.com>]

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

Cheers,

Vincent

2005/11/19, Vincent Siveton <vi...@gmail.com>:
> 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...@gmail.com>:
> > 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...@hotmail.com> 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@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
>

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

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

[Vincent Siveton <vi...@gmail.com>]

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...@gmail.com>:
> 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...@hotmail.com> 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>

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

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

[dan tran <da...@gmail.com>]

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...@hotmail.com> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>