We Keep Coding

How to disable inherited logback?

in my Maven project I am using an external library (namely parallec.io) which uses LogBack as their logging framework and has logback.xml file packed into the JAR. I know it is considered a bad practice to pack logback.xml, but the developer somehow did it.
In fact, I need nothing of that wordy output (e.g. how it inicializes etc) so would be happy to disable logback at all. I am not very much into the logging thing, but I realized I need to create logback.xml and configure logging using it, but the problem is the conflicting file from the library. I tried this solution
http://www.mkyong.com/maven/maven-exclude-logback-xml-in-jar-file/
but it did change nothing as far as I can see.
So if some one could suggest me a quick way to just get read of logging (or at list exclude that default logback.xml) I'd really appreciate it.

Okay here's what I did, so thanks to px5x2 for the trick.
<dependency>
<groupId>io.parallec</groupId>
<artifactId>parallec-core</artifactId>
<version>0.9.1</version>
<exclusions>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
</exclusion>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</exclusion>
</exclusions>
</dependency>

Using Saxon to process XPath in a JIRA module

I want to use saxon to process xpath in a jira module.
Unit tests covering the problematic code were running fine in eclipse, so I have deployed the module, and ...
I have encountered the dreaded
java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory (see Dealing with "Xerces hell" in Java/Maven?)
I tried to exclude xml-apis from saxon dependencies, as it is suggested in https://answers.atlassian.com/questions/104121/i-m-blocked-help-cannot-be-cast-to-javax-xml-parsers-saxparserfactory
Now I got w3c.dom missing, which is strange, because I would bet my hat that it is existing somewhere in jira.
I added dom4j to pom dependencies nevertheless, and got
java.lang.NoClassDefFoundError: Could not initialize class net.sf.saxon.Configuration
With no indication of which class is missing.
Here is the code with the initial problem:
https://github.com/magwas/andreymarkelov-atlas-plugins-requestedfields/tree/feature/xsltfixes
the patch leading to current state is at http://pastebin.com/vwR43hHt
What would be the solution?

Okay, figured it out. I am not sure why, so an analysis would be welcome.
<dependency>
<groupId>net.sf.saxon</groupId>
<artifactId>Saxon-HE</artifactId>
<version>9.4</version>
<exclusions>
<exclusion>
<artifactId>xom</artifactId>
<groupId>xom</groupId>
</exclusion>
<exclusion>
<artifactId>dom4j</artifactId>
<groupId>dom4j</groupId>
</exclusion>
</exclusions>
</dependency>

Maven ejb-client generation dependency exclusion

We have a solution where our UI projects are including quite a bunch of business services by using the EJB client dependencies. The problem with this on Maven is that even though the client .jar usually contains about 1-2 classes, they bring with them the full dependency stack of the entire service application. This can get a bit ugly, when the .ear files start growing up to 50-100Mb a pop and there are from time to time pesky errors thanks to irrelevant dependencies sneaking their way into the UI application.
Of course, we can always exclude the dependencies on the client end, but then we have to write the same bunch of lines to each client project using those services and that's a lot of needless repetition. Plus, people come up with the weirdest error messages and use a lot of time tracking them down before remembering to mention that they included some client jar and didn't check what additional dependencies it brought into the equation.
Example:
<dependency>
<groupId>fi.path.to.service</groupId>
<artifactId>customermanagement-common</artifactId>
<version>2.6</version>
</dependency>
<dependency>
<groupId>fi.path.to.service</groupId>
<artifactId>customermanagement-service</artifactId>
<classifier>client</classifier>
<exclusions>
<exclusion>
<groupId>fi.path.to.dependency</groupId>
<artifactId>internal-dependency-#1</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.castor</groupId>
<artifactId>castor</artifactId>
</exclusion>
<exclusion>
<groupId>fi.path.to.dependency</groupId>
<artifactId>internal-dependency-#2</artifactId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#3</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#4</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#5</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
<exclusion>
<artifactId>castor-xml</artifactId>
<groupId>org.codehaus.castor</groupId>
</exclusion>
<exclusion>
<artifactId>castor-codegen</artifactId>
<groupId>org.codehaus.castor</groupId>
</exclusion>
<exclusion>
<artifactId>castor-xml-schema</artifactId>
<groupId>org.codehaus.castor</groupId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#6</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
</exclusions>
<version>2.6</version>
</dependency>
That is just one service client being included, imagine having several of these in several different applications and you get the picture, writing up all the excludes each time is quite annoying and the project POMs start getting fairly longwinded.
I would mark the dependency as provided, but there are a couple dependencies that do crash on runtime, if they don't exist. Say ones that include another service call to yet another app with an external Exception class, which isn't for one reason or another wrapped inside the service project and will cause a ClassNotFoundException on runtime, if not present.
Therefore, I know it's possible to exclude/include classes from an ejb client during its generation through the usage of pom.xml specs on the maven-ejb-plugin, but is there any way to exclude dependencies as well?

Seems that Maven just doesn't support building multiple jars out of one module very well.
Thus the only reasonable way around this that we've found is to create another module (break xxx-service into xxx-service and xxx-service-client) and configure the xxx-service-client module to have only the EJB client/delegate class & minimal dependencies. That way the project can be built with a single execution.

I have the same problem here. I think one solution could be using profiles, since in each profile you could specify the dependencies (see http://blog.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/)
In my case, this doesn't work, because I need to generate both JARs (ejb and ejb-client) in a single execution of Maven. :)

Maven error on dependency: missing artifact

I asked this question yesterday and it turned out to be a Maven issue. Although I was able to find a workaround (going with Geronimo instead of Java JMS) I was unable to figure out why the Java JMS solution isn't working.
I don't like to duplicate questions, but I don't believe this is a dupe because it is an entirely different original question.
So, I am trying to get JMS working with my application so I can push messages to a local queue. In my Maven pom.xml I add the following dependency declaration:
<dependencies>
<dependency>
<groupId>javax.jms</groupId>
<artifactId>jms</artifactId>
<version>1.1</version>
<scope>provided</scope>
</dependency>
</dependencies>
And right off the bat get a (red) highlighted error (using Eclipse) stating:
Missing artifact javax.jms:jms:jar:1.1
When I replace this with another JMS API, such as Geronimo, the error goes away. Is this a problem with the reference (Java) JMS dependency? Or is something configured wrong in my sandbox?

You can see in maven repo browser here http://mvnrepository.com/artifact/javax.jms/jms that size of artifact is 0 bytes. Seems some problems or special policy for that artifact.

The jms 1.1 jar is not available in the default maven repository - you need to add a reference to one of other public repositories (jboss one for eg)
This answer has details
https://stackoverflow.com/a/5272660/672586

The error might come because of the log4j transitive dependencies. You can exclude such dependencies as given below.
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
<exclusions>
<exclusion>
<artifactId>jms</artifactId>
<groupId>javax.jms</groupId>
</exclusion>
<exclusion>
<artifactId>jmxri</artifactId>
<groupId>com.sun.jmx</groupId>
</exclusion>
<exclusion>
<artifactId>jmxtools</artifactId>
<groupId>com.sun.jdmk</groupId>
</exclusion>
</exclusions>
</dependency>

ClassCastException while parsing XML with WebLogic

I'm getting the following error message:
java.lang.ClassCastException: weblogic.xml.jaxp.RegistryDocumentBuilderFactory cannot be cast to javax.xml.parsers.DocumentBuilderFactory
I've gone through some forums researching this. They said to remove xml-apis.jar or that JAR files were conflicting. But even though I did all the suggested steps, I'm getting the same error.

It's always the xml-apis.jar. Remove them from your classpath (e.g. remove them from WEB-INF/lib of your webapp).

Remove xml-beans-1.xb2 to the lib directory. Modified the POM so it does not include that jar file with the following:
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.0.b2</version>
<scope>provided</scope>
</dependency>

I think Banang is right. Forum http://forum.springsource.org/showthread.php?t=22597 describes solution for similar problem.
Typically such problems happen when there are several versions of the same class in class path while those versions are loaded by different class loaders. One version of DocumentBuilderFactory was loaded by system class loader, other by class loader of your enterprise application. When you are calling the XML parser the parent's version of the class is used. When you are casting yours private version is utilized. These versions are incompatible that causes ClassCastException.

The reason for this issue is you are having multiple jars with same class name in library.
Go to WEB-INF/lib and remove xml-apis-1.0.b2.jar and stax-api-1.0.1.jar or remove them from you pom.xml itself and you would be good to go.

I wanted make a slight addition to the previous answers to this question, in the event that anyone else is in the same situation I was. I had the same problem on our WebLogic 9.2 server due to my use of CXF 2.2.3. In addition to the removal of the xml-apis.jar mentioned previously, I also had to remove a xmlParserAPIs library.
As I am using Maven2 it was just a simple matter of adding another inclusion.
<!-- CXF -->
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle</artifactId>
<version>${dependency.version.cxf}</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<artifactId>xml-apis</artifactId>
<groupId>xml-apis</groupId>
</exclusion>
<exclusion>
<artifactId>xercesImpl</artifactId>
<groupId>xerces</groupId>
</exclusion>
<exclusion>
<artifactId>xmlbeans</artifactId>
<groupId>org.apache.xmlbeans</groupId>
</exclusion>
<exclusion>
<artifactId>xmlParserAPIs</artifactId>
<groupId>xerces</groupId>
</exclusion>
</exclusions>
</dependency>
Hope this helps someone!

We also has such trouble. The reason of error was in gwt library. Receipe: exlude all gwt client libraries from distr.

As for my case, I managed to solve this issue by removing xml-apis library and also upgrading an XML processing library:
From
org.apache.xmlbeans/xmlbeans/2.4.0
Into
org.apache.xmlbeans/xmlbeans/2.6.0
FYI, I'm using Weblogic 10.3.6.0.