cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: [PROPOSAL] Modularize Spring
Date Wed, 18 Sep 2013 17:32:54 GMT
Right, component isn't a thing.  I probably shouldn't use that term.  I
want to standarize on the naming convention of plugin, module, and
extension.  It is explained a bit on the wiki [1] but I'll try to do a
little better job here.  So a plugin is basically a jar.  A jar contains
multiple modules.  A modules ends up being a spring application context
that composes multiple configuration files.  Modules are assembled into a
hierarchy at runtime.  Extensions are implementations of interfaces that
exist in a module.  A maven project produces a jar, so a plugin ends up
being a maven project also.

So currently today we don't have a strong definition of Plugin and I hope
to address that.



On Wed, Sep 18, 2013 at 4:25 AM, Daan Hoogland <>wrote:

> sounds great Darren,
> By component, you mean maven project or some larger chunk like
> distribution package? (did i miss this definition somewhere or do we
> define the components now?)
> regards,
> Daan
> On Wed, Sep 18, 2013 at 12:10 AM, Darren Shepherd
> <> wrote:
> > Currently ACS code is fairly modular in that you can add plug-ins to ACS
> to
> > extend most functionality.  Unfortunately ACS is not packaged in a
> modular
> > way.  It is still delivered essentially as one large unit.  There are
> many
> > reason for this but one large barrier to modularizing ACS is that the
> > Spring configuration is managed as one large unit.
> >
> > I propose that we break apart the Spring XML configuration such that each
> > component contributes its own configuration.  Additionally each component
> > will be loaded into its own Spring ApplicationContext such that its beans
> > will not conflict with the wiring of other beans in ACS.  This change
> will
> > lay the foundation for a richer plugin model and additionally a more
> > distributed architecture.
> >
> > The technical details for this proposal can be found on the wiki [1].
> >
> > Darren
> >
> > [1]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message