Hi,

I also support both the removal of the listed components and the jni
extension as well,
even though the latter compiles (on some platforms) there are no tests, and
can also
be restored later if needed.

Regards,
Adam

On Wed, Jun 12, 2024 at 11:33 AM Ferenc Gerlits <fgerl...@apache.org> wrote:

> I also agree with the removal of the stale/unmaintained components
> listed by Marton.
>
> It would be nice if we could use a NiFi processor via JNI in a pinch
> if there is no native equivalent, until a C++ alternative becomes
> available.  On the other hand, this does not work right now, it would
> be a lot of work to achieve it, and no user has asked for it.  On
> balance, I would keep JNI for now, but I'm not strongly opposed to
> removing it.
>
> Thanks,
> Ferenc
>
> On Tue, Jun 11, 2024 at 7:15 PM Martin Zink <martinz...@apache.org> wrote:
> >
> > Hey Marton,
> >
> > I strongly support this, and I also agree with Gábor that JNI should
> > be dropped as well.
> > Minifi java is in a really good shape so if anybody wants to use the
> > java processors I can't see a reason why would they bother with the
> > C++ agent with JNI since the whole point of the C++ agent goes out the
> > windows (since you have to have JVM with all of its bells and
> > whistles), and since its not really maintained I don't expect it to
> > work that well anyways.
> >
> > And due to the unique nature of JNI implementation, I always felt like
> > that's the extension that hinders our refactor efforts the most
> >
> > BR,
> > Martin
> >
> > On Tue, Jun 11, 2024 at 6:29 PM Gábor Gyimesi <lordga...@apache.org>
> wrote:
> > >
> > > Hi Marton,
> > >
> > > I also support removing all of these unused extensions, thanks for
> > > starting the discussion about this!
> > >
> > > I think we could also discuss if JNI extension could be removed. It's
> > > a special extension for running Java processors in MiNiFi C++, but as
> > > MiNiFi Java is also available for this purpose, and I'm not aware of
> > > any users that are using Java processors in MiNiFi C++ maybe that
> > > could be removed as well. Similarly to the other extensions it hasn't
> > > been tested or maintained for years.
> > >
> > > Regards,
> > > Gabor
> > >
> > > On Tue, 11 Jun 2024 at 17:42, Arpad Boda <ab...@apache.org> wrote:
> > > >
> > > > Marton,
> > > >
> > > > Thanks for bringing this up, I'm +1, too!
> > > >
> > > > Cheers,
> > > > Arpad
> > > >
> > > > On Tue, Jun 11, 2024 at 5:05 PM Joe Witt <joe.w...@gmail.com> wrote:
> > > >
> > > > > Marton
> > > > >
> > > > > I strongly support this. The path needs to be maintainable and
> keeping
> > > > > things around that dont get the love create many challenges.
> > > > >
> > > > > Thanks
> > > > >
> > > > > On Tue, Jun 11, 2024 at 7:48 AM Marton Szasz <sza...@apache.org>
> wrote:
> > > > >
> > > > > > Hi community,
> > > > > >
> > > > > > We're considering to drop certain features from MiNiFi C++ that
> seem to
> > > > > > be unused, and not worth maintaining. If you would like to keep
> some of
> > > > > > them, please share your opinion and your use case for them!
> > > > > >
> > > > > > To be removed:
> > > > > > 1. CoAP C2: not used anywhere as far as I'm aware, and not well
> > > > > > maintained. C2 over HTTP would remain unchanged.
> > > > > > 2. nanofi: This was an initiative around 2019-2020 to rewrite
> about half
> > > > > > of minifi in a C library form for integration to other software.
> There
> > > > > > was no development on it since early 2020, and I'm not aware of
> any
> > > > > users.
> > > > > > 3. pcap extension: not well tested or maintained, probably not
> used by
> > > > > > anyone
> > > > > > 4. usb camera extension: same as pcap
> > > > > > 5. sensors extension: same as pcap
> > > > > > 6. openwsman extension: same as pcap
> > > > > >
> > > > > > As we progress towards the new major versions, now is our best
> > > > > > opportunity to remove unused code, so the codebase becomes
> easier to
> > > > > > maintain, and this hopefully unlocks new feature possibilities.
> Let me
> > > > > > know what you think!
> > > > > >
> > > > > > Thanks,
> > > > > > Marton
> > > > > >
> > > > > >
> > > > >
>

Reply via email to