About dependencies in the POM : servletapi has been relocated to javax.servlet : servlet-api This one should also be set as <scope>provided</scope>, as it is provided by the servlet engine.
Not sure if this is the same case for javax.mail:mail. In an application-server context this one is provided, but not in a standalone (batch) context. For the latter case, any batch project would have to declare dependencies on server-side java API it uses anyway. Is there a good reason to use commons-beanutils-core and not the (more popular) commons-beanutils ? For many projects, this will introduce duplicate commons-beanutils* jars as many other libraries declare dependency on commons-beanutils. Nico. 2007/11/4, Oliver Heger <[EMAIL PROTECTED]>: > > Hi Jörg, > > thanks for the comments. > > Jörg Schaible wrote: > > Hi Oliver, > > > <snip/> > > > > src package compiles and runs tests on my compiler zoo, fine! > > > > Dependencies: > > - pom uses commons-logging:commons-logging-api instead of > > commons-logging:commons-logging. The API version should only be used > when > > building a server like Tomcat (IIRC) > > - because of this we have both commons-logging-api-1.0.4 and > > commons-logging-1.1 (as transitive dep from digester) in the classpath. > > Maybe we should directly upgrade to 1.1.1 to drop the optional deps of > JCL > 1.1.1 is not available yet. Would it help to upgrade to 1.1 in the > meantime? > > > - commons-jxpath triggers old xerces-1.2.3, ant-optional and jdom. At > least > > the first two should be possibly excluded, especially since the > > dependencies page refers xerces-2.2.0 and the pom refers an optional > > ant-1.6.5 > How can this be achieved? The dependency to jxpath has already been > marked as optional. What further steps need to be performed? > > > > > > > Site glitches: > > - broken link in "Howtos (1.2 release)" exists a broken link to the > > current "User's Guide" > > - download page has no entry for version 1.5 (yet ?) > > - changes state version 1.5 to be in SVN ... don't forget entry in POM > This is a problem of our release process because I cannot anticipate the > real release date. So I intend to fill the date in before the final site > gets deployed. But of course I must not forget this. > > > - findbugs report ... open issues ?? > The majority of these issues refers to generated code in the plist > package. I will try to find a way how these classes can be excluded. > > Oliver > > > > > > > Cheers, > > Jörg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
