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
