On Oct 19, 2005, at 11:20 PM, Gianny Damour wrote:
On 20/10/2005 3:08 PM, David Blevins wrote:
On Oct 19, 2005, at 9:23 PM, Gianny Damour wrote:
On 20/10/2005 1:56 PM, David Jencks wrote:
I've been working on building geronimo using the packaging and
assembly plugins. This works fine except for the unmanageable
dependencies. The project for the assemby plugin to work on
currently needs to include in the project.xml every jar to go into
the assembly's repository. Tracking these is impossible.
We need some way for a configuration or even a plain dependency to
instruct the assembly plugin to copy the artifacts dependencies
into the repository.
One possibility is to use maven poms. IIUC Dain is working on
integrating or imitating the latest maven repository management
code. Will this give us transitive dependencies? Will the maven
model work for us? How close is this? If we had it, it would be
pretty easy to construct separate jetty and tomcat assemblies, a
both assembly, an assembly w/o ejbs, etc etc. Without transitive
dependencies, it will be a nightmare to try to keep the repository
contents adequate and restricted to what is actually needed to run
the server.
Another approach would be: for each plain dependency, we could
generate a META-INF/geronimo-service.xml file based on the POM
dependencies as part of a standard build. Transitive dependencies
would be achieved by walking down the dependencies defined by the
geronimo-service.xml file.
That really wouldn't solve the transitive side of the problem. I
mean it would work as we maintain our poms to include our
dependency's dependencies (and dependencies of those dependencies
(and ...(N))), but expecting a completely flattened list of
dependencies in a single file per configuration isn't really the
definition of transitive.
LOL. Hopefully, this is not the approach that I was trying to
explained. Our POMs stay "as is" (w/o the dependencies of dependencies
and this transitively). Upon build, we generate a geronimo-service
plan defining all the "direct" runtime dependencies identified by the
POM.
Based on the resulting geronimo-service file, there would be two
approaches:
1. upon car packaging, runtime dependencies defined by the POM
dependencies are copied from the local maven repo to the car. Upon
assembly, the runtime dependencies defined by the car module are
copied to the repository; or
That's what "include" does, except the dependencies stay in the car. I
don't think this is a good idea generally, it sort of defeats the
purpose of the maven repo.
2. upon assembly, the runtime dependencies are read from the car and
copied from the local maven repo to the repository.
This is what I would like.
Thanks,
Gianny
Just being a stickler :)
We already generate part of the geronimo-service.xml files at build-
time, we might as well go all the way.
??? where is a geronimo-service.xml file generated today? do you mean
the version substitution?
thanks
david jencks
-David
