I'm open to name changes here, but lets get some consensus. I personally favour reactortools, but it's long winded, like multiproject. Since the reactor is designed to do multiproject builds, maybe that makes more sense.
ok, so now I'm leaning towards multiproject. Any objections? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Work: http://www.multitask.com.au Brian Ewins <[EMAIL PROTECTED]> wrote on 27/06/2003 11:21:50 PM: > > > Rafal Krzewski wrote: > > > I admit that having reactor tag (backed by reactor bean) and reactor > > plugin may be confusing. Still I don't see any compelling alternative. > > > > How about giving it a different name that new users would recognize? The > 'reactor' is something people only learn about by reading through the > manual[1] or asking on the mailing lists. The name just isn't > recognizable as doing what it does. > > Something like 'multiproject:build' is a bit more obvious than > 'reactor:build' for example. Some other example names - mainly taken > from what people use before they know about the reactor, or when > describing the reactor: > > subprojects:build, subprojects:site [2] > master:build, master:site > masterproject:build, masterproject:site > mainproject:build, mainproject:site > aggregate:build, aggregate:site [3] > > Just a suggestion. > > -Baz > > [1] I know, I know, RTFM... > [2] this is the one that makes most sense to me > [3] the 'reactor' concept is called an aggregate build in the GNU make > manual, I dont think the name is very clear though. > > > > Privacy and Confidentiality Notice > > ------------------------------------------------ > > The information contained in this E-Mail message is intended only > for the person or persons to whom it is addressed. Such information > is confidential and privileged and no mistake in transmission is > intended to waive or compromise such privilege. If you have > received it in error, please destroy it and notify us on the > telephone number printed above. If you do not receive complete and > legible copies, please telephone us immediately. Any opinions > expressed herein including attachments are those of the author only. > i-documentsystems Ltd. does not accept responsibility for the > accuracy or completeness of the information provided or for any > changes to this Email, however made, after it was sent. (Please note > that it is your responsibility to scan this message for viruses). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
