Modularization of plugins

John Sanda jsanda at redhat.com
Fri May 13 14:32:49 UTC 2011


We already store plugin versions and there is already some logic that 
deals with versions during deployment. Granted there would likely be 
changes we would want to make, but we wouldn't be starting from scratch.

On the one hand releasing each plugin individually would introduce a lot 
of overhead. On the other hand, releasing all plugins together has its 
downsides. Let's say we have an updated apache plugin that contains some 
critical bug fixes and new features that is ready for release. But the 
jboss-as-5 plugins is not yet ready to be shipped. The two plugins are 
pretty well independent of one another whereas the hibernate plugin is 
very much tied to the jboss-as5-plugin. Maybe a solution would be to 
organize plugins into groups using plugin dependencies as a starter 
criteria.

I absolutely envision an automated deployment that would utilize the 
content subsystem. We could define and configure plugin repositories in 
the RHQ server. The server could periodically check the repos for 
updates and provide notifications when new/updated plugins are available.

There has to be a good middle ground. I am just not sure what that is yet.
On 5/13/11 9:36 AM, David A. Webster wrote:
> Sound good in theory.  It is not particularly desirable to have to 
> wait for another release to get the next batch of project-supported 
> great plugins, that may be ready long before a new overall release is 
> ready.  But splitting plugins out into a separate distribution does 
> add a significant level of complexity to project management.
>
> 1)  you have the version compatibility issue to deal with already 
> mentioned.  For plugins with lots of dependencies this could get 
> really nasty.
> 2) Release management -- do all the plugins get released in a "batch" 
> as part of a separate distribution?  Or is there a release of each 
> plugin as it gets developed?  That could mean a separate "sub project" 
> for every plugin that is an official part of main product.
> 3) How is a plugins release distributed and installed?  Do i have to 
> manually install/deploy all the plugins on every release?  Assume 
> there would be some sort of automated deployment mechanism for a 
> separate plugins release?
> 4) With a new release of the main product, does it include all the 
> plugins, or are the plugins released separately, and in a batch or one 
> at a time in separate distributions/downloads?  Another facet of the 
> version compatibility issue.
>
> Just some thoughts.
>
> David Webster
> Union Pacific Railroad
> Lead Architect-Web Infrastructure
> Systems Engineering
> Phone: (402) 544-1094 | Email: dawebster at up.com
>
>
> *John Sanda <jsanda at redhat.com>*
> Sent by: rhq-devel-bounces at lists.fedorahosted.org
>
> 05/12/2011 11:52 PM
> Please respond to
> rhq-devel at lists.fedorahosted.org
>
>
> 	
> To
> 	rhq-devel at lists.fedorahosted.org
> cc
> 	
> Subject
> 	Re: Modularization of plugins
>
>
>
> 	
>
>
>
>
>
> Actually, I think a stronger argument can be made that it is less
> practical not to put plugins into a separate repo. RHQ is a really big
> project, and building it take a considerable amount of time even with a
> hefty multi-core machine that has lots of RAM. There is a very clear
> separation between plugins and other parts of RHQ; so, the initial
> effort would not be very involved. There are some things to consider
> though. Plugins could be released on a separate schedule which brings
> version compatibility into the fold. This would result in additional
> maintenance, but I think the pros far outweigh the cons. I think a
> separate release schedule for plugins is/could be a good thing. I also
> think it could help spur community involvement. We might consider a
> plugins sandbox for things that are more experimental. Plugins could be
> promoted from the sandbox into the main plugins repo. I think that this
> model has worked really well with Apache Commons.
>
> - John
>
> On 5/12/11 9:07 PM, Elias Ross wrote:
> > I was thinking, it'd be nicer if the standard plugins were all located
> > in a separate git repositories. It would make it easier to git clone,
> > and later extend/improve each of them without having the concern of
> > tracking the main project.
> >
> > Of course, they are so many, it's not likely practical. Perhaps just
> > the plugins in one repository by itself?
> >
> > You end up in a situation where you must first master doing the
> > complete build (which I haven't!) to contribute to one part of it. I
> > keep getting hung on GWT for some reason.
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/rhq-devel
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
>
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/rhq-devel/attachments/20110513/577eb5b2/attachment-0001.html 


More information about the rhq-devel mailing list