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