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 >
