Maven Dependency Management using exclusion vs. provided

Posted on by admin
Reply

I’m currently working on a project and noticed that there are a lot of libraries marked with a scope of provided like so:

<dependency>
<groupId>somegroup</groupId>
<artifactId>someartifact</artifactId>
<version>0.1</version>
<scope>provided</scope>
</dependency>

But, when I look at the target container, I see no such library.

Upon further investigation, I realize that this scope was being used to exclude the library from the deployed artifact.  It might have been a loose dependency on another library.  Instead of using and exclusions list, to tell *me* that they just didn’t want it in the artifact, they used the provided scope to tell me that it’s already in the container.

Dear developers using maven, please choose to exclude unwanted dependencies rather than giving them a “provided” scope and sending those that follow you down this same rabbit hole.

I would prefer to see this:

<dependency>
<groupId>somegroup<groupId>
<artifactId>someartifact.thatdependson.someartifact</artifactId>
<exclusions>
<exclusion>
<groupId>somegroup</groupId>
<artifactId>someartifact</artifactId>
</exclusion>
</exclusions>
</dependency>

Thanks!

Posted in Uncategorized | Leave a reply

VirtualBox Scare – VERR_SUPLIB_WORLD_WRITABLE

Posted on by admin
2

I’ve been really enjoying VirtualBox for a few months now.  Today, when I tried to open my images, I got a really scary error.  I thought that all of my work was gone.  I tried to open the other images I had, all of them failed with the same error.

VERR_SUPLIB_WORLD_WRITABLE

I’m using OSX, I did a fair bit of googling, the solution that worked for me:

chmod o-w /Applications

Posted in Uncategorized | 2 Replies

Javamail on CentOS/Redhat NoSuchProviderException SMTP

Posted on by admin
Reply

I’ve ran into this so many times and it gets me every time. The mail package the gets installed with the tomcat version that I install from the system repository (using yum) includes a javamail library that causes problems.

Apparently, if there are multiple, different java mail versions, the system just falls down and throws the NoSuchProviderException.

My application usually includes the latest version of the javax.mail library. So I simply renamed the java-mail.jar to java-mail.jar.orig in the tomcat “common” library.  Then I restated the tomcat server.

Changing the extension makes it not get loaded automatically when the system restarts.  I like to use the .orig so I know what changes I made in case I want to revert them.

Posted in Uncategorized | Leave a reply