2017-10-11 14:26 GMT+03:00 Mark Thomas <ma...@apache.org>:
>
> Having looked at a couple of options I settled on that one too.
>
> I haven't yet found an IDE with a GA release that handles this. Support
> in the tools is fairly embryonic as well.
Several thoughts:
1. I think Eclipse does not support having different version of Java
for different subsets of files in a project.
(I am on 4.6 Neon now, haven't tried 4.7 Oxygen yet)
As such, we will have to use two separate projects,
similar to the two projects in Tomcat 7.0 ("tomcat-7.0.x" and
"tomcat-7.0.x-java7").
There are two separate goals in build.xml to generate the two
projects. Documented in
http://tomcat.apache.org/tomcat-7.0-doc/building.html#Building_with_Eclipse
It was easier for Tomcat 7 with clear separation of WebSocket APIs.
I wonder how it will go with Tomcat 9, and with further backport of
Java 9 support to Tomcat 8.5 and 7.0
2. I think of changing JDK configuration in build files to use
explicit paths to JDK versions.
In Tomcat 7 we have "java.7.home" property to specify location of JDK 7.
My idea is to have explicit
java.6.home=
java.7.home=
java.8.home=
If either of them is missing, ${env.JAVA_HOME} provides the value -
like it is done in Tomcat 7 build.xml.
The goal is to be able to run build.xml with a later version of Java.
Advantages of this approach:
1) It resolves problem with download of some of dependent libraries.
(Those libraries require https connection and cannot be downloaded
with an old version of Java (Java 6), but can be downloaded with Java
8).
2) It allows us to upgrade to a never version of Checkstyle.
As 1) and 2) are not much of a problem, I have not pursued this idea yet.
>>> - accordingly we would need e.g. a directory output/classes9 or similar.
>
> I went for classes/META-INF/versions/9 so it mirrored the JAR structure
> but that probably isn't essential. One advantage was that - with my
> other build.xml changes - supporting additional versions was minimal
> effort.
>
>>> - If we need Java 9 for compilation of the Java 9 classes, we would
>>> mimic the Java 7 lines from the TC 7 build.xml.
>
> For the JreCompat code, we would need this. This is where most of the
> complexity was added for this approach.
>
>>> - To add the Java 9 classes to one of our jars it would suffice in
>>> build.xml to do something like
>>>
>>> <jar jarfile="${somefile.jar}" update="true">
>>> <manifest>
>>> <attribute name="Multi-Release" value="true"/>
>>> </manifest>
>>> <zipfileset prefix="META-INF/versions/9/" dir="${tomcat.classes}9"/>
>>> </jar>
>
> I took a slightly different approach. I extended the existing jarIt
> macro and provided a default.mr.manifest. We'd also need to decide how
> to handle the source JARs in this case. I didn't implement it but my
> conclusion was we should mirror the structure of the binary JARs.
>
>>> - to reduce redundant maintenance it would be good to factor out JVM
>>> dependent code, so that the classes we have to maintain multiply
>>> mostly contain the code that's really version-dependent.
>
> Big +1. I looked at removing JreCompat entirely but that would have
> required a lot of duplication. We have some large classes that only need
> one or two lines of Java 9 code.
>
> [...]
>
> MR means release builds will required Java 8 and Java 9 (or just Java 9
> with a risk we add a hard Java 9 dependency without realising).
>
> MR is not handled well by IDEs requiring manual inclusion / exclusion of
> source files (or multiple projects) to switch between the different
> versions.
>
> I do like the reduction in code and the build script complexity doesn't
> concern me overly - it is mostly adding volume rather than an complex
> logic. The IDE issues are more annoying.
I agree with the above. And the IDE issues are annoying.
> Overall, I'm torn. I guess I'm +0 on switching at this point. What does
> everyone else think?
>
> Mark
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61597
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
