Actually I'd like to take a step back and ask what are our plans for QMF and management in general. Fraser, this is in no way to discourage you or devalue your current contribution. But as you rightly pointed out in the later part of your email, we should look at the bigger picture and see if we can align our selves with the AMQP working group effort.
>From a community perspective, I'm not too keen to have our users to start using java QMF given the uncertain future. It might be a disservice to them. But on the positive side, your contribution has forced us to discuss this again! Regards, Rajith On Mon, Mar 25, 2013 at 2:32 PM, Fraser Adams <[email protected]> wrote: > Hi Ted, > I was torn between extras and tools. I guess what sold me on tools at the > moment was because I've noticed that a ruby subdirectory has just been added > there, so having a Java one too seems to make some sense. Also as part of > the Java QMF stuff I've done I've striven to add ports of the "canonical" > python tools (such as qpid-config). Now partly that's perhaps superfluous, > but it does provide good illustration how to use the QMF API. > > I'm a bit concerned that extras might be viewed a bit "second class citizen" > and as I say it was the ruby stuff now in tools that swung it for me. > > If there's strength of feeling that extras is more appropriate then that's > fine and I'll be OK with that, but then the location of the ruby stuff seems > inconsistent (I'm not knocking the ruby stuff, just trying to figure the > most consistent place). > > The "stand alone project" thing is interesting, there was talk of this for > QMF last year but it didn't sprout wings, and I guess probably won't. > Perhaps it might be time for a proper concerted think about "management" in > general. Rob looks like he might announce some stuff from OASIS on AMQP > management in the near future, so perhaps the time is ripe to move all the > management stuff into a new space to start the ball rolling on that general > trajectory? > > I haven't made a proper start on this yet 'cause I ran into issues with the > Java broker plugin stuff changing :-/ so I probably won't be able to make > progress for a week or so 'cause I'm just about to go on holiday. I'll have > email access but no development IT, it'll be good to have a discussion on > management in general and what the thinking on the more "strategic" picture > is. I think it's a good time to start this discussion, it's probably overdue > given the divergence between the C++ and Java brokers. > > Frase > > > > On 25/03/13 12:54, Ted Ross wrote: >> >> Frase, >> >> Another possibility is qpid/extras/qmf. That's where the Python >> implementation is. We've used the extras directory as a place to put more >> layered functionality, or things that might someday become stand-alone >> projects. >> >> -Ted >> >> On 03/24/2013 03:15 AM, Fraser Adams wrote: >>> >>> Hello all, >>> I'm looking to commit the Java QMF2 API, tools and GUI that I've hitherto >>> had as tarballs here >>> >>> https://issues.apache.org/jira/browse/QPID-3675 >>> >>> It's all pretty self-contained and although has dependencies on the Qpid >>> Java it doesn't impact anything in the main code base. >>> >>> My preference for location would be in qpid/tools/src in a new >>> subdirectory java which would seem to fit in given that there's a new ruby >>> subdirectory that's just been added. >>> >>> Does that seem reasonable? >>> >>> Regards, >>> Frase >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
