"I would suggest starting with moving the Python ones to a dedicated repo, let's have a workflow established and polished there, might follow with some Java ones in case it works well."
Yeah kinda where my head is too On Fri, Jun 21, 2024 at 2:07 PM Arpad Boda <ab...@apache.org> wrote: > Joe, > > Interesting thoughts, I see a lot of pros and cons. Let me list the most > important ones of both: > +cves in extensions doesn't make nifi "vulnerable" automatically as they > live in a different repo. > +the responsibility of being up-to-date is being moved to the maintainers > of the given extension, same applies for the stability of the tests > covering that extension > > -easier to introduce breaking changes accidentally: a breaking change might > go through and get committed. Especially in case of Java extensions, they > python api is pretty thin (yet!). Only an extension developer will find it, > most probably not immediately, when things already depend on the breaking > change and it gets very difficult to make the right call in this case > -might lose some extensions as they get even less maintained than they are > now > > Overall I have no strong opinion either ways, I would suggest starting with > moving the Python ones to a dedicated repo, let's have a workflow > established and polished there, might follow with some Java ones in case it > works well. > > Cheers, > Arpad > > On Friday, June 21, 2024, Joe Witt <joew...@apache.org> wrote: > > > Team, > > > > For the longest time we had all these Java based extensions and it was > > often inconvenient for them to live within the codebase. Indeed it makes > > the builds crazy long and it delays getting new components out. We had a > > lot of work to do for this to be convenient and perhaps we still have > gaps > > remaining. > > > > Now we have these Python components. I am not confident we really want > > these in the codebase for similar but even more important reasons. The > > python components have similar issues when it comes to Licensing and > Notice > > recognition. They have their own rapid vulnerability tracking. Our > > current tooling doesn't make tracking that very easy. > > > > I'm concerned about where the Python ones are heading in terms of > > maintainability but also generally for the builds as well with the Java > > ones. Is it time to move to a repo for the Java extensions and its own > > project/group name and versioning? Same for Python extensions? > > > > This lets them evolve on their own schedule. It does bring up an > > interesting challenge as it relates to a convenience binary. The ideal > > state is extensions are released and shipped independent of the nifi > > application. But we'd need to make that really nice/easy for the users. > > > > We have a lot going on so maybe still not time to tackle this. Curious > to > > hear thoughts > > > > Thanks > > >
