I agree that if we're building a config for the JavaEE5 item then we can
create a plugin. I think the problem will come from those items that
don't have a strong service-like runtime characteristics (such as the
common annotations or JSTL) and therefore wouldn't normally be configs.
Perhaps we can/should force these to be configs just so that we can
deliver them as plugins?
Joe
Guillaume Nodet wrote:
There is no real difference between a plugin and a car.
So if Geronimo can be built using cars, it surely can be built
using plugins. You just need to define the needed dependencies
between the cars. One problem will come from the console, which
is not pluggable yet, but the portlets could be slightly enhanced
to display nicely if a needed car (gbeans) is not available.
On 11/6/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
On 11/6/06, David Jencks <[EMAIL PROTECTED]> wrote:
> I would much prefer that we develop each jee5 feature as a plugin and
> put each one -- modules and configs -- into a plugin in a (new)
> plugins area. Then we can move each current trunk feature into the
> plugins area one by one and actually get an improved organization.
> We could base assembly on the micro-g or have a separate jee5
> assembly area.
Is the plugin feature strong enough to let us build one plugin for
each jee5 feature? Can we divide jee on such small parts that can be
represented as plugins? Won't there be any overlapping features that
won't be able to be build as plugins?
Jacek
--
Jacek Laskowski
http://www.jaceklaskowski.pl
