fixes #273 - remove hard dependency on lightblue-core-hystrix

[dcrissman]

No description provided.

[dcrissman]

This still fails, but actually builds further than it was before. So the fix work, but #267 needs to be resolved before the build will be totally stable again. Merge if you want or wait until everything is fixed.

[coveralls]

Coverage decreased (-0.01%) to 67.357% when pulling fd89f66 on dcrissman:remove-deps into 19e4922 on lightblue-platform:master.

[jewzaam]

jdk7 build fails. Can a profile be setup for jdk7 that doesn't include the integration tests?

[bserdar]

Can we split this into two projects, one for 1.7 and one for 1.8, similar
to the structure we have for lightblue-rest?

On Fri, Mar 18, 2016 at 9:58 AM, Naveen Malik [email protected]
wrote:

jdk7 build fails. Can a profile be setup for jdk7 that doesn't include the
integration tests?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#277 (comment)

[jewzaam]

How about a profile for jdk7 vs jdk8 where the difference is the modules built? Is there a reason to bother building integration tests with jdk7?

http://maven.apache.org/guides/introduction/introduction-to-profiles.html#Profiles_in_POMs

[dcrissman]

Perhaps not, but again this will lock a jdk7 application at a certain
version. Probably ok, but doesn't resolve bug fixes or other updates.

On Fri, Mar 18, 2016 at 12:04 PM, Naveen Malik [email protected]
wrote:

How about a profile for jdk7 vs jdk8 where the difference is the modules
built? Is there a reason to bother building integration tests with jdk7?

http://maven.apache.org/guides/introduction/introduction-to-profiles.html#Profiles_in_POMs

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
#277 (comment)

[jewzaam]

It only means integration tests would run with jdk8, not jdk7. If you want
to run them, even if your client needs jdk7, you build with jdk8. It isn't
something used at runtime, so wouldn't that be reasonable?

On Fri, Mar 18, 2016 at 1:05 PM, Dennis Crissman [email protected]
wrote:

Perhaps not, but again this will lock a jdk7 application at a certain
version. Probably ok, but doesn't resolve bug fixes or other updates.

On Fri, Mar 18, 2016 at 12:04 PM, Naveen Malik [email protected]
wrote:

How about a profile for jdk7 vs jdk8 where the difference is the modules
built? Is there a reason to bother building integration tests with jdk7?

http://maven.apache.org/guides/introduction/introduction-to-profiles.html#Profiles_in_POMs

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
<
#277 (comment)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#277 (comment)

[jewzaam]

And the client jar's published would be jdk7

On Fri, Mar 18, 2016 at 1:56 PM, Naveen Malik [email protected] wrote:

It only means integration tests would run with jdk8, not jdk7. If you
want to run them, even if your client needs jdk7, you build with jdk8. It
isn't something used at runtime, so wouldn't that be reasonable?

On Fri, Mar 18, 2016 at 1:05 PM, Dennis Crissman <[email protected]

wrote:

Perhaps not, but again this will lock a jdk7 application at a certain
version. Probably ok, but doesn't resolve bug fixes or other updates.

On Fri, Mar 18, 2016 at 12:04 PM, Naveen Malik [email protected]
wrote:

How about a profile for jdk7 vs jdk8 where the difference is the modules
built? Is there a reason to bother building integration tests with jdk7?

http://maven.apache.org/guides/introduction/introduction-to-profiles.html#Profiles_in_POMs

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
<
#277 (comment)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#277 (comment)

[dcrissman]

I don't believe this conversation is actually being recorded in github. We
should move to either mojo or github.

On Fri, Mar 18, 2016 at 1:56 PM, Naveen Malik [email protected]
wrote:

And the client jar's published would be jdk7

On Fri, Mar 18, 2016 at 1:56 PM, Naveen Malik [email protected] wrote:

It only means integration tests would run with jdk8, not jdk7. If you
want to run them, even if your client needs jdk7, you build with jdk8. It
isn't something used at runtime, so wouldn't that be reasonable?

On Fri, Mar 18, 2016 at 1:05 PM, Dennis Crissman <
[email protected]

wrote:

Perhaps not, but again this will lock a jdk7 application at a certain
version. Probably ok, but doesn't resolve bug fixes or other updates.

On Fri, Mar 18, 2016 at 12:04 PM, Naveen Malik <
[email protected]>
wrote:

How about a profile for jdk7 vs jdk8 where the difference is the
modules
built? Is there a reason to bother building integration tests with
jdk7?

http://maven.apache.org/guides/introduction/introduction-to-profiles.html#Profiles_in_POMs

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
<

#277 (comment)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
<
#277 (comment)

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
#277 (comment)

[dcrissman]

Discussion did get logged to github, but to wrong issue. Above conversation should be on #267

[coveralls]

Coverage decreased (-0.01%) to 67.357% when pulling d791fff on dcrissman:remove-deps into 19e4922 on lightblue-platform:master.