Java versions we wish to support

[Zoran Regvart <zo...@regvart.com>]

Hello,
while doing the exploration of running tests on Java 11 I found out
that from that version onward Java EE APIs are no longer distributed
with Java[1].

I think this makes a difference in how we declare the dependencies. So
for instance JAXB API is no longer available, we need to add it and we
have two options:

 1. declare in the <dependencies> directly

If we declare it in the <dependencies> directly, then some clients
might need to exclude that dependency: for instance application
servers might bundle a version of JAXB API and having another version
might lead to issues.

 2. declare in the <dependencies> of the Java 11+ <profile>

In this case Camel is OK when build/tested on Java 11+, but client
might get a ClassNotFoundException on Java 11+. This is based on my
understanding that Maven profiles in dependencies are considered only
at build time of the dependency, not when that dependency is used.

Am I wrong about this? What can we do? Declare that from some version
of Camel (say 3.0.0) we only support Java 11?

zoran

[1] http://openjdk.java.net/jeps/320
-- 
Zoran Regvart

Re: Java versions we wish to support

[Willem Jiang <wi...@gmail.com>]

+1 for declaring the dependencies directly.

User can always override the version by introducing the dependencies
management or just exclude them. and adding the dependencies supports most
of cases.


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Jul 20, 2018 at 3:16 AM, Pascal Schumacher <pascalschumacher@gmx.net
> wrote:

> Am 19.07.2018 um 16:42 schrieb Zoran Regvart:
>
>> Hello,
>> while doing the exploration of running tests on Java 11 I found out
>> that from that version onward Java EE APIs are no longer distributed
>> with Java[1].
>>
>> I think this makes a difference in how we declare the dependencies. So
>> for instance JAXB API is no longer available, we need to add it and we
>> have two options:
>>
>>   1. declare in the <dependencies> directly
>>
>> If we declare it in the <dependencies> directly, then some clients
>> might need to exclude that dependency: for instance application
>> servers might bundle a version of JAXB API and having another version
>> might lead to issues.
>>
>>   2. declare in the <dependencies> of the Java 11+ <profile>
>>
>> In this case Camel is OK when build/tested on Java 11+, but client
>> might get a ClassNotFoundException on Java 11+. This is based on my
>> understanding that Maven profiles in dependencies are considered only
>> at build time of the dependency, not when that dependency is used.
>>
>> Am I wrong about this?
>>
>
> You are right.
>
> I'm for declaring the dependencies directly. (This also means that Java 9
> / 10 users won't have to add the modules.)
>
> As you said in case of a conflict users can exclude the dependencies.
>
> Imho Camel should still support Java 8.
>
> Regards,
> Pascal
>

Re: Java versions we wish to support

[Pascal Schumacher <pa...@gmx.net>]

Am 19.07.2018 um 16:42 schrieb Zoran Regvart:
> Hello,
> while doing the exploration of running tests on Java 11 I found out
> that from that version onward Java EE APIs are no longer distributed
> with Java[1].
>
> I think this makes a difference in how we declare the dependencies. So
> for instance JAXB API is no longer available, we need to add it and we
> have two options:
>
>   1. declare in the <dependencies> directly
>
> If we declare it in the <dependencies> directly, then some clients
> might need to exclude that dependency: for instance application
> servers might bundle a version of JAXB API and having another version
> might lead to issues.
>
>   2. declare in the <dependencies> of the Java 11+ <profile>
>
> In this case Camel is OK when build/tested on Java 11+, but client
> might get a ClassNotFoundException on Java 11+. This is based on my
> understanding that Maven profiles in dependencies are considered only
> at build time of the dependency, not when that dependency is used.
>
> Am I wrong about this?

You are right.

I'm for declaring the dependencies directly. (This also means that Java 
9 / 10 users won't have to add the modules.)

As you said in case of a conflict users can exclude the dependencies.

Imho Camel should still support Java 8.

Regards,
Pascal