+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 <pascalschumac...@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 >
