> I think that will not happen until we are out of Ant as doing this multi jar > / subproject mumbo jumbo is not too much appealing to ... anybody?
I find it more or less equally painful to make a change in a large Gradle, Maven, or Ant project. I consider myself a pretty active contributor, but I still find myself very rarely interacting with ant, and when I did, it never caused any trouble. That said, there are many other important things that we can improve, so I'd focus on them. Same goes for submodules. On Thu, Dec 12, 2024, at 5:53 PM, Paulo Motta wrote: > > I think that will not happen until we are out of Ant as doing this multi > > jar / subproject mumbo jumbo is not too much appealing to ... anybody? > > This is a contentious/controversial topic, but the more I work with gradle > the more I lean towards ant's simplicity. That said, I'd support moving away > if it becomes a technical blocker to break up cassandra-all - and if this > happen I would vote for maven as replacement. :-D > > On Thu, Dec 12, 2024 at 11:42 AM Miklosovic, Stefan via dev > <dev@cassandra.apache.org> wrote: >> These are all good ideas but in practical terms I think that will not happen >> until we are out of Ant as doing this multi jar / subproject mumbo jumbo is >> not too much appealing to ... anybody? >> >> ________________________________________ >> From: Paulo Motta <pa...@apache.org> >> Sent: Thursday, December 12, 2024 17:35 >> To: dev@cassandra.apache.org >> Subject: Re: Supporting 2.2 -> 5.0 upgrades >> >> EXTERNAL EMAIL - USE CAUTION when clicking links or attachments >> >> >> >> > +1 on moving the read/write logic into its own jar. >> >> +1, not only read-write logic but anything used by both the server and >> subprojects (ie. cassandra-sidecar), for example JMX Mbeans and other >> interfaces. >> >> I think one way to do that would be to split cassandra-all into >> cassandra-server and cassandra-common (anything used by both subprojects and >> server), but not sure if this would be feasible or what it would take. >> >> If there's loose agreement this would be a feasible path I'd be happy to >> create a JIRA to investigate what this would take. >> >> On Thu, Dec 12, 2024 at 11:26 AM Doug Rohrer >> <droh...@apple.com<mailto:droh...@apple.com>> wrote: >> +1 on moving the read/write logic into its own jar. >> >> Doug >> >> > On Dec 11, 2024, at 7:21 PM, David Capwell >> > <dcapw...@apple.com<mailto:dcapw...@apple.com>> wrote: >> > >> > From a disk format point of view the only thing I remember was the disk >> > type bug with UDTs. Bringing that logic back was hard as the type system >> > (in 5.0) tries to avoid allowing construction of invalid states, and we >> > would need to weaken that in order to enable the migration. Assuming the >> > user migrated from 3.x to 4.x then the sstable metadata should have been >> > rewritten to fix this bug. >> > >> > One thought (though know its a ton of effort).. we have talked about for a >> > long time about moving the reading/writing logic into its jar (so tools >> > don’t need cassandra-all and can limit the dependencies)… if we did that >> > we could try to solve this as an out of process migration… have the 2.2 >> > reader then write using 6.0 writer (ignoring compact storage… )… >> > >> >> On Dec 11, 2024, at 4:59 AM, Benedict >> >> <bened...@apache.org<mailto:bened...@apache.org>> wrote: >> >> >> >> I think 3.11 supported upgrade from 2.2, but I haven’t checked. I am >> >> fairly sure 4.x supported upgrade from 3.0.x also. >> >> >> >> >> >>> On 11 Dec 2024, at 12:53, Miklosovic, Stefan via dev >> >>> <dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>> wrote: >> >>> >> >>> I see. That makes sense. I think that by 3.x you meant basically the >> >>> latest 3.11, right? I guess 2.2 -> 3.0 already works, we would just try >> >>> to support 2.2 -> 3.11 straight away. I need to check where we are at in >> >>> that area. >> >>> >> >>> ________________________________________ >> >>> From: Benedict <bened...@apache.org<mailto:bened...@apache.org>> >> >>> Sent: Wednesday, December 11, 2024 13:09 >> >>> To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org> >> >>> Cc: Miklosovic, Stefan; >> >>> dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>; Miklosovic, >> >>> Stefan >> >>> Subject: Re: Supporting 2.2 -> 5.0 upgrades >> >>> >> >>> EXTERNAL EMAIL - USE CAUTION when clicking links or attachments >> >>> >> >>> >> >>> >> >>> >> >>> 2.2 is particularly hard because of the major storage format changes >> >>> that took place. >> >>> >> >>> I think if we want to retain (restore) upgrade support from 3.x I would >> >>> support that, but 2.x is probably too burdensome and likely to have too >> >>> many hard edges. >> >>> >> >>> I think if users only had to upgrade 2.2->3.x then eg 3.x->6.0 that >> >>> would be a pretty friendly upgrade path all things considered. >> >>> >> >>>> On 11 Dec 2024, at 12:03, Miklosovic, Stefan via dev >> >>>> <dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>> wrote: >> >>>> >> >>>> Hey, >> >>>> >> >>>> I want to fork the thread where we are mentioning that 2.2 -> 5.0 would >> >>>> be cool to support. >> >>>> >> >>>> I was involved in checking that offline upgrades from 3.0 to 5.0 work >> >>>> and fixed few issues along the way (1), hence I can imagine that >> >>>> supporting 2.2 -> 5.0 would be basically the same thing just on >> >>>> steroids and more involved? Anyway, having a stab into this is not >> >>>> useless at all, I will at least go deep into the upgrade stuff I have >> >>>> never given a lot of thought to which is good learning experience. >> >>>> >> >>>> Any tips where to start? Was any progress done by anybody already in >> >>>> this matter to not start from zero? >> >>>> >> >>>> (1) >> >>>> https://urldefense.com/v3/__https://issues.apache.org/jira/browse/CASSANDRA-19002__;!!Nhn8V6BzJA!RFZoz6sQSrP_qLd0K_eNWO3UAc1s8mTT5SkFalUMwM7_l9gWfb4cnfTFvdY68zsh5-REW7T8ALTPQwqMM_gWWSyp$ >> >>>> >> >>>> Regards >> >>> >> >> >> >
