Brill Pappin wrote:
Sorry for the long post. I'm including the history in the post so others can
follow the discussion so far.
-----Original Message-----
From: Trygve Laugstøl [mailto:[EMAIL PROTECTED]
Sent: December 1, 2006 8:06 AM
To: Brill Pappin
Cc: [EMAIL PROTECTED]
Subject: Re: Just found your appassembler
Brill Pappin wrote:
I Just found your appassembler in the mojo snapshot trunk.
I was about to embark on something different but similar and was
wondering what you vision for appassembler was?
What I was about to start is a launcher/installer plugin that can
assemble an application, create native launchers (wrapper
being one)
and build an installer with all the content.
Yah, that's about right. The idea was also to make a generic
application descriptor that can be used in other situations, like
beeing able to update the application from a repository.
I like the update idea.
Got a few more that I haven't worked out. I also wanted the
ability to
bundle the JRE with the applications... We currently do
that where I
work by adding the JRE to the repository as a dependency
and a custom
plugin we wrote can pull it down.
It’s a rather large dependency however, so I don't know how
practical
it would be. The JRE that maven is launched from should be
fairly easy
to find, but then your limited to only one version and one platform.
That is actually easier that it sounds like. I've done
exactly the same thing for a (currently) closed part of the
appassembler, just with the java service wrapper [2] and the
dependency plugin. In my versjon I included a set of wrapper
binaries in the binary that matched the three versions of
platforms we have to support (linux x86, windows 32 and
solaris sparc 64), and used the assembly plugin to package it all up.
I've already created a rudimentary plugin for the product
were I work,
but wanted to take it to the next level. I was thinking
that if our
visions were in line, that maybe we could collaborate.
We would love to collaborate. Let us know what you had in mind and
we'll take it from there. In the future let's take the
discussion on
[email protected] as I know there are other people that's
interrested.
I need this stuff fairly quickly and I'm not sure I'm
willing to wait
for you good folks to have time, but maybe I could patch the
appassembler module (not sure I like the name btw).
That's toally fine, your ideas are also most useful as they
then have been used in the real world. The whole appassembler
plugin was originally driven out of real world requirements
that on other plugin could deliver.
We're still trying to figure out the scope and direction that
we want to take the appassembler plugin. Our idea is to
create a very easy way for developers to create complete,
platform independent binaries that can be used to deliver
projects super fast. We're most likely going to implement
"package" and "run" mojos to make it easier to use as you
won't need the assembly plugin at all as long as you use our defaults.
That’s exactly my thought as well, but I'm discovering that the plugin
configuration in the pom can get quite large and I'm not near finished;
however I think in early versions it would be fine to put it all in the pom
and we can refactor it later as the patterns evolve.
I started with windows because I thought it would be the hardest part.
So far what I've got for the new generation of my own installer (which I
started from scratch) is a plugin that uses 3rd party components e.g. to
generate an exe launcher I've started with Janel
(http://sourceforge.net/projects/janel/) it uses a self contained exe that
reads a properties file which is generated by the plugin config. For the
installer I had started on a system that would allow different types of
installers (starting with a simple zip archive) next was going to be a
config for generating an NSIS script and executing the nsis compiler on it.
The *nix platforms should be easier to work though as a lot of it can be
done with shell scripts etc. There is already an RPM plugin that we you call
or incorporate (not that I'm a fan of RPM).
It might be worth using something like IzPack
(http://www.izforge.com/izpack/) as a standard installer but you would have
to have a JRE to run it... I could even see writing custom install panels
for this, but that’s a discussion for later.
Ok, I see what you want now. I've specifically not added any installer
concepts into the appassembler as I see the appassembler as something
that would run before the assembly plugin and an installer plugin and
that the generated files are something that would be installed like any
other installable file along with the jar files.
As for the name it's not my favorite either, if you have any
suggestions please bring them forward!
I'm currently just using "installer" as the name, but it’s a bit confusing.
Maybe the best thing would be to come up with a distinct name the way the
test plugin is called "surefire". I'm in favour of that kind of naming
because it makes things clear when your talking about something.
All in all, I'm fairly easy, as long as it does what I need it to do :)
Good point. I would not mind changing the name to something like
surefire. We've also talked about move the appassembler out of mojo and
to a separate Codehaus if it keeps on growing.
I know the assembly plugin is being worked on and improved and this
stuff would really work best as part of it, but things would get
complex fast; I had the idea that what might work well is a
plugin-plugin for assembly...
Essentially specific components that assembly could call to do a
particular thing (such as create a launcher) although I
haven't looked
into the feasibility of that yet. The nice thing about that
model is
that assembly "assemblers" could be written without
impacting the core assembly code.
That is true, and while it might be a good idea to put more
of this into the assembly plugin the appassembler plugin has
a bigger goal which is helping developers with a way to
describe their applications. There are several bits of the
plugin's configuration I would like to move into Maven's POM.
Even if the assembly plugin gets plugin functionality the
appassembler will live besides the assembly plugin. The
assembly plugin plugin will just call out to the appassembler
code we already have.
Right, I'm with you on that one. Assembly will get even more complex than it
already is and having it do too much might muddy the goal.
Yah. Another case I've been wanting to support is to generate the same
scripts from Ant tasks.
Is there a wiki some place where we (people interested in features) can work
out the stories for this plugin? I can patch the current tree with my
additions, which can be refactored later but it might be good get this down
in an organized overview.
We have some notes here [1] that I guess are rather outdated now. Feel
free to (re)move content and/or add subpages as you see fit.
[1]: http://docs.codehaus.org/display/MOJO/Application+Assembler
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
