Hi Brett, Brett Porter wrote on Thursday, April 14, 2005 9:22 AM:
>> So how do I define these dependencies if I am myself the author of >> such an artifact, that has different dependencies dependent on the >> used functionality? > > At the first level, you can specify what is compile, runtime > and test. That'll help filter out. OK. I've already detected this. > There isn't any way to classify based on functionality. > That's very error prone... Consider you have XmlConfigurator > that requires stax in your list of dependencies. You add > another class that uses stax, but it is required for some > other piece of functionality. Your library still compiles, > because the stax dependency is there, and the tests succeed. > Meanwhile, another application just broke because a dependency is > missing. Introducing dependency groups ;-) ?? > If your library provides discreet pieces of functionality > that are completely isolated from the rest of the code, so > much so that it has its own dependencies, they should > probably be in a separate library. I doubt that we will ever see: commons-configuration-core.jar commons-configuration-jndi.jar commons-configuration-db.jar commons-configuration-ini.jar ... well, you know what I mean :) [snip] > I've filed a JIRA issue for what has been planned for later. Saw it. It is possibly the best way to handle such situations. - J�rg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
