You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2013/11/06 19:50:06 UTC
Copied QMF management spec
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Andrew Stitcher <as...@redhat.com>.
On Thu, 2013-11-07 at 18:40 +0000, Fraser Adams wrote:
> On 06/11/13 23:29, Andrew Stitcher wrote:
> > Fraser can you explicitly confirm that, and I will go and just do it.
> I'd be happy with that if it's OK with everyone else (though as I say a
> little README note to say where it has gone for the first release after
> it has been removed would probably be the friendly thing to do - and
> happy for that to be gone eventually too)
Ok, I will add a small "where's management_schema.xml gone" readme to
the specs directory as I delete the file from there.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 06/11/13 23:29, Andrew Stitcher wrote:
> On Wed, 2013-11-06 at 19:52 +0000, Fraser Adams wrote:
>
>> "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
> So from this answer I sense that the correct way to go is to remove the
> management_schema.xml from outside the cpp tree.
>
> Fraser can you explicitly confirm that, and I will go and just do it.
I'd be happy with that if it's OK with everyone else (though as I say a
little README note to say where it has gone for the first release after
it has been removed would probably be the friendly thing to do - and
happy for that to be gone eventually too)
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2013-11-06 at 19:52 +0000, Fraser Adams wrote:
> "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
So from this answer I sense that the correct way to go is to remove the
management_schema.xml from outside the cpp tree.
Fraser can you explicitly confirm that, and I will go and just do it.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 07/11/13 18:22, Justin Ross wrote:
> On Wed, Nov 6, 2013 at 2:52 PM, Fraser Adams
> <fr...@blueyonder.co.uk> wrote:
>> 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's from the cwiki infra change (see
> https://issues.apache.org/jira/browse/INFRA-6573). The stable URL:
>
> https://cwiki.apache.org/confluence/display/qpid/QMFv2+API+Proposal
>
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
Brilliant! thanks Justin
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Justin Ross <ju...@gmail.com>.
On Wed, Nov 6, 2013 at 2:52 PM, Fraser Adams
<fr...@blueyonder.co.uk> wrote:
> 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's from the cwiki infra change (see
https://issues.apache.org/jira/browse/INFRA-6573). The stable URL:
https://cwiki.apache.org/confluence/display/qpid/QMFv2+API+Proposal
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
"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: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Gordon Sim <gs...@redhat.com>.
On 11/07/2013 12:02 PM, Justin Ross wrote:
> On Thu, Nov 7, 2013 at 6:01 AM, Gordon Sim <gs...@redhat.com> wrote:
>> I'll note in passing that the python release pulls in the (AMQP) spec file
>> without needing it to be copied in svn.
>
> It does that by producing a sparse qpid/ archive:
>
> tar -czf artifacts/qpid-python-${VER}.tar.gz qpid-${VER}/python
> qpid-${VER}/specs
>
> As a result, the LICENSE and README files are not in the archive root.
> I think this is bad in general, and the qpid cpp artifact in
> particular has always had those files at the root.
That's a good point, and I agree that we want to keep things that way.
> In order to solve this problem and avoid copying the specs, we'd need
> to add a dist generation step, as we previously had with autotools.
Providing the management spec is moved, not copied, I could live with
copying the other two files.
No one should really be modifying the AMQP related files and if they did
its actually probably preferable that it doesn't affect all components
unless they explicitly chose to replicate the change. (That's assuming
functional changes of course).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Justin Ross <ju...@gmail.com>.
On Thu, Nov 7, 2013 at 6:01 AM, Gordon Sim <gs...@redhat.com> wrote:
> I'll note in passing that the python release pulls in the (AMQP) spec file
> without needing it to be copied in svn.
It does that by producing a sparse qpid/ archive:
tar -czf artifacts/qpid-python-${VER}.tar.gz qpid-${VER}/python
qpid-${VER}/specs
As a result, the LICENSE and README files are not in the archive root.
I think this is bad in general, and the qpid cpp artifact in
particular has always had those files at the root.
In order to solve this problem and avoid copying the specs, we'd need
to add a dist generation step, as we previously had with autotools.
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Gordon Sim <gs...@redhat.com>.
On 11/06/2013 11:25 PM, Andrew Stitcher wrote:
> On Wed, 2013-11-06 at 18:50 +0000, Gordon Sim wrote:
>> ...
>> 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).
>
> Apologies, I was under the impression that the management spec was
> *extremely* rarely changed.
Well, 10 times in 2013 so far and I have a pending change already on
review board... updates aren't frequent but it is continually evolving.
>> 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.
>
> I agree entirely.
>
>>
>> The java broker no longer uses this. However I'm not sure whether the
>> Java based QMF API does?
>
> I could find no references outside cpp to management-schema.xml, so I
> assume the file is not used elsewhere.
It seems that assumption is correct, in which case there is no point in
leaving the old copy there where its only purpose can be to cause confusion.
>> 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.
>
> That is why it was duplicated (Justin's preference).
I would argue duplication - especially without any discussion to make
people aware of the issue - would be the worst approach even if
something else was using it, since it would likely result in undetected
divergence of components that previously shared the same file.
>> 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.
>
> I agree, however it is impossible to have a self contained c++ tree at
> present without having this file in that tree.
I'll note in passing that the python release pulls in the (AMQP) spec
file without needing it to be copied in svn.
However, as far as the management spec goes it sounds like the cpp tree
might actually be the best place for it since that is the only component
left using it. Duplication of the other files is less serious perhaps.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Copied QMF management spec
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2013-11-06 at 18:50 +0000, Gordon Sim wrote:
> ...
> 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).
Apologies, I was under the impression that the management spec was
*extremely* rarely changed.
>
> 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.
I agree entirely.
>
> The java broker no longer uses this. However I'm not sure whether the
> Java based QMF API does?
I could find no references outside cpp to management-schema.xml, so I
assume the file is not used elsewhere.
>
> 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.
That is why it was duplicated (Justin's preference).
>
> 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.
I agree, however it is impossible to have a self contained c++ tree at
present without having this file in that tree.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org