So, what goes into a car file that is not provided by the original
plan.xml?
The more I work with car files the more I want to get rid of them. I
really don't like them at all.
I don't see why we need them... appears that the plan.xml (or some
other form of xml) is sufficient. Car files are adding much much
unneeded complexity to the build, to the bootstrap and to plugin and
user development.
Why are they needed? How do they make anything easier for anyone?
I really think that we need to give cars the boot (the brown leathery
type with some mud on the heels).
--jason
On Aug 12, 2006, at 6:56 AM, anita kulshreshtha wrote:
IMO there are 2 aspects of this plugin:
1. The features used by all users - These users will use the packaging
plugin to package a car to create geronimo plugins. We should make
their lives are as easy as possible by providing everything in the
dafault configuration. In other words they could say <geronimoPlugin>
(may be not even that) and put the files in src/conf dir
(geronimo-plugin.xml, notices.txt etc) and it should work. IMO, we
should not expect them to know maven well. If it makes the code a bit
messy for the people maintaining the plugin, it should be ok because
they are supposed to be maven experts. These users will use
application
configs similar to the *-examples configs. They would like to
specify a
server by name and not by using ordered deployers.
2. The features used to build the server cars - These features are
used
by very few: Dain, David Jencks, Aaron and may be few others. They are
the only ones who modify these configurations and the changes are very
rare. We should not care if these fearutes are clumsy at the moment
;-).
I hope you would take the above into consideration while changing
the plugin. The filtering should work. IIUC you are using the deployer
to generate an unpacked car (even for executable configurations),
copying the files from target/classes to the correct location in the
mojo and then archiving it using your favorite tool ;-). I would
prefer
that we use geronimo code to do this so that the all the cars are
consistent. I would like David Jencks' input on this. Maybe we should
modify the deployer to take a dir parameter for the stuff to be added
at META-INF in the car.
Since the m1 build will be dropped and you have changed the plans,
it should be possible to remove the velocity merge.
The daytrader generates 3 artifacts. They must (?) each get
notice.txt, etc and then get zipped. They are installed using the
attached artifacts.
I have not looked at the code, but it sounds right, and I will look
at the code on Monday.
Thanks
Anita
--- Jason Dillon <[EMAIL PROTECTED]> wrote:
I've just finished committing changes that should (I hope) bring back
the functionality needed to include geronimo-plugin.xml... someone
please validate that it works as desired.
Maven is now responsible for making the car archives now... the car
plugin will always spit out into a local repo and then the
PackageMojo will create an archive out of it using the m2 archiver
bits, which allows flexible manifest entries... blah blah.
geronimo-plugin.xml is still being filtered using the resources
plugin... and really anything you drop into src/main/resources will
be included into the car, and filtering is controlled by the default
m2 bits in your pom.
Plan files have been updated to use ${pom.version} instead of $
{pom.currentVersion}... ${pom} is actually the project reference,
which is closer to what it would be if filtered by resources (which
we will eventually get to, and drop velocity).
Car files now all have LICENSE.txt and NOTICE.txt included (side-
effect of using Maven's mech to pick up resources), blah blah
The addition of the startup-jar is no longer hidden... its just
another resources in src/main/resources.
I also updated the PackageBuilder to take a list of classpath
elements (that are artifacts, like the dependency plugin) which
allows for customization of the prefix added to the entry in the
manifest, which was needed to get lib/endorsed bits (the m2 archiver
only allows one prefix per set). Right now the list is non-
transitive... I could not figure how to get that working... need to
ping the peeps in #maven for help. I will be pruning the list of
properties we have in the root pom to manage versions, which are
mostly unused now.
There is still some more dependency clean up that needs to be done,
but the servers are starting fine.
Please take a moment and check for any strangeness and lemme know if
you find anything.
May still be a bit more work to get the multiple car muck working...
but until I have something that is actually using the plugin that I
can peek at I can't really fix it.
I left the Deployer code asis... though my hunch is that some of this
is not needed (the jar and manifest bits primarily)... and if someone
knows if we use those bits anywhere else please speak up, else we
should drop the unused bits.
--jason
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
