On 20/10/2005 4:13 PM, David Jencks wrote:
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?
Yes. Also, if they could be used upon assembly that would be exactly
what I was describing.
Thanks,
Gianny
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/
