On Oct 19, 2005, at 11:03 PM, Gianny Damour wrote:
On 20/10/2005 2:58 PM, David Jencks wrote:
On Oct 19, 2005, at 9:57 PM, Gianny Damour wrote:
You may be right. Having said that, this XML parsing is done each
time that a dependency is declared by a configuration. I see this
approach as more self-contained than a solution based on the build
system. Indeed, this approach allows to declare the runtime
dependencies of a dependency, which is rather handy.
Could you explain what you mean by this?
I think that this is better explained with an example:
Based on the META-INF/geronimo-service.xml file of the geronimo-tomcat
dependency, I know that 4 runtime dependencies are required. As a
user, it is clear that I need these 4 dependencies in my repository to
be able to use geronimo-tomcat. Without this file, I do not know that.
Based on the geronimo-tomcat POM, a user is able to derive the compile
time dependencies; yet it is not clear that tomcat-coyote needs to be
there at runtime.
Ah, I see. thanks.
I think that this is more handy as it is then trivial to write a
tomcat plan: I add the tomcat-plan dependency; define my GBeans; and
add to my repo the geronimo-service.xml runtime dependencies. With the
current approach, I would need to add to my custom plan all the
dependencies defined by j2ee-tomcat-plan (do I need all of them?).
Now I'm confused again. Right now, the dependencies in
modules/tomcat/src/etc/META-INF/geronimo-service.xml become
dependencies of any configuration that uses
geronimo-tomcat-${geronimo_version}.jar as a dependency.
Unfortunately, they are a shortened version of the dependencies for
jetty and don't include the 1001 tomcat jars that are needed to run
tomcat :-) So, if we edited all the geronimo-service.xml files and
added them where missing would that do what you describe?
thanks
david jencks
Also, I think that it is also a pain to declare the transitive
dependencies in a configuration. I would prefer to simply define the
top level dependencies, e.g. the ones defining the declared GBeans,
and let them define the other dependencies.
That is certainly a goal I like :-).
I like the idea of constructing the geronimo-service.xml's from the
project.xml. That would eliminate one source of duplication. And,
we could open up the configurations and possibly jars included
explicitly in an assembly and extract the dependencies and install
them into the geronimo repo providing they are available. However,
unless maven is also keeping track of the transitive dependencies
somehow, such as through poms, I don't see how maven will be able to
guarantee that all the dependencies needed for an assembly are
actually present in the local maven repo, so we can copy them. Any
ideas?
I see the problem now: all the dependencies need to be in the local
maven repo and it seems that only Maven will be able to do that.
Thanks,
Gianny
thanks,
david jencks
Thanks,
Gianny
On 20/10/2005 2:40 PM, Bruce Snyder wrote:
On 10/19/05, Gianny Damour <[EMAIL PROTECTED]> wrote:
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.
I'm not shooting down anything, but that sounds like a lot of extra
XML parsing. I'm curious to hear Dain chime in here to describe
exactly what he's doing with the Maven repo management code.
Bruce
--
perl -e 'print
unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;
VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
