Hello Hopsters! I've heard of several organisations who are porting over plugins to the Apache Hop API. Likewise we already have a few plugins which we can't incorporate into the Apache Hop downloads because of conflicting licenses ... but which are still worth consideration by potential users. Finally we know that there are companies out there considering migration to Hop which have dozens of self-written plugins which they don't want to (or can't share) with the world. These companies or organisations would probably like an internal way of distributing plugins.
Here are some of my thoughts to kick this off... On the back-end we need a way to automatically update plugin metadata to the latest version. Doing this manually just doesn't work well. This can be done by looking at github downloads or some other way of doing this automatically. We need some way to make sure that what people download is what they think is downloaded. (signing, checksums, ...) We'll also want clear metadata about the downloadable content: version, status, license, company, website, support, forum, source code, JIRA, ... We would want to flag plugin versions for critical/recommended updating or even to flag them for forced update (for example in a large company with lots of Hop users). On the Hop client side we would want a way to browse plugins in the Hop GUI but also on the command-line. We need an easy way of adding new plugin sources. We need a way of downloading and/or updating all or certain plugins. We need ways of enabling/disabling plugins. For our Lifecycle Environments we would want to combine this with Environment validation rules so that we can set a minimum version for Apache Hop itself but also the installed plugins, Java or even the underlying operating system, the memory or disk requirements and so on. Using that metadata we can then inform the Hop user that a certain plugin is of the wrong version, needs to be installed and so on. The marketplaces, code repositories or whatever we're going to call it can be implemented at any given time as a plugin itself. This can be seen separately from everything else. Let me know if you had any other immediate requirements and what kind of terminology we should use for the various parts in play. Cheers, Matt
