git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supporting multiple JDKs



> How would we be sure users will never encounter bugs unless we build
> against that JDK? 


Apache Cassandra does not distribute JDK1.7 built releases.

The only way a user could repeat such a bug is if they have built C* themselves.

I don't think the project should be responsible for every possible build combination tom, dick and harry can do.
That's my 2cents anyway. 

And I would suggest to go further and crash the build with JDK1.7 so we can take away the possibility for users to shoot their foot off this way.


> > The time it takes for tests to run is a headache, so to have to run
> dtests four times over makes me grimace.
> It takes only about 25min with default 4x parallelism to run unit tests in
> CircleCI.

I referred to dtests, how would you do this on CircleCI?
Today dtests take 5-9 hours on builds.apache.org, not including re-runs for offheap, large, novnode.


> We definitely can build against JDK 8 alone, however from the thread you
> linked and from 9608, we wanted to do a stable release that uses JDK8, and
> an experimental release, which uses JDK8 to build most files, and JDK11 to
> build the Java 11 specific AtomicBTreePartitionBase file.

Currently I'm unclear on how we would make a stable release using only JDK8, maybe their are plans on the table i don't know about?
 
The current build.xml requires both JDKs to run `ant artifacts`.
That is any release will have compiled in ant all but one class with `_build_multi_java` instead of `_build_java8_only`.


> My proposal is not to necessarily run UTs and DTests against JDK11 always
> with every commit but to have workflows in place that can be used whenever
> we deem necessary.


I'm not familiar with optional jobs or workflows in CircleCi, do you have an example of what you mean at hand?
I like the idea of having a collection of CircleCi workflows, even if I'd rather see less JDKs supported at compile-time.


> I think building the artefacts should be part of the CI build step because patches are not always about java code. 

Off-topic, but what are your thoughts on this? Can we add `ant artifacts`, and the building of the docs, as a separate jobs into the existing default CircleCI workflow? I think we should also be looking into getting https://cassandra.apache.org/doc/latest/ automatically updated after each successful trunk build, and have https://cassandra.apache.org/doc/X.Y versions on the docs in place (which are only updated after each patch release).

regards,
Mick

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx