Some of them should be test dependencies. The rest, which are "optional", become tricky to declare. If we leave them out of the dom4j pom, then if you touch that code and don't use the dep, you get a runtime error. We instead chose the current approach of passing along all the deps, and having to exclude them in your build. By making the problem be a compile time problem, you get a lot more assistance rather than a sneaky error at runtime, and often the extra dependencies are harmless.
- Brett On 8/5/05, Ken Weiner <[EMAIL PROTECTED]> wrote: > Thanks for the reply, Brett. I suspected that the issue was within > dom4j's POM, and I'd like to help clean it up by submitting issues to > MEV in JIRA. However, I am not sure what the appropriate corrections > would be. Should the jars inside the dom4j POM be declared with a > particular scope that would prevent them from being fetched when > another POM depends on dom4j? If so, which scope would this be? > > -Ken > > On 8/3/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > There isn't actually a way to turn it off wholesale, but you can > > exclude specific ones using <exclusions />: > > > > <dependency> > > <groupId>dom4j</groupId> > > ... > > <exclusions> > > <exclusion> > > <groupId>jdbc</groupId> > > <artifactId>jdbc</artifactId> > > </exclusion> > > ... > > </exclusions> > > > > This should be considered a last resort - what really needs to happen > > is for the dom4j metadata to be corrected. It in particular is well > > known to be problematic. > > > > You can file issues for other metadata at > > http://jira.codehaus.org/browse/MEV > > > > We will be spending more time after the beta-1 release on cleaning up > > the existing metadata. > > > > - Brett > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
