Maybe we need a process to select components to be removed, with the community feedback, and alert the developer that the component is deprecated after a component is selected to be removed. I'm understanding one problem here is the component was removed causing surprise to users.
On Tue, Dec 27, 2022, 20:33 ski n <raymondmees...@gmail.com> wrote: > Sometimes it's also good to question why the project is dead. I also worked > for big retail companies, as well as government organizations, and saw > fixed length formats on various occasions. The truth is that these formats > are outdated and get less and less support, thus fewer libraries and tools. > This will only get worse. At a certain moment, I think it's better to have > a good internal discussion than to search for technical solutions on the > old path (even if modern solution are less capable and feel like a > workaround). Believe me, I have enough of these and know how hard they are. > > Regards, > > Raymond > > > > On Tue, Dec 27, 2022 at 11:44 PM Ephemeris Lappis < > ephemeris.lap...@gmail.com> wrote: > > > Hello again. > > > > I'd personally like to contribute to bring Beanio back to Camel, but in > > the context of our customer's works I'm afraid we can't afford it : our > > current job is essentially to create and maintain softwares and > > information systems of these business entities, using middlewares and > > tools, and not providing them. We're planing a migration from our old > > Red-Hat Fuse to more recent, lighter Karaf and Camel stack, and the road > > seems to be... quite long... > > > > I've had a look at the camel-beanio's code, and it seems that it should > > not be so difficult to fork it or perhaps reuse a part of it, > > considering only the beanio features, without any component interface > > (avoiding future work to follow Camel versions and changes), with > > processors for example. This would imply some changes to our routes, but > > would limit impacts on the many files mappings and their processing. > > > > But this is probably not the preferred strategy : a data format in the > > Camel's scope is still clearly the best choice, offering a fully > > integrated component for all... > > > > I've noticed, if I'm not wrong, that the old camel-beanio library itself > > has no external dependency (out of Camel's world) that could be a > > concern about security CVEs. This is probably a good news, whatever > > solution. > > > > So I also vote to get beanio back :) ! > > > > Regards. > > > > Ephemeris Lappis > > > > Le 27/12/2022 à 22:16, Andrea Cosentino a écrit : > > > If you have time and there is a willing to maintain the library, this > is > > > good > > > > > > As of today, the only updated release is milestone from 18 months ago > and > > > no further work. > > > > > > There should be a community of developers working on the beanio fork to > > > consider it again for being in Camel. > > > > > > Il mar 27 dic 2022, 21:39 kilidarria <kilidar...@gmail.com> ha > scritto: > > > > > >> I would vote to bring this back and maintaining it. We also have > > numerous > > >> flat files with complex record structures defined. We are currently RH > > fuse > > >> I'm not sure what their upgrade plans are for Camel 3 so I have some > > >> time. MarciSent from my Galaxy > > >> -------- Original message --------From: Andrea Cosentino < > > >> anco...@gmail.com> Date: 12/27/22 3:03 AM (GMT-08:00) To: > > >> users@camel.apache.org Subject: Re: Camel 3.X / DataFormat BeanIO The > > >> problem with this kind of dead libraries is related to the fact > thatthey > > >> rapidly become affected by multiple CVEs.So being mature and non > > >> maintained, it's a problem.Since nobody updates or release new > versions, > > >> going ahead we're going toinclude weak libraries if we maintain them > in > > >> codebase.So, I don't think there is any hope to see the component back > > in > > >> the camelcodebase.Il giorno mar 27 dic 2022 alle ore 12:00 Ephemeris > > Lappis > > >> <ephemeris.lap...@gmail.com> ha scritto:> Hello.>> It seems very > > strange > > >> to me to remove a component when no easy> alternative exists. Almost > > half > > >> of our about 100 projects use fixed> length files that are still used > by > > >> many companies legacy systems, and> rely on beanio.>> In my opinion, a > > >> stable component that has no recent change is not> "dead", just > > "mature".>> > > >> Can we hope it gets back to a future Camel release ?>> Regards.>> Le > > mar. > > >> 27 déc. 2022 à 11:47, Claus Ibsen <claus.ib...@gmail.com> a écrit> :> > > >> > > >>> Hi> >> > BeanIO is a dead/not-active project and removed in 3.x, as > > some > > >> other> > components - its documented in the upgrade guide to 3.17.x> > >> > > >> > > >>> On Tue, Dec 27, 2022 at 11:38 AM Ephemeris Lappis <> > > > >> ephemeris.lap...@gmail.com> wrote:> >> > > Hello.> > >> > > I'm very > > >> surprised to see that the data format BEANIO has been removed> > > in > > the > > >> last Camel versions. Isn't any replacement component ?> > >> > > We > used > > >> BeanIO in many exchanges that handle enterprise legacy systems> > > > > fixed > > >> length formatted files (big retail companies still use it for> > > > many > > >> purposes). I know alternative components for many file formats> > > > > (xml, > > >> csv, etc.), but for fixed length, BeanIO is really the only one> > > > > that > > >> can handle complex structured files...> > >> > > What can we do :( > ???> > > > > > >>>>>> Thanks for any idea that can save our migration plans.> > >> > > > > >> Regards.> > >> >> >> > --> > Claus Ibsen> > -----------------> > > > >> @davsclaus> > Camel in Action 2: https://www.manning.com/ibsen2> > > > > -- > > Cet e-mail a été vérifié par le logiciel antivirus d'Avast. > > www.avast.com > > >
