Overall, a good idea.
I do think that to make it work, there'd have to be clear admission
criteria, and an independent board / comittee to judge submissions
against these criteria.
Feedback to devs should also be in terms of those criteria in case
their submission is currently not admitted.
One of the criteria I would suggest is availability of freely
available documentation (so it can be linked to from the marketplace
site).
I would also suggest criteria for the content and structure of the
documentation.
The value in this is to make it easy for potential users to discover
whether it makes sense for them to use a a particular plugin.
kind regards,
Roland
> --
> You received this message because you are subscribed to the Google Groups
> "kettle-developers" group.
> To post to this group, send email to kettle-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> kettle-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/kettle-developers?hl=en.
>
--
Roland Bouman
blog: http://rpbouman.blogspot.com/
twitter: @rolandbouman
Author of "Pentaho Solutions: Business Intelligence and Data
Warehousing with Pentaho and MySQL",
http://tinyurl.com/lvxa88 (Wiley, ISBN: 978-0-470-48432-6)
Author of "Pentaho Kettle Solutions: Building Open Source ETL
Solutions with Pentaho Data Integration",
http://tinyurl.com/33r7a8m (Wiley, ISBN: 978-0-470-63517-9)
you raise a number of good points I hadn't thought about.
My reply mostly reflects my own experiences hunting for plugins.
With a few exceptions (web browser plugins), whether its CMS-related
(drupal), web development (jQuery), I find I spend oodles of time
downloading and trying plugins just to find out what they actually do.
In many cases, documentation is so sparse that it's hard to even
comprehend what the function of the plugin is. Just a little bit of
documentation (screenshot + typical example) would remedey say 50% of
those problems.
But indeed maybe documentation criteria is a bit over the top. The
voting system may indeed work as a filter - thanks for pointing that
out.
regards,
Roland
--
You received this message because you are subscribed to the Google Groups "kettle-developers" group.
To post to this group, send email to kettle-d...@googlegroups.com.
To unsubscribe from this group, send email to kettle-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en.
We have a concept of "official" and "unofficial" packages for Weka.
Official packages get their meta data hosted at the central repository
(the package itself can reside anywhere that is http accessible) and
are verified by the Weka team (to the extent that the package
functions and does not contain malware etc.). Unofficial packages
don't get their meta data hosted at the central repository and can be
installed by just pointing the package manager at their URL. The
unofficial route allows folks to quickly make (possibly) experimental
stuff available without having to go through the official channel.
The main motivation for the Weka project was to reduce the burden of
supporting external contributions. It makes a clear delineation
between what is provided by the core Weka team and what is a
contribution. A secondary goal was to open up Weka to the use of
third-party libraries (something that has been avoided like the plague
in the past :-)). Third-party library related issues/problems are now
clearly the domain of package contributers who include them in their
packages.
This has all been working just swimmingly since the release. Packages
have been downloaded via the package manager more than 33,000 times
since late July.
The package manager code is independent of Weka and is checked in to
Pentaho's public SVN.
For those who are interested, the central repository is at:
http://weka.sourceforge.net/packageMetaData/
Information on the clients and package structure is at:
http://weka.wikispaces.com/How+do+I+use+the+package+manager%3F
http://weka.wikispaces.com/How+are+packages+structured+for+the+package+management+system%3F
Cheers,
Mark.
This effort is nowhere near complete and is provided as a test-bed for
the technology. There is wiki page up outlining the new OSGI-based
plugin system and I am looking for feedback!:
http://wiki.pentaho.com/display/EAI/OSGI-enabled+Kettle
--
You received this message because you are subscribed to the Google Groups "kettle-developers" group.
To post to this group, send email to kettle-d...@googlegroups.com.
To unsubscribe from this group, send email to kettle-develop...@googlegroups.com.
Not sure of the answer for the normal use case, but two thoughts:
1) is there any reason _not_ to have the capability to dynamically
install plugins? If an OSGI container works without too high of cost
(and from my experience that should be true) why not use it?
2) I sorta have a vauge idea of using PDI for the configuration /
management of some parts of the back end of an app server that needs
to be able to dynamically add new interfaces to many strange and weird
external data sources. The ability for it to play in the OSGI world
in general may open it up to many new and exciting use cases?
--
Peter Hunsberger
--
You received this message because you are subscribed to the Google Groups "kettle-developers" group.
To post to this group, send email to kettle-d...@googlegroups.com.
To unsubscribe from this group, send email to kettle-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en.
> I agree with you Matt. OSGI provides a wealth of options that aren't
> all desirable at the same time. Sitting down and deciding how to
With OSGi you get many things "for free" just by using it. The other thing one gets is lots of other smart people sorting out complicated issues like applications with depedencies across class loaders, etc.
For instance, in a service engagement we're building a set of PDI Job plugins. The plugins all have some common functionality (base class) and then we extend them for the specific fcnality. Given the current plugin classloading mechanism, we can't actually install all this as a plugin.
You can only have 1 plugin per plugin.xml, and each plugin has it's own classloader. Currently, you can't have a package (with a base class) either duplicated across all plugins (you'll get strange errors like Object X cannot be cast to Object X) or only in one (class not found from one plugin to another). The only way currently to solve this problem is to include the base classes, which are really part of the plugins, in the kettle libext and then have the individual plugins extended from that classloader.
So... there's one piece of functionality that OSGi solves well. The ability for plugins to build "on top of each other" instead of just being able to build upon core Kettle. Enough to warrant a whole framework? ;) Maybe not. All the same, use cases for the way OSGi handles these types of things are there.
Nick
--
You received this message because you are subscribed to the Google Groups "kettle-developers" group.
To post to this group, send email to kettle-d...@googlegroups.com.
To unsubscribe from this group, send email to kettle-develop...@googlegroups.com.
> Your assertions are fortunately not true.
Love it when I'm wrong and it means a limitation isn't actually!!!
> And best of all: no XML is involved ;-)
Yeah... I saw some notes in the plugin loader that this was only for testing... Double checking looks like the general classpath search was the one that's marked as testing only. I got the sense that the annotations was the slightly off color method and that the plugin.xml was the primary way to build plugins. Are annotations now the preferred method?
Does the annotation method bring in all annotated plugins into separate classloaders? ie, with XML you get one classloader per plugin. Now, it would seem you get either
1) a single classloader for all annotated plugins
-or-
2) a single classloader per loaded .jar in plugins/ dir
This is great news! Makes my day! Multiple plugins in a single jar! :)
Nick
Nick
--
You received this message because you are subscribed to the Google Groups "kettle-developers" group.
To post to this group, send email to kettle-d...@googlegroups.com.
To unsubscribe from this group, send email to kettle-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en.