Sounds good.
Alex
Ole Ersoy wrote:
I would think the Roadmap for our plugin should be a
reflection of the design of the JPackage plugin.
Although we'd have to see whether the other installers
benefit from the same type of flexibility incorporated
into the JPackage plugin.
I think the Mac and Solaris ones will, but windows...
So the JPackage plugin is a subset of our plugin.
We just add more mojos and JET templates for other to
generate other installers.
I'm updating the design document for the JPackage
plugin right now.
I'll post it on the wiki asap.
Then I'll be ready to start coding.
Then we can work together to see whether how we want
the roadmap to look for the other installers.
Sounds ok?
Cheers,
- Ole
--- Alex Karasulu <[EMAIL PROTECTED]> wrote:
This is all good but what happens to our plugin? Or
that is to be
determined?
Alex
Ole Ersoy wrote:
Aye that makes sense. So you want to stuff things
into the
src/main/resources area so they are bundled in
jars
and can be extracted
from them once those jars are pulled down from
ibiblio or elsewhere?
Yap,
So when the documentation for including the RPM
Plugin
in a build is created, in there it will say that
the
plugin fetches all the install files from the
repository, so everything has to be in Maven
standard
directories.
That motivates projects to use the conventions
provided by Maven.
So Maven just stuffs everything in the Jar.
The Plugin writes the Spec file per the
configuration
instructions provided in a install.xml file and
puts
it in the $rpmbuildenvironment/SPECS directory.
Then it invokes
rpm -ba somedaemon.spec
The commands for extracting
and building the install layout are in the spec
file.
So really maven is done, and RPM takes care of the
rest.
- Ole
--- Alex Karasulu <[EMAIL PROTECTED]> wrote:
Ole Ersoy wrote:
Yes I think what I'm saying is getting diluted
because
you are used to thinking about how the current
installer plugin works.
OK - Pretend for a minute that there are no
installer
plugins. We are just getting started.
Okie.
All we have are maven java projects.
Now we want to create a maven plugin that
that we can use to create the RPM installer.
However other projects have to be able to use it
to,
and we want everyone using it the same way to
make
cross project collaboration easier, etc.
So we first make a generic decision with respect
to
where the stuff the installer installs comes
from.
OK
We think that it's smart to pull all the
resources
that the installer plugin needs from the maven
repository, because that's where Maven puts
everything
after various quality assurance tests pass.
Hmmm even non-java artifacts like shared libs and
stuff? Meaning things
where the extension is not .jar or .pom? Cuz
maven
has serious issues
with doing that I think. Don't know fully though
but I'd give it a try.
So as as a rule we state that the Maven plugin
we
are
creating pulls resources and artifacts from the
Repository only. We're going with the Maven
Convention over configuration motto.
Coolio but you have to really experiment with
maven
to see if it can
manage other artifact types besides jars and
poms.
So the plugin does not care about stuff that
exists in
maven projects sitting in a workspace or in a
version
control system.
It only cares about stuff that maven has
installed
in
a local maven repository.
Does that make more sense?
Aye that makes sense. So you want to stuff
things
into the
src/main/resources area so they are bundled in
jars
and can be extracted
from them once those jars are pulled down from
ibiblio or elsewhere?
Alex
____________________________________________________________________________________
Want to start your own business? Learn how on
Yahoo! Small Business
(http://smallbusiness.yahoo.com)
____________________________________________________________________________________
Want to start your own business? Learn how on Yahoo! Small Business
(http://smallbusiness.yahoo.com)
