Why not just mock the classes and have the mock classes take the
appropriate actions when they are called by mistake.
Seems easier to manage and you just provide the right jar at run-time as
part of the install or deploy.
The developers don't have to worry about dependencies and maven works
nicely.
You could have a testing mock version that jumps up and down when it is
called by mistake so that the programmers know that they missed the test
for the option.
Ron
On 04/02/2015 5:32 PM, Curtis Rueden wrote:
Hi Mark,
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>.
Wouldn't it make more sense for A to declare the dependency on B as
"<optional>true</optional>" rather than abusing the provided scope?
http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
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.
I have historically had a lot of trouble with things done that way. The
problem is that Class.forName is very easy to mess up when custom
ClassLoaders are in use. Personally I think it is better to use a
compile-time dependency, and write the actual direct Java code, catching
ClassNotFoundException in the appropriate places to handle the situation
where the dependency is not present at runtime. Then you lean on the
compiler, and avoid subtle reflection-related bugs and problems. Since the
dependency is declared as <optional>true</optional>, you do not infect
downstream code with the dependency in every case -- instead, people can
choose for themselves whether to use it.
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.
Could you work around their design issue by catching NoClassDefFoundError,
and handle the error in a more appropriate way for your users?
Regards,
Curtis
On Thu, Jan 22, 2015 at 10:48 AM, Mark H. Wood <[email protected]> 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.
--
Mark H. Wood
Lead Technology Analyst
University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
