Formally this is 'covered' by Gradshteyn & Ryzhik (2005), 6.512.1 (page 653).

Checking also the errata it is siad, that one has to correct the conditions for the scaling parameters at the integration variables by 'flipping'. However that still does not resolve the problem of mu+-nu +1 = 0 (in the sense of the formula given in G&R).

I looked in the reference given = Erdelyi, Integral Transforms. But refuse to work through that, since he gives it in a modified presentation (which G&R translate, I think).

But I think one can give a formal solution.

It is by change of variables, may be it is zero for 0 < r < 1 (but as alraedy said: MMA may have an error as well)

Your zip:

Int(BesselJ(2,r*x)*BesselJ(1,x), x=0 .. infinity)

value(%) gives 0, value(expand(%)) gives 1/(r^2)-1 which is -15/16 for r=4 (and the integral does not evaluate if feeding r=4 first). Wolfram Alpha gives 1/16 and numerical I got essentially that using a quite different routine.

Your 'r' is close to 0 (and not above 1), but that shows one can not trust Maple here (I never do for Bessel fct)

Link to MMA result

Though I think there are bugs in MMA in that field as well

The zip file does not download, a bug in Mapleprimes

I agree that Maple does not have a recipe for those kinds of integrals

However I do not trust that symbolically it is zero:

Int(BesselJ(2, r*k)*BesselJ(1, 1500*k), k = 0 .. infinity);
value(%); # as it was said

                                  0

Int(BesselJ(2, r*k)*BesselJ(1, 1500*k), k = 0 .. infinity); expand(%);
value(%): collect(%, r);

                          1500/r^2-1/1500

which looks like the other plot


And I do not quite believe what MMA shows: should be zero or
some like factor * piecwise r resp 1/r for r <1 resp 1 < r ?

@Kitonum 

You are right. Same for me in M 17

Using your sheet I get the same problem.

Pasting your code in a new sheet it works.

Please find it appended.

MP_procproblem.mws

I can not see your pictures. It is better to post the (ASCII) code of your input as well. Or upload a file (if that accidentially works)

That is what Markiyan essentially says (and he shows it for your example by using 'convert/rational').

Do not mix (without good reason) exact values and floats. Then it works.

That exercise (?) is asking to code something you have been told in lectures.

Try it. You only can fail at worst. That does not matter: just dare & re-try again.

Changing x = -t+Pi and renaming gives Int( sin(x)^(-cos(x)) , x = 0 .. Pi)
and the same problem, now in x=0 which saves typing and displays nicer.

Change again by x = exp(-w) and MultiSeries:-asympt gives 1 + O(w)/exp(w)^2
for the new integrand, to be integrated up to +infinity, showing divergence.
And avoids the branch point in x=0, at least formally. 

May be that Maple internally does it differently, but if needed one can try
asymptotic integrals to make it sound. I suppose.

my objection would be that there is no 'series', I think there is a branch point in x=Pi

my stomach says: it will diverge looking at sin(x)^cos(x) * (x-Pi) via a plot (and evaluating that integral), despite the log parts in the series: that looks like regular/pole * pole

PS: is there a way in that board to merge it with Carl's answers?

why does it converge?

Nice example - have not checked why Maple has problems.

I prefer to write it as follows and the answer is immediate:

Int(sqrt(1+(diff(hypergeom([3, 4], [2, 1, 6], x), x))^2), x = 1 .. 17, 
   epsilon = 10^(-3), # not needed for this integrand 
   method=_d01akc);   # uses NAG routines
evalf(%);
                           453.137567466324

Edited:

Using UpperCase Diff works without problems

Int(sqrt(1+(Diff(hypergeom([3, 4], [2, 1, 6], x), x))^2), x = 1 .. 17);
evalf(%);

                           453.137567466326

and after that (and befor feeing values) one can 'see' the periodic entering something like

asympt(f(-p), p, 1): convert(%, polynom): simplify(%): simplify(%, size): collect(%, [sin, cos]);

So Maple already should do for p < 0, if you provide help feeding sin and cos, I hope.