What geronimo does is to first "deploy" all applications into the
maven repo (packaging plugin for g 1.1 and earlier, car plugin for
trunk) and then assemble a server by copying the car files and then
pulling in all transitive dependencies (using geronimo's dependency
system) (assembly plugin for g 1.1 and earlier, I think car plugin
again for trunk, I'm not quite sure how it works in trunk). This
assures that you get exactly the artifacts you need in your server.
However if you are using g 1.1 it means you have to get your
artifacts into an m1 repo and trunk is not quite production ready at
this point.
IMO geronimo should not object to poms being in our repo. Can you
provide more details on how to reproduce this problem? The best would
be a jira entry with a sample and instructions.
thanks
david jencks
On Aug 22, 2006, at 8:40 AM, Desai, Brian wrote:
Hi,
My team is trying to get our hands around automating deployment of
common libraries from our build environment (maven 2.x) to a Geronimo
repository. Being that the G build environment is now also maven 2.x,
I'm hoping to see how others are tackling this problem.
It seems that the G repository is almost identical to a maven
repository
in structure and we were hoping for an easy way to bridge between the
two. Our first idea was to copy the directory structure from
.m2/repository to <GHOME>/repository. Geronimo, however, has issues
with the pom.xml files when resolving dependencies to the libraries at
runtime (it seems to confuse the pom for the library). Certainly, we
could write a script to filter out all the pom.xml files, but we'd
still
have the problem of filtering what does and does not get deployed
to G.
Since the easiest thing to do would be to copy top-level folders in
the
repository, we would probably be deploying way more libraries than
necessary.
It seems reasonable to simply create one big maven project that has
dependencies on all the projects that we would want to deploy. This
would take care of the "filtering" part of the problem. If we could
then deploy this project and all of its dependencies to a G repo
(removing pom.xml, etc), that would solve the rest. Perhaps a m2
geronimo plugin?
These were our ideas. Does anyone know of a better way we could
tackle
this problem? ... perhaps tools/tricks to help automate the deployment
from m2->G?
Thanks in advance for the help!
- Brian
