Re: Camel 3.X / DataFormat BeanIO

[Otavio Rodolfo Piske <an...@gmail.com>]

Unfortunately unmaintained code (even if it has no dependencies) can pose a
risk (in terms of CVEs, attack footprint, etc) to the project and all the
community around it. Removing functionality is not cool, but exposing the
community is even worse IMHO.

There is indeed a process before removing these components:

1. We add a deprecation for them in Jira [1]
2. We wait for the next LTS release
3. They are removed after the LTS release [2]

When we deprecate these components, a few things happen:

1. They are marked as so in the build summary and appropriate classes are
marked as deprecated (so that it's clear to the community contributing that
those components have become deprecated)
2. They automatically get marked as deprecated on the index [3]
3. After removed, they are added to the migration guides [4]

Granted: there's certainly room for improvement, but I am not sure how
feasible it is given the number of contributors, infrastructure, etc.

Links:
1. Examples: https://issues.apache.org/jira/browse/CAMEL-17667,
https://issues.apache.org/jira/browse/CAMEL-18455 or
https://issues.apache.org/jira/browse/CAMEL-17667
2. https://issues.apache.org/jira/browse/CAMEL-18496
3. https://camel.apache.org/components/3.20.x/index.html
4. https://camel.apache.org/manual/camel-3x-upgrade-guide-3_19.html


On Wed, Dec 28, 2022 at 12:45 AM Rhuan Henrique <rh...@gmail.com> wrote:

> 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 <ra...@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.lappis@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 <ki...@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 <
> > > >> ancosen@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
> > > >> <ep...@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 <cl...@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.lappis@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
> > >
> >
>


-- 
Otavio R. Piske
http://orpiske.net