On 06/02/2015 6:32 AM, Curtis Rueden wrote:
Hi Ron,
Why not just mock the classes and have the mock classes take the
appropriate actions when they are called by mistake.
To clarify my earlier comments: I like your solution here, and agree that
it would work well in this circumstance. It gives
Hi Ron,
> Why not just mock the classes and have the mock classes take the
> appropriate actions when they are called by mistake.
To clarify my earlier comments: I like your solution here, and agree that
it would work well in this circumstance. It gives more control than my
suggestion to catch No
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
ni
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
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
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