Modularization of plugins

Charles Crouch ccrouch at redhat.com
Fri May 13 14:20:45 UTC 2011


I think there are a number of separate concerns here:

1) location of source for plugins
2) how plugins are packaged together and installed
3) when plugins are released

I think 1) can be changed without necessarily impacting 2) and 3), though it would require changes to our current release build process. 
I think the issue that's been brought up is around it being a pain to just build and commit a new plugin, because currently you also have to build the entire rest of the server. I don't think there have been any concrete objections to how we do 2) or 3) above.

One thing we would need to insure that the required jar's from the main rhq build were available in a maven repo somewhere such that people could just pull the plugin repo and build successfully. I imagine that would also mean that the master branch of the plugin repo would not rely on SNAPSHOT versions of core rhq jars, but rather a specific released version.

Cheers
Charles


----- Original Message -----
> 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


More information about the rhq-devel mailing list