Hello.
Yes, some kind of process to select what component live or die is a good
idea. In the case of beanio, I'm almost sure that many IT teams still
use it for customers that need its features. Even if old fixed length
formats seem to be obsolete today, retail companies (and more) like our
current customer use them for exchanging data between the back-office
systems of their own entities , point of sales logistic, partners and
suppliers, transport or government, etc... When a possibility exists to
use alternative "modern" formats (XML for example), new schemas are
defined. But in many cases I bet that some of the oldest plain text
definitions will stay for many years, since no functional change is
needed, and thus no reason exist to spend time and money updating legacy
software in all the "business galaxy"... From my point of view this is
where we can see that features are "dead" or not, and not only listing
commits 😉! We notice the same for IT languages in this world where C or
COBOL are probably more present than Java, that many already say "old"
(not dead yet)... I've been using Camel itself for many years,
especially with ServiceMix as our ESB platform : is Camel still young,
or mature, or ... ?
Back to camel-beanio : I've not found detailed documentation about SPI
and integration contracts for data formats : even if I think it's going
to be difficult for us to assume such a work, I'd like to estimate the
workload to get it back as is, with a correct integration in our DSLs
(mostly blueprint, and Java), test framework, etc. Some nice link about
that ?
Thanks again.
Regards.
Ephemeris Lappis
Le 28/12/2022 à 00:45, Rhuan Henrique a écrit :
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
