"I think its a bad idea to have duplicated files":
+1 agree with Gordon here, the source tree is already confusing enough
(I'd be keen to see a lot more of the "modularisation" that has begun
with proton/jms/dispatch etc. it'd be good to start to be able to put
together systems from pluggable components - I think that's what the
strategy seems to be, but that shouldn't be at the cost of copy'n'paste
reuse, which whilst fine for a quick fix ultimately isn't sustainable).
"The java broker no longer uses this. However I'm not sure whether the
Java based QMF API does?" no, none of the Java (or GUI stuff)
*explicitly* uses the management schema, but I did "reference" it
especially for the method calls. I did wonder about generation, but it's
probably not so useful these days given the Map model for both QMF2 and
the AMQP 1.0 Management spec - the GUI attempts where possible to
introspect the objects it receives. As it happens the Java QMF code has
full support for all of the QMF2 API Schema query stuff, but the broker
only supports that for QMF1 - I did raise a Jira *ages* ago (before I
was a committer) with a patch that mapped QMF1 types to QMF2 responses,
but it never got any traction :-) I doubt there's any point now.
Actually that reminds me. In a bunch of places in my JavaDoc I had
references to the QMF2 API (that never was :-)) which is what the Java
API actually implements:
https://cwiki.apache.org/qpid/qmfv2-api-proposal.html
I noticed that in the 0.24 website reorganisation that link is broken
and I can't actually find any sign of it (I can find the QMF2 protocol
stuff). Any idea where it is? I'd still quite like to be able to
reference it. I realise that it's not the API of the future, but frankly
I think that there was a lot of good stuff in there and it'll be
interesting to use that to figure out any potential gaps as the AMQP 1.0
Management stuff gets a bit of traction - it seems a shame to lose that
history/linkage (well at least until AMQP 1.0 Management has taken over
the world).
"If it doesn't then I personally don't mind having this moved to the cpp
tree, but lets remove the other copy to avoid confusion. "
+1 I'd definitely rather have a move than a copy. It might be worth
having a README in the specs directory to say it has moved (at least for
the first version after it has moved - kind of like Ted has done when he
moved dispatch).
Cheers,
Frase
On 06/11/13 18:50, Gordon Sim wrote:
On 10/29/2013 09:31 PM, Andrew Stitcher (JIRA) wrote:>
[
https://issues.apache.org/jira/browse/QPID-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808477#comment-13808477
]
Andrew Stitcher edited comment on QPID-5237 at 10/29/13 9:31 PM:
-----------------------------------------------------------------
I've made the c++ tree self contained by copying in the 3 things that
were being used that were external:
* The version file (QPID_VERSION.txt)
* The xml specification of amqp 0-10 used to generate its framing code
* The xml specification of the broker management object model
Note these are now duplicated and so if changed will need to be
updated in multiple places. In practice I expect this only to matter
for the version file, which is already effectively duplicated in
several (many?) places in the java tree.
The amqp 0-10 spec is effectively fixed anyway, and the broker
management schema seems only to be used in the C++ tree (although the
java broker must duplicate some of the effect even if it is not
actually generating code from the spec.)
I realise after tracking this down that you did comment in JIRA, but to
me this would have warranted at least a brief email direct to the list
(since JIRA comments are easy to miss, at least in my experience).
I think its a bad idea to have duplicated files. For the management spec
in particular this is bound to lead to confusion, especially since it
hasn't been clearly highlighted. I already spent some time trying to
figure out why changes to the spec had no effect.
The java broker no longer uses this. However I'm not sure whether the
Java based QMF API does?
If it does then having two separate copies is not in my view acceptable
and moving it without checking what works for the other component seems
unreasonable.
If it doesn't then I personally don't mind having this moved to the cpp
tree, but lets remove the other copy to avoid confusion.
--Gordon.
---------------------------------------------------------------------
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]
