There's a difference between build-time dependencies and run-time dependencies.
To build the SOAP connector, it requires Axis to build remoting. However, during execution, if you don't have Axis on your classpath, it won't be available, and won't cause a run-time dependencies. The intent is to only have a minimal amount of support that is part of the core JDK - such as Sockets, RMI, IIOP for Connectors and multicast, JNDI for Detectors. If different protocols are desired beyond that and we support them, you can just add the dependent JARs and they become available. I think this is what you want ... However, with the build, it is sometimes harder (at least for the non-expert buildmagic humans) to figure out how to link in other modules (for build only) such as the naming stuff, just for compiling the code. If there is a better way, can someone help us out here? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Sunday, March 09, 2003 11:16 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Naming a core module? The only protocols that can be included in the core are those natively supported by the VM. I certainly do not want to force these all of these extra protocol dependencies down into the core just because they might be used to access JMX. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Tom Elrod" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 08, 2003 11:02 PM Subject: RE: [JBoss-dev] Naming a core module? > I agree that it doesn't make sense to have naming in core. Actually > noted this in the e-mail I sent out when I made the commit. > > However, don't have a solution off-hand for how we can include modules > and jars in remoting (and yet exclude the from core, without removing > remoting, which jmx now depends on). This will probably become more > of problem as the list of these such things continues to grow, since > more and more protocols (JMS, IIOP, etc.) and detectors (JINI, SLP, > etc.) will be added over time. Already includes SOAP and JNDI, which > really don't belong in core. > > Best suggestion I can give is to remove remoting from core, create yet > another sub module for jmx remoting which will depend on remoting and > jmx (thus leaving jmx in core without needing remoting). As you can > see, this makes things much more complex in regards to development, > building, and deploying (which is pretty complex to begin with). Just > have to weigh the trade-offs. > > Whatever the preference, I will be on vacation next week so won't be > able to do anything with it till I get back. > > -Tom ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
