Since plugins are a collection of classes and they are available to me on the class path, I should be able to subclass any of them -- and replace them.
Imagine I like the functionality of one and want to add a bit more? Why can't plugins have protected methods that I customize? I don't want to redo all its work, but I do want to "replace" classes with my subclass. Paul On Sun, Jul 20, 2008 at 8:33 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote: > I don't see plugins as something that you extend, but more like > something that you customize. If there is something that you need to > modify on a plugin, then that should probably be an extension point in > the plugin. Take for example the case of Codebehind and REST, with > some small modifications Codebehind was modified so it could be > "customized" by REST without having to extend it. I know this doesn't > cover all the possible use cases. > > musachy > > On Sun, Jul 20, 2008 at 8:45 PM, Paul Benedict <[EMAIL PROTECTED]> > wrote: > > When I want to extend a plugin, I unfortunately have to unpack the > libraries > > and include them into my own web application. I use Maven's Dependency > > plugin for this. :-) It is the only way I know of getting a hold of the > > binaries without forcing them into plugin status. > > > > I see two ways out of this: > > 1) Refactor each plugin to be the code and a plugin jar wrapper. > > 2) S2 needs a way of saying which plugin NOT to load. Obviously the > plugin > > jar is going to be in WEB-INF/lib. That's good enough to extend, if I > have a > > way to stop it from registering. > > > > I wholly prefer #2. Other options welcomed. > > > > Paul > > > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
