You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Martin Ritchie <ri...@apache.org> on 2009/02/18 17:41:29 UTC
[Discussion] Release Artefacts
Hello,
I thought it best if we discuss what we are looking to release as
artefacts for the upcoming release.
Let me start with what I think we should be releasing with my reasons
and we can see what the general view is.
Starting with the source packages that we should be providing:
- C++
- C#
- Java (broker, client, common & testing)
- Java Management (all management components)
- Ruby
- Python
I believe that if we are providing source packages then they should
provide more value than a tar of the svn tree. Such is the case for
the C++ source that has had the framing already generated. I think the
frame generation should be performed for all of the source builds that
we provide this would mean that we do not need to bundle the various
generators and end users would have all the source they need. If a
user wanted to have control over the generated files then they can
download the tagged source version. I don't think mirroring a straight
svn export offers anything to an end user over the svn tag for the
release.
I am also suggesting that we split the Java AMQP implementation,
broker, client, common & tests from the Java management code as the
groups are distinct packages. Splitting the source down further to a
broker, client & common packages is not necessary.
In addition to the source packages we should also be providing binary
builds or at least access to builds of the components that we believe
are ready for use. I would also advocate that the packages we provide
should be of a useful unit to an end user. As such I would suggest the
following packages:
The current brokers should be shipped in the following packages:
- C++ with a link by supported platform (32/64bit)
+ Linux, (binary/rpm/link)
+ Windows (zip/link)
- Java (zip)
The brokers should be provided on their own without any other package
as that makes a useful package size for the following reasons:
1) Use of a Qpid broker with a client library that is not of the same
language or even a Qpid client
2) Upgrade of an existing Qpid broker, where clients are also not migrating.
3) Evaluation of Qpid brokers compared to other AMQP offerings.
Shipping the brokers on their own means that we can have discrete
client packages per language which allows them to be more readily used
with any AMQP broker.
Each of the clients (C++, DotNet, Java, Python, Ruby) could make up
two packages:
+ Client Libraries
+ Examples
I'd advocate the separation of library and examples as each package is
a useful package in its own right. I am more open here to persuasion
that this is unnecessary but thinking wider that just Qpid our clients
could be useful to all AMQP implementations. In these cases shipping
examples as a separate package makes sense to me.
Finally we have the management tools, apologies if I have missed a
tool from the list. Each of the tools should get their own package so
an end user can grab the tool they are interested in. Taking the steps
to make each of these tools a separate package opens the option for
them to release bug fixes in their own right without being tied to a
full release.
Management
- Eclipse JMX Console
+ Win
+ Linux
+ OS X
- JMX Command LIne Tool
- QMan
- WsDmAdapter
I'd like to get views from everyone in the project as it affects all
of the work we do and the way it is provided to the world. While it
may require a bit of effort to get the packages easily built for
release I think it is a worthwhile goal.
Cheers
Martin
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Aidan Skinner <ai...@apache.org>.
On Wed, Feb 18, 2009 at 4:41 PM, Martin Ritchie <ri...@apache.org> wrote:
> Starting with the source packages that we should be providing:
>
> - C++
> - C#
> - Java (broker, client, common & testing)
> - Java Management (all management components)
I don't think it makes sense to split the Java components by source.
> I believe that if we are providing source packages then they should
> provide more value than a tar of the svn tree. Such is the case for
> the C++ source that has had the framing already generated. I think the
> frame generation should be performed for all of the source builds that
> we provide this would mean that we do not need to bundle the various
> generators and end users would have all the source they need. If a
> user wanted to have control over the generated files then they can
> download the tagged source version. I don't think mirroring a straight
> svn export offers anything to an end user over the svn tag for the
> release.
Generating the C++ framing is rather onerous, since it adds a dep
(ruby?). Generating the java framing doesn't really add any pain.
> In addition to the source packages we should also be providing binary
> builds or at least access to builds of the components that we believe
> are ready for use. I would also advocate that the packages we provide
> should be of a useful unit to an end user. As such I would suggest the
> following packages:
> The current brokers should be shipped in the following packages:
> - C++ with a link by supported platform (32/64bit)
> + Linux, (binary/rpm/link)
> + Windows (zip/link)
I think it only makes sense for us to provide C++ binaries for
windows. Freenixen are better served by providing binaries in
downstream (eg. Fedora, OpenSUSE has ruby client packages). Java
binaries make sense becuase of WORA[1], and packaging Java is still a
PITA in a lot of places.
> Shipping the brokers on their own means that we can have discrete
> client packages per language which allows them to be more readily used
> with any AMQP broker.
> Each of the clients (C++, DotNet, Java, Python, Ruby) could make up
> two packages:
> + Client Libraries
> + Examples
Are we going to try shipping the client via maven again? I know it
would be useful for some users and it is, whatever your opinion, one
of the standard ways of distributing Java libs. I had a quick look at
using Ivy to manage our depedencies but got a bit ADD. It did look
like it would be able to do this pretty easily and without generating
network traffic.
- Aidan
[1] or WOTE, if you're feeling snarky
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Andrea Gazzarini <a....@gmail.com>.
Hi Martin,
"Management
- Eclipse JMX Console
+ Win
+ Linux
+ OS X
- JMX Command LIne Tool
- QMan
- WsDmAdapter"
I already started a discussion with Rajith (QPID-1619) about that
(moreless).
Concerning QMan artifacts I think that it would make sense to distribute
only one item : QMan :)
In fact, JMX Adapter (I think is "QMan" item in your list) is included in
WS-DM Adapter so IMO we could provide the whole bundle and let the users
choose what approach fits better their needs.
The whole archive is about 10M so I think it's not so big...
Regards,
Andrea
2009 /2/18 Rafael Schloming <ra...@redhat.com>
> Martin Ritchie wrote:
>
>> Hello,
>>
>> I thought it best if we discuss what we are looking to release as
>> artefacts for the upcoming release.
>>
>> Let me start with what I think we should be releasing with my reasons
>> and we can see what the general view is.
>>
>> Starting with the source packages that we should be providing:
>>
>> - C++
>> - C#
>> - Java (broker, client, common & testing)
>> - Java Management (all management components)
>> - Ruby
>> - Python
>>
>> I believe that if we are providing source packages then they should
>> provide more value than a tar of the svn tree. Such is the case for
>> the C++ source that has had the framing already generated. I think the
>> frame generation should be performed for all of the source builds that
>> we provide this would mean that we do not need to bundle the various
>> generators and end users would have all the source they need. If a
>> user wanted to have control over the generated files then they can
>> download the tagged source version. I don't think mirroring a straight
>> svn export offers anything to an end user over the svn tag for the
>> release.
>>
>
> Personally I don't think pre-generating the framing provides any value at
> all. In fact quite the opposite. If you apply a patch that modifies any of
> the templates and try to rebuild, you'll be in a world of hurt.
>
> I believe the reason the C++ source code includes pre-generated framing is
> actually to avoid adding a build dependency on ruby, but since the Java
> framing generator adds no external dependencies at all, I think it would be
> a step backwards to introduce what would essentially amount to a crippled
> source tarball.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [Discussion] Release Artefacts
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> Hello,
>
> I thought it best if we discuss what we are looking to release as
> artefacts for the upcoming release.
>
> Let me start with what I think we should be releasing with my reasons
> and we can see what the general view is.
>
> Starting with the source packages that we should be providing:
>
> - C++
> - C#
> - Java (broker, client, common & testing)
> - Java Management (all management components)
> - Ruby
> - Python
>
> I believe that if we are providing source packages then they should
> provide more value than a tar of the svn tree. Such is the case for
> the C++ source that has had the framing already generated. I think the
> frame generation should be performed for all of the source builds that
> we provide this would mean that we do not need to bundle the various
> generators and end users would have all the source they need. If a
> user wanted to have control over the generated files then they can
> download the tagged source version. I don't think mirroring a straight
> svn export offers anything to an end user over the svn tag for the
> release.
Personally I don't think pre-generating the framing provides any value
at all. In fact quite the opposite. If you apply a patch that modifies
any of the templates and try to rebuild, you'll be in a world of hurt.
I believe the reason the C++ source code includes pre-generated framing
is actually to avoid adding a build dependency on ruby, but since the
Java framing generator adds no external dependencies at all, I think it
would be a step backwards to introduce what would essentially amount to
a crippled source tarball.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Carl Trieloff <cc...@redhat.com>.
The management stuff only covers the Java list, is that the area you
want to clean up by implication
have not mentioned the other mgnt tools?
Carl.
>> Hello,
>>
>> I thought it best if we discuss what we are looking to release as
>> artefacts for the upcoming release.
>>
>> Let me start with what I think we should be releasing with my reasons
>> and we can see what the general view is.
>>
>> Starting with the source packages that we should be providing:
>>
>> - C++
>> - C#
>> - Java (broker, client, common & testing)
>> - Java Management (all management components)
>> - Ruby
>> - Python
>>
>> I believe that if we are providing source packages then they should
>> provide more value than a tar of the svn tree. Such is the case for
>> the C++ source that has had the framing already generated. I think the
>> frame generation should be performed for all of the source builds that
>> we provide this would mean that we do not need to bundle the various
>> generators and end users would have all the source they need. If a
>> user wanted to have control over the generated files then they can
>> download the tagged source version. I don't think mirroring a straight
>> svn export offers anything to an end user over the svn tag for the
>> release.
>>
>> I am also suggesting that we split the Java AMQP implementation,
>> broker, client, common & tests from the Java management code as the
>> groups are distinct packages. Splitting the source down further to a
>> broker, client & common packages is not necessary.
>>
>>
>> In addition to the source packages we should also be providing binary
>> builds or at least access to builds of the components that we believe
>> are ready for use. I would also advocate that the packages we provide
>> should be of a useful unit to an end user. As such I would suggest the
>> following packages:
>> The current brokers should be shipped in the following packages:
>> - C++ with a link by supported platform (32/64bit)
>> + Linux, (binary/rpm/link)
>> + Windows (zip/link)
>> - Java (zip)
>>
>> The brokers should be provided on their own without any other package
>> as that makes a useful package size for the following reasons:
>> 1) Use of a Qpid broker with a client library that is not of the same
>> language or even a Qpid client
>> 2) Upgrade of an existing Qpid broker, where clients are also not
>> migrating.
>> 3) Evaluation of Qpid brokers compared to other AMQP offerings.
>>
>> Shipping the brokers on their own means that we can have discrete
>> client packages per language which allows them to be more readily used
>> with any AMQP broker.
>> Each of the clients (C++, DotNet, Java, Python, Ruby) could make up
>> two packages:
>> + Client Libraries
>> + Examples
>>
>> I'd advocate the separation of library and examples as each package is
>> a useful package in its own right. I am more open here to persuasion
>> that this is unnecessary but thinking wider that just Qpid our clients
>> could be useful to all AMQP implementations. In these cases shipping
>> examples as a separate package makes sense to me.
>>
>> Finally we have the management tools, apologies if I have missed a
>> tool from the list. Each of the tools should get their own package so
>> an end user can grab the tool they are interested in. Taking the steps
>> to make each of these tools a separate package opens the option for
>> them to release bug fixes in their own right without being tied to a
>> full release.
>>
>> Management
>> - Eclipse JMX Console
>> + Win
>> + Linux
>> + OS X
>> - JMX Command LIne Tool
>> - QMan
>> - WsDmAdapter
>>
>>
>> I'd like to get views from everyone in the project as it affects all
>> of the work we do and the way it is provided to the world. While it
>> may require a bit of effort to get the packages easily built for
>> release I think it is a worthwhile goal.
>>
>> Cheers
>>
>> Martin
>>
>> --
>> Martin Ritchie
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>>
>
>
Re: [Discussion] Release Artefacts
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Martin,
Great to see this discussion kicking off.
I pretty much agree with your suggestions, with my main focus being the Java
packages. Our last rel shipped a truly vast one size fits all - I think what
you've proposed is far better for user experience.
Regards,
Marnie
On Wed, Feb 18, 2009 at 4:41 PM, Martin Ritchie <ri...@apache.org> wrote:
> Hello,
>
> I thought it best if we discuss what we are looking to release as
> artefacts for the upcoming release.
>
> Let me start with what I think we should be releasing with my reasons
> and we can see what the general view is.
>
> Starting with the source packages that we should be providing:
>
> - C++
> - C#
> - Java (broker, client, common & testing)
> - Java Management (all management components)
> - Ruby
> - Python
>
> I believe that if we are providing source packages then they should
> provide more value than a tar of the svn tree. Such is the case for
> the C++ source that has had the framing already generated. I think the
> frame generation should be performed for all of the source builds that
> we provide this would mean that we do not need to bundle the various
> generators and end users would have all the source they need. If a
> user wanted to have control over the generated files then they can
> download the tagged source version. I don't think mirroring a straight
> svn export offers anything to an end user over the svn tag for the
> release.
>
> I am also suggesting that we split the Java AMQP implementation,
> broker, client, common & tests from the Java management code as the
> groups are distinct packages. Splitting the source down further to a
> broker, client & common packages is not necessary.
>
>
> In addition to the source packages we should also be providing binary
> builds or at least access to builds of the components that we believe
> are ready for use. I would also advocate that the packages we provide
> should be of a useful unit to an end user. As such I would suggest the
> following packages:
> The current brokers should be shipped in the following packages:
> - C++ with a link by supported platform (32/64bit)
> + Linux, (binary/rpm/link)
> + Windows (zip/link)
> - Java (zip)
>
> The brokers should be provided on their own without any other package
> as that makes a useful package size for the following reasons:
> 1) Use of a Qpid broker with a client library that is not of the same
> language or even a Qpid client
> 2) Upgrade of an existing Qpid broker, where clients are also not
> migrating.
> 3) Evaluation of Qpid brokers compared to other AMQP offerings.
>
> Shipping the brokers on their own means that we can have discrete
> client packages per language which allows them to be more readily used
> with any AMQP broker.
> Each of the clients (C++, DotNet, Java, Python, Ruby) could make up
> two packages:
> + Client Libraries
> + Examples
>
> I'd advocate the separation of library and examples as each package is
> a useful package in its own right. I am more open here to persuasion
> that this is unnecessary but thinking wider that just Qpid our clients
> could be useful to all AMQP implementations. In these cases shipping
> examples as a separate package makes sense to me.
>
> Finally we have the management tools, apologies if I have missed a
> tool from the list. Each of the tools should get their own package so
> an end user can grab the tool they are interested in. Taking the steps
> to make each of these tools a separate package opens the option for
> them to release bug fixes in their own right without being tied to a
> full release.
>
> Management
> - Eclipse JMX Console
> + Win
> + Linux
> + OS X
> - JMX Command LIne Tool
> - QMan
> - WsDmAdapter
>
>
> I'd like to get views from everyone in the project as it affects all
> of the work we do and the way it is provided to the world. While it
> may require a bit of effort to get the packages easily built for
> release I think it is a worthwhile goal.
>
> Cheers
>
> Martin
>
> --
> Martin Ritchie
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: [Discussion] Release Artefacts
Posted by Steve Huston <sh...@riverace.com>.
Hi Robert,
> -----Original Message-----
> From: Robert Greig [mailto:robert.j.greig@gmail.com]
> Sent: Thursday, March 12, 2009 3:41 PM
> To: dev@qpid.apache.org
> Subject: Re: [Discussion] Release Artefacts
>
>
> 2009/3/11 Steve Huston <sh...@riverace.com>:
>
> > It's most likely to be one installer with optional components for
> > broker, client, examples, docs. Or something close to that.
>
> Are you going to use WiX?
That is the plan, yes.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Robert Greig <ro...@gmail.com>.
2009/3/11 Steve Huston <sh...@riverace.com>:
> It's most likely to be one installer with optional components for
> broker, client, examples, docs. Or something close to that.
Are you going to use WiX?
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Martin Ritchie <ri...@apache.org>.
2009/3/11 Carl Trieloff <cc...@redhat.com>:
>
>
> I think we should create a page for community built binaries, on this page
> we can link any non-apache signed builds.
> This could include
> - windows binaries
> - RPMs we build
> - I know some has built it for Umbatu etc
> - A Sun build, etc...
>
> Make is open so anyone can add links to builds of a specific Qpid release
>
> thoughts..
> Carl.
Exactly what I was thinking. Reminds me of other OS projects you've
got their main source/bin release then links to other binaries that
the community provide.
Where do the QMF command line tools get built? Would you be able to
get a script to package them up for distribution?
Cheers
Martin
>
> Martin Ritchie wrote:
>>
>> 2009/3/11 Steve Huston <sh...@riverace.com>:
>>
>>>
>>> Hi Martin,
>>>
>>> FYI, part of the work Microsoft is funding me to do is produce a
>>> prebuilt binary installer for M5. Where it will be offered from is not
>>> yet determined, but it can always be from riverace.com.
>>>
>>> -Steve
>>>
>>
>> Steve, That's great. What will the installer contain? Only Broker,
>> Broker+Client or two installers one for each?
>>
>> Cheers
>>
>>
>>>>
>>>> -----Original Message-----
>>>> From: martin.a.ritchie@googlemail.com
>>>> [mailto:martin.a.ritchie@googlemail.com] On Behalf Of Martin Ritchie
>>>> Sent: Wednesday, March 11, 2009 7:07 AM
>>>> To: dev@qpid.apache.org
>>>> Subject: Re: [Discussion] Release Artefacts
>>>>
>>>>
>>>> Thanks for everyone's input on this:
>>>>
>>>> Seems like we are all agreeing that more discreet packages
>>>> would be better.
>>>>
>>>> Just to summerise what everyone has said I believe these packages is
>>>> what everyone is looking for:
>>>>
>>>> A single source package for the source release as well as the cpp
>>>> source package that removes the build dependency on ruby. The
>>>>
>>>
>>> provided
>>>
>>>>
>>>> binaries would be split in to broker, client, examples and tools.
>>>>
>>>
>>> The
>>>
>>>>
>>>> C++ binaries that we actually build could be limited to Windows, as
>>>> downstream packagers will provide other builds we can link to. Each
>>>> client language should have their own package and an additional
>>>> example/documentation package. Finally we will have a set of
>>>>
>>>
>>> packages
>>>
>>>>
>>>> for the management tools from all languages. Carl, you mentioned
>>>>
>>>
>>> other
>>>
>>>>
>>>> C++ tools but on the wiki I only see details about QMF and QMan if
>>>>
>>>
>>> you
>>>
>>>>
>>>> let me know what the other items that we should package are I'll pop
>>>> them on the list here:
>>>>
>>>> - Single Source package
>>>> - C++ Source package
>>>> - Binary Packages for
>>>> + Brokers
>>>> + C++
>>>> - Windows only from Qpid, simply link to other downstream
>>>>
>>>
>>> binary
>>>
>>>>
>>>> builds for other platforms
>>>> + Java
>>>> + Client and Example Package
>>>> + C++
>>>> - Windows only from Qpid, simply link to other downstream
>>>>
>>>
>>> binary
>>>
>>>>
>>>> builds for other platforms
>>>> + C# (0-8,0-10)
>>>> + Java
>>>> + Python
>>>> + Ruby
>>>> + Management
>>>> - Eclipse JMX Console
>>>> + Win
>>>> + Linux
>>>> + OS X
>>>> - JMX Command Line Tool
>>>> - QMan / WsDmAdapter
>>>>
>>>>
>>>> Cheers
>>>>
>>>> Martin
>>>>
>>>> 2009/2/19 Steve Huston <sh...@riverace.com>:
>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Rajith Attapattu [mailto:rajith77@gmail.com]
>>>>>> ...
>>>>>> Binary distributions
>>>>>> ------------------------------------
>>>>>> +1 on having separate builds for brokers, clients and management
>>>>>>
>>>>>
>>>>> tools
>>>>>
>>>>>>
>>>>>> when ever it makes sense.
>>>>>> I have been advocating this for a while now.
>>>>>>
>>>>>> How ever as Aidan points out, for c++ its best we restrict our
>>>>>>
>>>>>
>>>>> selves
>>>>>
>>>>>>
>>>>>> to providing binaries for windows only.
>>>>>>
>>>>>
>>>>> I have funding to produce Windows installer in the M5 (or whatever
>>>>> it's called) timeframe. The contents and shape of that are
>>>>>
>>>>
>>>> not yet in
>>>>
>>>>>
>>>>> place, so I'm open to hearing what people think it should contain.
>>>>> I've been working under the assumption that it will have:
>>>>>
>>>>> - broker binary
>>>>> - built DLLs (broker, client, common)
>>>>> - qmfconsole
>>>>> - sources (complete, and those required for building apps)
>>>>> - doxygen-generated docs
>>>>>
>>>>> -Steve
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>>>>
>>>>> Apache Qpid - AMQP Messaging Implementation
>>>>> Project: http://qpid.apache.org
>>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Martin Ritchie
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>>>
>>>> Apache Qpid - AMQP Messaging Implementation
>>>> Project: http://qpid.apache.org
>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Carl Trieloff <cc...@redhat.com>.
I think we should create a page for community built binaries, on this page
we can link any non-apache signed builds.
This could include
- windows binaries
- RPMs we build
- I know some has built it for Umbatu etc
- A Sun build, etc...
Make is open so anyone can add links to builds of a specific Qpid release
thoughts..
Carl.
Martin Ritchie wrote:
> 2009/3/11 Steve Huston <sh...@riverace.com>:
>
>> Hi Martin,
>>
>> FYI, part of the work Microsoft is funding me to do is produce a
>> prebuilt binary installer for M5. Where it will be offered from is not
>> yet determined, but it can always be from riverace.com.
>>
>> -Steve
>>
>
> Steve, That's great. What will the installer contain? Only Broker,
> Broker+Client or two installers one for each?
>
> Cheers
>
>
>>> -----Original Message-----
>>> From: martin.a.ritchie@googlemail.com
>>> [mailto:martin.a.ritchie@googlemail.com] On Behalf Of Martin Ritchie
>>> Sent: Wednesday, March 11, 2009 7:07 AM
>>> To: dev@qpid.apache.org
>>> Subject: Re: [Discussion] Release Artefacts
>>>
>>>
>>> Thanks for everyone's input on this:
>>>
>>> Seems like we are all agreeing that more discreet packages
>>> would be better.
>>>
>>> Just to summerise what everyone has said I believe these packages is
>>> what everyone is looking for:
>>>
>>> A single source package for the source release as well as the cpp
>>> source package that removes the build dependency on ruby. The
>>>
>> provided
>>
>>> binaries would be split in to broker, client, examples and tools.
>>>
>> The
>>
>>> C++ binaries that we actually build could be limited to Windows, as
>>> downstream packagers will provide other builds we can link to. Each
>>> client language should have their own package and an additional
>>> example/documentation package. Finally we will have a set of
>>>
>> packages
>>
>>> for the management tools from all languages. Carl, you mentioned
>>>
>> other
>>
>>> C++ tools but on the wiki I only see details about QMF and QMan if
>>>
>> you
>>
>>> let me know what the other items that we should package are I'll pop
>>> them on the list here:
>>>
>>> - Single Source package
>>> - C++ Source package
>>> - Binary Packages for
>>> + Brokers
>>> + C++
>>> - Windows only from Qpid, simply link to other downstream
>>>
>> binary
>>
>>> builds for other platforms
>>> + Java
>>> + Client and Example Package
>>> + C++
>>> - Windows only from Qpid, simply link to other downstream
>>>
>> binary
>>
>>> builds for other platforms
>>> + C# (0-8,0-10)
>>> + Java
>>> + Python
>>> + Ruby
>>> + Management
>>> - Eclipse JMX Console
>>> + Win
>>> + Linux
>>> + OS X
>>> - JMX Command Line Tool
>>> - QMan / WsDmAdapter
>>>
>>>
>>> Cheers
>>>
>>> Martin
>>>
>>> 2009/2/19 Steve Huston <sh...@riverace.com>:
>>>
>>>>> -----Original Message-----
>>>>> From: Rajith Attapattu [mailto:rajith77@gmail.com]
>>>>> ...
>>>>> Binary distributions
>>>>> ------------------------------------
>>>>> +1 on having separate builds for brokers, clients and management
>>>>>
>>>> tools
>>>>
>>>>> when ever it makes sense.
>>>>> I have been advocating this for a while now.
>>>>>
>>>>> How ever as Aidan points out, for c++ its best we restrict our
>>>>>
>>>> selves
>>>>
>>>>> to providing binaries for windows only.
>>>>>
>>>> I have funding to produce Windows installer in the M5 (or whatever
>>>> it's called) timeframe. The contents and shape of that are
>>>>
>>> not yet in
>>>
>>>> place, so I'm open to hearing what people think it should contain.
>>>> I've been working under the assumption that it will have:
>>>>
>>>> - broker binary
>>>> - built DLLs (broker, client, common)
>>>> - qmfconsole
>>>> - sources (complete, and those required for building apps)
>>>> - doxygen-generated docs
>>>>
>>>> -Steve
>>>>
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>
>>>> Apache Qpid - AMQP Messaging Implementation
>>>> Project: http://qpid.apache.org
>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> Martin Ritchie
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>>
>
>
>
>
RE: [Discussion] Release Artefacts
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: martin.a.ritchie@googlemail.com
>
> 2009/3/11 Steve Huston <sh...@riverace.com>:
> > Hi Martin,
> >
> > FYI, part of the work Microsoft is funding me to do is produce a
> > prebuilt binary installer for M5. Where it will be offered
> from is not
> > yet determined, but it can always be from riverace.com.
> >
> > -Steve
>
> Steve, That's great. What will the installer contain? Only Broker,
> Broker+Client or two installers one for each?
It's most likely to be one installer with optional components for
broker, client, examples, docs. Or something close to that.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Martin Ritchie <ri...@apache.org>.
2009/3/11 Steve Huston <sh...@riverace.com>:
> Hi Martin,
>
> FYI, part of the work Microsoft is funding me to do is produce a
> prebuilt binary installer for M5. Where it will be offered from is not
> yet determined, but it can always be from riverace.com.
>
> -Steve
Steve, That's great. What will the installer contain? Only Broker,
Broker+Client or two installers one for each?
Cheers
>> -----Original Message-----
>> From: martin.a.ritchie@googlemail.com
>> [mailto:martin.a.ritchie@googlemail.com] On Behalf Of Martin Ritchie
>> Sent: Wednesday, March 11, 2009 7:07 AM
>> To: dev@qpid.apache.org
>> Subject: Re: [Discussion] Release Artefacts
>>
>>
>> Thanks for everyone's input on this:
>>
>> Seems like we are all agreeing that more discreet packages
>> would be better.
>>
>> Just to summerise what everyone has said I believe these packages is
>> what everyone is looking for:
>>
>> A single source package for the source release as well as the cpp
>> source package that removes the build dependency on ruby. The
> provided
>> binaries would be split in to broker, client, examples and tools.
> The
>> C++ binaries that we actually build could be limited to Windows, as
>> downstream packagers will provide other builds we can link to. Each
>> client language should have their own package and an additional
>> example/documentation package. Finally we will have a set of
> packages
>> for the management tools from all languages. Carl, you mentioned
> other
>> C++ tools but on the wiki I only see details about QMF and QMan if
> you
>> let me know what the other items that we should package are I'll pop
>> them on the list here:
>>
>> - Single Source package
>> - C++ Source package
>> - Binary Packages for
>> + Brokers
>> + C++
>> - Windows only from Qpid, simply link to other downstream
> binary
>> builds for other platforms
>> + Java
>> + Client and Example Package
>> + C++
>> - Windows only from Qpid, simply link to other downstream
> binary
>> builds for other platforms
>> + C# (0-8,0-10)
>> + Java
>> + Python
>> + Ruby
>> + Management
>> - Eclipse JMX Console
>> + Win
>> + Linux
>> + OS X
>> - JMX Command Line Tool
>> - QMan / WsDmAdapter
>>
>>
>> Cheers
>>
>> Martin
>>
>> 2009/2/19 Steve Huston <sh...@riverace.com>:
>> >> -----Original Message-----
>> >> From: Rajith Attapattu [mailto:rajith77@gmail.com]
>> >> ...
>> >> Binary distributions
>> >> ------------------------------------
>> >> +1 on having separate builds for brokers, clients and management
>> > tools
>> >> when ever it makes sense.
>> >> I have been advocating this for a while now.
>> >>
>> >> How ever as Aidan points out, for c++ its best we restrict our
>> > selves
>> >> to providing binaries for windows only.
>> >
>> > I have funding to produce Windows installer in the M5 (or whatever
>> > it's called) timeframe. The contents and shape of that are
>> not yet in
>> > place, so I'm open to hearing what people think it should contain.
>> > I've been working under the assumption that it will have:
>> >
>> > - broker binary
>> > - built DLLs (broker, client, common)
>> > - qmfconsole
>> > - sources (complete, and those required for building apps)
>> > - doxygen-generated docs
>> >
>> > -Steve
>> >
>> >
>> >
>>
> ---------------------------------------------------------------------
>> > Apache Qpid - AMQP Messaging Implementation
>> > Project: http://qpid.apache.org
>> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Martin Ritchie
>>
>>
> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Carl Trieloff <cc...@redhat.com>.
Martin Ritchie wrote:
> Thanks for everyone's input on this:
>
> Seems like we are all agreeing that more discreet packages would be better.
>
> Just to summerise what everyone has said I believe these packages is
> what everyone is looking for:
>
> A single source package for the source release as well as the cpp
> source package that removes the build dependency on ruby. The provided
> binaries would be split in to broker, client, examples and tools. The
> C++ binaries that we actually build could be limited to Windows, as
> downstream packagers will provide other builds we can link to. Each
> client language should have their own package and an additional
> example/documentation package. Finally we will have a set of packages
> for the management tools from all languages. Carl, you mentioned other
> C++ tools but on the wiki I only see details about QMF and QMan if you
> let me know what the other items that we should package are I'll pop
> them on the list here:
>
> - Single Source package
> - C++ Source package
> - Binary Packages for
> + Brokers
> + C++
> - Windows only from Qpid, simply link to other downstream binary
> builds for other platforms
> + Java
> + Client and Example Package
> + C++
> - Windows only from Qpid, simply link to other downstream binary
> builds for other platforms
> + C# (0-8,0-10)
> + Java
> + Python
> + Ruby
> + Management
> - Eclipse JMX Console
> + Win
> + Linux
> + OS X
> - JMX Command Line Tool
> - QMan / WsDmAdapter
The QMF command line tools are missing from the list
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [Discussion] Release Artefacts
Posted by Steve Huston <sh...@riverace.com>.
Hi Martin,
FYI, part of the work Microsoft is funding me to do is produce a
prebuilt binary installer for M5. Where it will be offered from is not
yet determined, but it can always be from riverace.com.
-Steve
> -----Original Message-----
> From: martin.a.ritchie@googlemail.com
> [mailto:martin.a.ritchie@googlemail.com] On Behalf Of Martin Ritchie
> Sent: Wednesday, March 11, 2009 7:07 AM
> To: dev@qpid.apache.org
> Subject: Re: [Discussion] Release Artefacts
>
>
> Thanks for everyone's input on this:
>
> Seems like we are all agreeing that more discreet packages
> would be better.
>
> Just to summerise what everyone has said I believe these packages is
> what everyone is looking for:
>
> A single source package for the source release as well as the cpp
> source package that removes the build dependency on ruby. The
provided
> binaries would be split in to broker, client, examples and tools.
The
> C++ binaries that we actually build could be limited to Windows, as
> downstream packagers will provide other builds we can link to. Each
> client language should have their own package and an additional
> example/documentation package. Finally we will have a set of
packages
> for the management tools from all languages. Carl, you mentioned
other
> C++ tools but on the wiki I only see details about QMF and QMan if
you
> let me know what the other items that we should package are I'll pop
> them on the list here:
>
> - Single Source package
> - C++ Source package
> - Binary Packages for
> + Brokers
> + C++
> - Windows only from Qpid, simply link to other downstream
binary
> builds for other platforms
> + Java
> + Client and Example Package
> + C++
> - Windows only from Qpid, simply link to other downstream
binary
> builds for other platforms
> + C# (0-8,0-10)
> + Java
> + Python
> + Ruby
> + Management
> - Eclipse JMX Console
> + Win
> + Linux
> + OS X
> - JMX Command Line Tool
> - QMan / WsDmAdapter
>
>
> Cheers
>
> Martin
>
> 2009/2/19 Steve Huston <sh...@riverace.com>:
> >> -----Original Message-----
> >> From: Rajith Attapattu [mailto:rajith77@gmail.com]
> >> ...
> >> Binary distributions
> >> ------------------------------------
> >> +1 on having separate builds for brokers, clients and management
> > tools
> >> when ever it makes sense.
> >> I have been advocating this for a while now.
> >>
> >> How ever as Aidan points out, for c++ its best we restrict our
> > selves
> >> to providing binaries for windows only.
> >
> > I have funding to produce Windows installer in the M5 (or whatever
> > it's called) timeframe. The contents and shape of that are
> not yet in
> > place, so I'm open to hearing what people think it should contain.
> > I've been working under the assumption that it will have:
> >
> > - broker binary
> > - built DLLs (broker, client, common)
> > - qmfconsole
> > - sources (complete, and those required for building apps)
> > - doxygen-generated docs
> >
> > -Steve
> >
> >
> >
>
---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
>
>
> --
> Martin Ritchie
>
>
---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Martin Ritchie <ri...@apache.org>.
Thanks for everyone's input on this:
Seems like we are all agreeing that more discreet packages would be better.
Just to summerise what everyone has said I believe these packages is
what everyone is looking for:
A single source package for the source release as well as the cpp
source package that removes the build dependency on ruby. The provided
binaries would be split in to broker, client, examples and tools. The
C++ binaries that we actually build could be limited to Windows, as
downstream packagers will provide other builds we can link to. Each
client language should have their own package and an additional
example/documentation package. Finally we will have a set of packages
for the management tools from all languages. Carl, you mentioned other
C++ tools but on the wiki I only see details about QMF and QMan if you
let me know what the other items that we should package are I'll pop
them on the list here:
- Single Source package
- C++ Source package
- Binary Packages for
+ Brokers
+ C++
- Windows only from Qpid, simply link to other downstream binary
builds for other platforms
+ Java
+ Client and Example Package
+ C++
- Windows only from Qpid, simply link to other downstream binary
builds for other platforms
+ C# (0-8,0-10)
+ Java
+ Python
+ Ruby
+ Management
- Eclipse JMX Console
+ Win
+ Linux
+ OS X
- JMX Command Line Tool
- QMan / WsDmAdapter
Cheers
Martin
2009/2/19 Steve Huston <sh...@riverace.com>:
>> -----Original Message-----
>> From: Rajith Attapattu [mailto:rajith77@gmail.com]
>> ...
>> Binary distributions
>> ------------------------------------
>> +1 on having separate builds for brokers, clients and management
> tools
>> when ever it makes sense.
>> I have been advocating this for a while now.
>>
>> How ever as Aidan points out, for c++ its best we restrict our
> selves
>> to providing binaries for windows only.
>
> I have funding to produce Windows installer in the M5 (or whatever
> it's called) timeframe. The contents and shape of that are not yet in
> place, so I'm open to hearing what people think it should contain.
> I've been working under the assumption that it will have:
>
> - broker binary
> - built DLLs (broker, client, common)
> - qmfconsole
> - sources (complete, and those required for building apps)
> - doxygen-generated docs
>
> -Steve
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [Discussion] Release Artefacts
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Rajith Attapattu [mailto:rajith77@gmail.com]
> ...
> Binary distributions
> ------------------------------------
> +1 on having separate builds for brokers, clients and management
tools
> when ever it makes sense.
> I have been advocating this for a while now.
>
> How ever as Aidan points out, for c++ its best we restrict our
selves
> to providing binaries for windows only.
I have funding to produce Windows installer in the M5 (or whatever
it's called) timeframe. The contents and shape of that are not yet in
place, so I'm open to hearing what people think it should contain.
I've been working under the assumption that it will have:
- broker binary
- built DLLs (broker, client, common)
- qmfconsole
- sources (complete, and those required for building apps)
- doxygen-generated docs
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Discussion] Release Artefacts
Posted by Rajith Attapattu <ra...@gmail.com>.
Martin,
Thanks for bringing this up for discussion.
Here are my two cents.
Source distributions
----------------------------
I am quite happy with the way the current source builds work.
I don't think we need to pre generate the framing code (allthough C++
does it to avoid a build dep on ruby).
>I believe that if we are providing source packages then they should
>provide more value than a tar of the svn tree.
I believe as per apache regulations, source builds should be an exact
tar/zip of the svn tree.
Also other packaging formats like RPM requires a pristine copy of the
source from where the binaries are built.
As rafi metioned you will have trouble with applying patches, should
the patch contains any modification to the templates.
I don't think spilting the source distribution in anyway is worth the
trouble. A source distribution should build as it is.
To dp that, we might have to meddle with the make files and build
files and this complication is not worth the trouble and adds no value
IMO.
Binary distributions
------------------------------------
+1 on having separate builds for brokers, clients and management tools
when ever it makes sense.
I have been advocating this for a while now.
How ever as Aidan points out, for c++ its best we restrict our selves
to providing binaries for windows only.
For the various linux flavours it would be best to allow the
respective communities to provide these binaries.
A huge +1 for providing a downloadable example package with some good
documentation.
To make it easy these examples should be source with clear
instructions on how to build them.
The current set of interoperable examples across all languages are the
best place to start.
Regards,
Rajith
On Wed, Feb 18, 2009 at 11:41 AM, Martin Ritchie <ri...@apache.org> wrote:
> Hello,
>
> I thought it best if we discuss what we are looking to release as
> artefacts for the upcoming release.
>
> Let me start with what I think we should be releasing with my reasons
> and we can see what the general view is.
>
> Starting with the source packages that we should be providing:
>
> - C++
> - C#
> - Java (broker, client, common & testing)
> - Java Management (all management components)
> - Ruby
> - Python
>
> I believe that if we are providing source packages then they should
> provide more value than a tar of the svn tree. Such is the case for
> the C++ source that has had the framing already generated. I think the
> frame generation should be performed for all of the source builds that
> we provide this would mean that we do not need to bundle the various
> generators and end users would have all the source they need. If a
> user wanted to have control over the generated files then they can
> download the tagged source version. I don't think mirroring a straight
> svn export offers anything to an end user over the svn tag for the
> release.
>
> I am also suggesting that we split the Java AMQP implementation,
> broker, client, common & tests from the Java management code as the
> groups are distinct packages. Splitting the source down further to a
> broker, client & common packages is not necessary.
>
>
> In addition to the source packages we should also be providing binary
> builds or at least access to builds of the components that we believe
> are ready for use. I would also advocate that the packages we provide
> should be of a useful unit to an end user. As such I would suggest the
> following packages:
> The current brokers should be shipped in the following packages:
> - C++ with a link by supported platform (32/64bit)
> + Linux, (binary/rpm/link)
> + Windows (zip/link)
> - Java (zip)
>
> The brokers should be provided on their own without any other package
> as that makes a useful package size for the following reasons:
> 1) Use of a Qpid broker with a client library that is not of the same
> language or even a Qpid client
> 2) Upgrade of an existing Qpid broker, where clients are also not migrating.
> 3) Evaluation of Qpid brokers compared to other AMQP offerings.
>
> Shipping the brokers on their own means that we can have discrete
> client packages per language which allows them to be more readily used
> with any AMQP broker.
> Each of the clients (C++, DotNet, Java, Python, Ruby) could make up
> two packages:
> + Client Libraries
> + Examples
>
> I'd advocate the separation of library and examples as each package is
> a useful package in its own right. I am more open here to persuasion
> that this is unnecessary but thinking wider that just Qpid our clients
> could be useful to all AMQP implementations. In these cases shipping
> examples as a separate package makes sense to me.
>
> Finally we have the management tools, apologies if I have missed a
> tool from the list. Each of the tools should get their own package so
> an end user can grab the tool they are interested in. Taking the steps
> to make each of these tools a separate package opens the option for
> them to release bug fixes in their own right without being tied to a
> full release.
>
> Management
> - Eclipse JMX Console
> + Win
> + Linux
> + OS X
> - JMX Command LIne Tool
> - QMan
> - WsDmAdapter
>
>
> I'd like to get views from everyone in the project as it affects all
> of the work we do and the way it is provided to the world. While it
> may require a bit of effort to get the packages easily built for
> release I think it is a worthwhile goal.
>
> Cheers
>
> Martin
>
> --
> Martin Ritchie
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org