[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-user
Subject:    Re: Best practice for "optional" dependencies?
From:       Ron Wheeler <rwheeler () artifact-software ! com>
Date:       2015-01-22 22:01:16
Message-ID: 54C1732C.90803 () artifact-software ! com
[Download RAW message or body]

If it is declared as "provided", you can substitute a jar that does what 
you want if the "optional" dependency gets called by mistake.

I gather that it is some sort of error at a higher level that would get 
these methods called when it is not supposed to be used.

Your replacement can flag an error or do anything that you think would 
be more helpful than "NoClassDefFoundError"

You need to know the signature of the methods that you want to replace 
and return something that the calling program can eat without getting 
indigestion.

If you never use the real decryption method, you can change the 
dependency scope of your replacement to "compile" on your replacement 
and none of your programmers will have to read the pom or notes.

If you want to flag something in the POM, you could put an "exclude" of 
B in the dependency on A to show that you are not using the original B.

Ron

On 22/01/2015 11:48 AM, Mark H. Wood wrote:
> I'm working on a project which has an "optional" transitive
> dependency.  That is: we depend on someone else's artifact (let's call
> it A), which itself depends *in some circumstances* on a third
> artifact (from a third source) which I'll call "B".  That is:  if you
> never trigger a certain feature of A then it doesn't really need B.  A
> expresses this by making B a dependency with <scope>provided</scope>.
>
> I feel that this is an abuse of the dependency mechanism, and that
> optional dependencies should not be declared to Maven as dependencies
> at all.  I think that A should use Class.forName to probe for B and
> (if not found) gracefully explain why it cannot perform the requested
> function.  What do you think?
>
> The feature in question is decryption of a file, which is triggered
> when A recognizes an encrypted file, and that is out of our control.
> Decryption requires key material, and in our application there is no
> reasonable opportunity to provide it, so we can't actually make use of
> the decryption function.  We are thus faced with a choice: declare a
> transitive dependency as if it were a direct dependency, to support an
> unusable feature, and leave notes all over our POMs to explain why
> dependency:analyze is wrong and you should not remove this dependency;
> or keep explaining to people why they get NoClassDefFoundError when
> processing some of their files.
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]