btw if you think about that ... if we ever felt some strong urge to move from Ant we could not overcome and we had code split to more modules / subprojects already, then moving such an already-splitted project from Ant to whatever else would be just an exercise. It would be like "OK we split Cassandra's codebase to 10 modules" so moving that to Maven or whatever would be just about what? About writing poms and wiring that together.
I suggest we try to make a simple module by extracting some functionality to see how it would look like, gain the experience to do that and iterate. I can imagine untying all the guts so we can ship that as separate jar will be the work in itself (and most probably the majority of that). My main concern was to not complicate it further and rather to start from scratch but if we take an iterative process like that, that might also make it easier to move away eventually if we think it is the right move as we would have split it already anyway. On Thu, Dec 12, 2024 at 6:01 PM Benedict <bened...@apache.org> wrote: > Why would ant get in the way? We already build multiple jars, and accord > will be a submodule. We have far more organisational issues to overcome > than ant. > > I have for a while advocated for a shared lib to also share between Harry, > accord, dtests etc > > I am however not 100% sure about splitting read/write path, at least not > as first posited. The idea of maintaining it as an API for dropping in > different jars is a whole other world of potential pain I don’t want to > countenance. Supporting eg bulk readers or writers or other integrations > seems pretty feasible though. > > On 12 Dec 2024, at 16:53, Paulo Motta <pa...@apache.org> 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 >> >>> >> >> >> > >> >>
