Modularization of plugins

David A. Webster DAWEBSTER at UP.COM
Fri May 13 13:36:52 UTC 2011


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


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


More information about the rhq-devel mailing list