You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Andrew Stitcher <as...@redhat.com> on 2009/12/03 01:53:30 UTC
First Qpid 0.6 Beta Release available for download and testing
Apologies for the long message, but there actually is a fair bit to say:
I've uploaded the artifacts for a 0.6 beta release to qpid.apache.org:
http://qpid.apache.org/dist/qpid-0.6beta1/
Please download and test this release. No, really, please download and
at least look at it.
I've called it a beta because, it seems to me in the area that I know (C
++) and in the currently outstanding bugs it seems very usable.
I plan that every one should give this a good beating for 1-2 weeks and
then I'll spin a release candidate, or if there are many problems found
and fixed a beta2.
So all being well I'd like to vote on releasing 0.6 in a couple of
weeks.
---
The status of this beta:
My testing has been building the C++ tar source under various linux
platforms (using this release or very slightly earlier ones).
Essentially "configure; make check".
Fedora 11/Fedora 12 (these both tested with the same results):
Autotools build is fine including all broker modules. It doesn't seem
that the build as it stands in the C++ source release builds the qmf
bindings.
Cmake build is mostly fine - however the clustering module doesn't build
due to a complication of recent versions of boost. And r886259 breaks
building the clustering tests (due to missing the new
tests/cluster.cmake from EXTRA_DIST)
Red Hat Enterprise Linux 5:
Autotools builds fine.
Cmake builds fine (but this was a slightly earlier release and this
would have been broken by r886259 as above).
Debian 5 (lenny).
Neither the clustering module nor the XML module have their necessary
prerequisites so can't be built here.
Given this both autotools and cmake builds were fine.
---
Overall Release Status:
I've put up a page for the release on the wiki:
http://cwiki.apache.org/confluence/display/qpid/0.6+Release
(don't use the mirror on qpid.apache.org as it won't have the
dynamically updated bug list)
Please edit the release page to add your understanding to it - it's a
little biased to the areas that I know about presently.
One area that needs attention is the Release notes, I appeal to you to
add any release notes to that wiki page and I will turn them into
something to put in the release itself. Otherwise the only release notes
will be for the C++ code and whatever I can get from the 0.6 fixed bugs.
---
Deficiencies:
I've removed the separate dotnet package from the release as it doesn't
build for me using the release script. More about this separately.
I've not packaged the wcf code separately as I've no idea how it should
look and I doubt I could build it under Linux anyway.
I'm concerned there appear to be 5 13Mb eclipse plugins labelled for
various platforms - is this really necessary - it certainly took a long
time to upload and constitutes a large amount of space.
---
At this point I suggest that any bugs important enough to be fixed
before the 0.6 release should be tagged with "Fix version" 0.6 and be a
blocker or critical.
So if you find an issue that must be fixed before release then put it in
Jira like this.
Conversely if you know of a bug that is in this state that can be
resolved then resolve it poste haste.
I will assume that as long as there *any* bugs like this 0.6 release is
blocked.
Regards
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: First Qpid 0.6 Beta Release available for download and testing
Posted by Alan Conway <ac...@redhat.com>.
On 12/02/2009 07:53 PM, Andrew Stitcher wrote:
> Apologies for the long message, but there actually is a fair bit to say:
>
> I've uploaded the artifacts for a 0.6 beta release to qpid.apache.org:
>
> http://qpid.apache.org/dist/qpid-0.6beta1/
>
> Please download and test this release. No, really, please download and
> at least look at it.
>
Kicked the tires on RHEL5, no problem with the following:
- automake built & tested the c++ subdir of the big source package tarball.
- automake built, tested & installed cpp distro
- cmake built & tested cpp distro (after copying tests/cluster.cmake to
work-around the known & fixed cmake build problem)
- ran a cluster from the install
- built the installed examples, ran direct example against cluster.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
Posted by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>.
Andrew Stitcher wrote:
> I've not packaged the wcf code separately as I've no idea how it
> should look and I doubt I could build it under Linux anyway.
I will take a look at it ASAP and get you what you need.
Cliff
Re: First Qpid 0.6 Beta Release available for download and testing
Posted by Alan Conway <ac...@redhat.com>.
On 12/07/2009 11:04 AM, Andrew Stitcher wrote:
> On Mon, 2009-12-07 at 10:28 -0500, Alan Conway wrote:
>> On 12/04/2009 12:20 PM, Andrew Stitcher wrote:
>>> On Fri, 2009-12-04 at 11:07 -0500, Alan Conway wrote:
>>>> ...On 12/02/2009 07:53 PM, Andrew Stitcher wrote:
>>>>
>>>>> Cmake build is mostly fine - however the clustering module doesn't build
>>>>> due to a complication of recent versions of boost.
>>>>
>>>> The cluster& cluster test build& pass for me on f11 with
>>>> boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there a machine I can
>>>> log into where you see the problem?
>>>
>>> In response - I don't understand how you can be building this! The
>>> StoreStatus.o has references to symbols that are only in libboost_system
>>> but it's not directly linked. However having said this I also can't
>>> understand why the autotools build does work by the same token - it's a
>>> bit of a mystery!
>>>
>>
>> ldd shows that in my build cluster.so is indeed linked with boost_system-mt.
>>
>> [aconway@rolf cmake]$ ldd src/cluster.so | grep boost
>> libboost_filesystem-mt.so.4 => /usr/lib64/libboost_filesystem-mt.so.4
>> (0x00007f1d97f67000)
>> libboost_program_options-mt.so.4 =>
>> /usr/lib64/libboost_program_options-mt.so.4 (0x00007f1d978ac000)
>> libboost_system-mt.so.4 => /usr/lib64/libboost_system-mt.so.4
>> (0x00007f1d95f44000)
>>
>> Also note that libcommon uses boost::filesystem and links without problems,
>> although perhaps StoreStatus is using different symbols. What missing symbols
>> are you seeing?
>
> Ok, I haven't explained in enough detail:
>
> libqpidcommon isn't a problem because by default shared objects are
> allowed to have unresolved symbols at link time on the Unix systems I
> know - if they weren't resolved at the run time load you'd get an error
> - generally sigkill to the process.
>
> ldd doesn't tell you what you need to know here as it gives the
> transitive linkage - ie in this case libboost_system is loaded because
> libboost_filesystem requires it. To get the actual (non transitive)
> requires of an object you need to use objdump -p.
>
> When we build plugin modules for qpid we tell the linker to give an
> error if it finds unresolved symbols when linking against the non
> transitive requirements (--no-undefined to the linker -Wl,--no-undefined
> to the compiler). It's possible that libtool adds another option to make
> it check the symbols transitively, which would explain why the autotools
> build works, but I can't see why your cmake build could be different
> from mine.
My cmake build does not have those flags in the link line for cluster.so:
/usr/bin/ccache /usr/bin/distcc g++ -fPIC -g -O -shared
-Wl,-soname,cluster.so -o cluster.so
CMakeFiles/cluster.dir/qpid/cluster/Quorum_cman.o
CMakeFiles/cluster.dir/qpid/cluster/Cluster.o
CMakeFiles/cluster.dir/qpid/cluster/Decoder.o
CMakeFiles/cluster.dir/qpid/cluster/ClusterMap.o
CMakeFiles/cluster.dir/qpid/cluster/ClusterPlugin.o
CMakeFiles/cluster.dir/qpid/cluster/Connection.o
CMakeFiles/cluster.dir/qpid/cluster/ConnectionCodec.o
CMakeFiles/cluster.dir/qpid/cluster/Cpg.o
CMakeFiles/cluster.dir/qpid/cluster/UpdateClient.o
CMakeFiles/cluster.dir/qpid/cluster/RetractClient.o
CMakeFiles/cluster.dir/qpid/cluster/ErrorCheck.o
CMakeFiles/cluster.dir/qpid/cluster/Event.o
CMakeFiles/cluster.dir/qpid/cluster/EventFrame.o
CMakeFiles/cluster.dir/qpid/cluster/ExpiryPolicy.o
CMakeFiles/cluster.dir/qpid/cluster/FailoverExchange.o
CMakeFiles/cluster.dir/qpid/cluster/Multicaster.o
CMakeFiles/cluster.dir/qpid/cluster/OutputInterceptor.o
CMakeFiles/cluster.dir/qpid/cluster/PollerDispatch.o
CMakeFiles/cluster.dir/qpid/cluster/InitialStatusMap.o
CMakeFiles/cluster.dir/qpid/cluster/MemberSet.o
CMakeFiles/cluster.dir/qpid/cluster/StoreStatus.o -lcpg -lcman
libqpidbroker.so.0.6 libqpidclient.so.0.6 -lboost_filesystem-mt
libqpidcommon.so.0.6 -lboost_program_options-mt -lboost_filesystem-mt -luuid
-ldl -lrt -lsasl2 -Wl,-rpath,/home/aconway/qpid/qpid/cmake/src
I don't know why those flags aren't present, maybe something wrong with the
CMAKE_COMPILER_IS_GNUCXX that's causing it to fail on my box? How can I debug
what cmake is doing here?
> The symbols that are unresolved in all of the shared objects that use
> boost_filesystem due to inline expansions of things from it are:
> U boost::system::get_system_category()
> U boost::system::get_generic_category()
Yep, they're undefined for me as well but not causing a compile error due to the
missing flags. I'm still not clear on what the solution is here:
- drop the --no-undefined-flags
- explicitly link with boost system if present
We could drop the --no-undefined flag for cluster.so only as a workaround if
linking with boost system is tricky.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: First Qpid 0.6 Beta Release available for download and testing
Posted by Andrew Stitcher <as...@redhat.com>.
On Mon, 2009-12-07 at 10:28 -0500, Alan Conway wrote:
> On 12/04/2009 12:20 PM, Andrew Stitcher wrote:
> > On Fri, 2009-12-04 at 11:07 -0500, Alan Conway wrote:
> >> ...On 12/02/2009 07:53 PM, Andrew Stitcher wrote:
> >>
> >>> Cmake build is mostly fine - however the clustering module doesn't build
> >>> due to a complication of recent versions of boost.
> >>
> >> The cluster& cluster test build& pass for me on f11 with
> >> boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there a machine I can
> >> log into where you see the problem?
> >
> > In response - I don't understand how you can be building this! The
> > StoreStatus.o has references to symbols that are only in libboost_system
> > but it's not directly linked. However having said this I also can't
> > understand why the autotools build does work by the same token - it's a
> > bit of a mystery!
> >
>
> ldd shows that in my build cluster.so is indeed linked with boost_system-mt.
>
> [aconway@rolf cmake]$ ldd src/cluster.so | grep boost
> libboost_filesystem-mt.so.4 => /usr/lib64/libboost_filesystem-mt.so.4
> (0x00007f1d97f67000)
> libboost_program_options-mt.so.4 =>
> /usr/lib64/libboost_program_options-mt.so.4 (0x00007f1d978ac000)
> libboost_system-mt.so.4 => /usr/lib64/libboost_system-mt.so.4
> (0x00007f1d95f44000)
>
> Also note that libcommon uses boost::filesystem and links without problems,
> although perhaps StoreStatus is using different symbols. What missing symbols
> are you seeing?
Ok, I haven't explained in enough detail:
libqpidcommon isn't a problem because by default shared objects are
allowed to have unresolved symbols at link time on the Unix systems I
know - if they weren't resolved at the run time load you'd get an error
- generally sigkill to the process.
ldd doesn't tell you what you need to know here as it gives the
transitive linkage - ie in this case libboost_system is loaded because
libboost_filesystem requires it. To get the actual (non transitive)
requires of an object you need to use objdump -p.
When we build plugin modules for qpid we tell the linker to give an
error if it finds unresolved symbols when linking against the non
transitive requirements (--no-undefined to the linker -Wl,--no-undefined
to the compiler). It's possible that libtool adds another option to make
it check the symbols transitively, which would explain why the autotools
build works, but I can't see why your cmake build could be different
from mine.
The symbols that are unresolved in all of the shared objects that use
boost_filesystem due to inline expansions of things from it are:
U boost::system::get_system_category()
U boost::system::get_generic_category()
Regards
Andrew
>
> ---------------------------------------------------------------------
> 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: First Qpid 0.6 Beta Release available for download and testing
Posted by Alan Conway <ac...@redhat.com>.
On 12/04/2009 12:20 PM, Andrew Stitcher wrote:
> On Fri, 2009-12-04 at 11:07 -0500, Alan Conway wrote:
>> ...On 12/02/2009 07:53 PM, Andrew Stitcher wrote:
>>
>>> Cmake build is mostly fine - however the clustering module doesn't build
>>> due to a complication of recent versions of boost.
>>
>> The cluster& cluster test build& pass for me on f11 with
>> boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there a machine I can
>> log into where you see the problem?
>
> In response - I don't understand how you can be building this! The
> StoreStatus.o has references to symbols that are only in libboost_system
> but it's not directly linked. However having said this I also can't
> understand why the autotools build does work by the same token - it's a
> bit of a mystery!
>
ldd shows that in my build cluster.so is indeed linked with boost_system-mt.
[aconway@rolf cmake]$ ldd src/cluster.so | grep boost
libboost_filesystem-mt.so.4 => /usr/lib64/libboost_filesystem-mt.so.4
(0x00007f1d97f67000)
libboost_program_options-mt.so.4 =>
/usr/lib64/libboost_program_options-mt.so.4 (0x00007f1d978ac000)
libboost_system-mt.so.4 => /usr/lib64/libboost_system-mt.so.4
(0x00007f1d95f44000)
Also note that libcommon uses boost::filesystem and links without problems,
although perhaps StoreStatus is using different symbols. What missing symbols
are you seeing?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: First Qpid 0.6 Beta Release available for download and testing
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2009-12-04 at 11:07 -0500, Alan Conway wrote:
> ...On 12/02/2009 07:53 PM, Andrew Stitcher wrote:
>
> > Cmake build is mostly fine - however the clustering module doesn't build
> > due to a complication of recent versions of boost.
>
> The cluster & cluster test build & pass for me on f11 with
> boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there a machine I can
> log into where you see the problem?
In response - I don't understand how you can be building this! The
StoreStatus.o has references to symbols that are only in libboost_system
but it's not directly linked. However having said this I also can't
understand why the autotools build does work by the same token - it's a
bit of a mystery!
>
> > And r886259 breaks
> > building the clustering tests (due to missing the new
> > tests/cluster.cmake from EXTRA_DIST)
>
> I think you already fixed this in 886779 - is there still an issue to resolve?
Yes fixed.
A
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2009-12-04 at 11:53 -0500, Steve Huston wrote:
> > -----Original Message-----
> > From: Alan Conway [mailto:aconway@redhat.com]
> > Sent: Friday, December 04, 2009 11:07 AM
> > To: dev@qpid.apache.org; Andrew Stitcher
> > Subject: Re: First Qpid 0.6 Beta Release available for
> > download and testing
> >
> >
> > On 12/02/2009 07:53 PM, Andrew Stitcher wrote:
> >
> > > Cmake build is mostly fine - however the clustering module
> > doesn't build
> > > due to a complication of recent versions of boost.
> >
> > The cluster & cluster test build & pass for me on f11 with
> > boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there
> > a machine I can
> > log into where you see the problem?
>
> It's probably this:
> https://issues.apache.org/jira/browse/QPID-2202
It's related to this in that it's symbols from boost::filesystem which
aren't found. However the details of Unix and Windows linking are
different enough that the bugs can't be related (essentially because the
dll linking under windows is driven from the header files, but that
isn't possible under Unix).
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Alan Conway [mailto:aconway@redhat.com]
> Sent: Friday, December 04, 2009 11:07 AM
> To: dev@qpid.apache.org; Andrew Stitcher
> Subject: Re: First Qpid 0.6 Beta Release available for
> download and testing
>
>
> On 12/02/2009 07:53 PM, Andrew Stitcher wrote:
>
> > Cmake build is mostly fine - however the clustering module
> doesn't build
> > due to a complication of recent versions of boost.
>
> The cluster & cluster test build & pass for me on f11 with
> boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there
> a machine I can
> log into where you see the problem?
It's probably this:
https://issues.apache.org/jira/browse/QPID-2202
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: First Qpid 0.6 Beta Release available for download and testing
Posted by Alan Conway <ac...@redhat.com>.
On 12/02/2009 07:53 PM, Andrew Stitcher wrote:
> Cmake build is mostly fine - however the clustering module doesn't build
> due to a complication of recent versions of boost.
The cluster & cluster test build & pass for me on f11 with
boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there a machine I can
log into where you see the problem?
> And r886259 breaks
> building the clustering tests (due to missing the new
> tests/cluster.cmake from EXTRA_DIST)
I think you already fixed this in 886779 - is there still an issue to resolve?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: First Qpid 0.6 Beta Release available for download and testing
Posted by Martin Ritchie <ri...@apache.org>.
Hi Andrew,
I've updated the 0.6 Relese page with another JIRA filter showing all
other unresolved JIRAs tagged Fix For : 0.6. These should be resolved
or migrated to Affects 0.6 and the fix for cleared.
http://cwiki.apache.org/confluence/display/qpid/0.6+Release
Martin
2009/12/3 Robbie Gemmell <ro...@gmail.com>:
> The reason there are multiple 'eclipse-plugin' artifacts is that it
> isnt actually just an Eclipse plugin, but actually a full Eclipse RCP
> application and the launcher and SWT code for these is platform
> specific. The artifacts are generated from the
> management/eclipse-plugin module, which is just an Eclipse RCP plugin,
> hence its name.
>
> I know this has also confused for a couple of users in the past, so I
> would be in favour of updating the release artifact names, Eg:
> qpid-jmx-management-console-0.6-linux-gtk-x86.tar.gz instead of
> qpid-management-eclipse-plugin-0.6-linux-gtk-x86.tar.gz
>
> What do people think?
>
> Robbie
>
> 2009/12/3 Andrew Stitcher <as...@redhat.com>:
>
> <snip>
>
>> Deficiencies:
>>
>> I've removed the separate dotnet package from the release as it doesn't
>> build for me using the release script. More about this separately.
>>
>> I've not packaged the wcf code separately as I've no idea how it should
>> look and I doubt I could build it under Linux anyway.
>>
>> I'm concerned there appear to be 5 13Mb eclipse plugins labelled for
>> various platforms - is this really necessary - it certainly took a long
>> time to upload and constitutes a large amount of space.
>>
>
> </snip>
>
> ---------------------------------------------------------------------
> 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: First Qpid 0.6 Beta Release available for download and testing
Posted by Robbie Gemmell <ro...@gmail.com>.
The reason there are multiple 'eclipse-plugin' artifacts is that it
isnt actually just an Eclipse plugin, but actually a full Eclipse RCP
application and the launcher and SWT code for these is platform
specific. The artifacts are generated from the
management/eclipse-plugin module, which is just an Eclipse RCP plugin,
hence its name.
I know this has also confused for a couple of users in the past, so I
would be in favour of updating the release artifact names, Eg:
qpid-jmx-management-console-0.6-linux-gtk-x86.tar.gz instead of
qpid-management-eclipse-plugin-0.6-linux-gtk-x86.tar.gz
What do people think?
Robbie
2009/12/3 Andrew Stitcher <as...@redhat.com>:
<snip>
> Deficiencies:
>
> I've removed the separate dotnet package from the release as it doesn't
> build for me using the release script. More about this separately.
>
> I've not packaged the wcf code separately as I've no idea how it should
> look and I doubt I could build it under Linux anyway.
>
> I'm concerned there appear to be 5 13Mb eclipse plugins labelled for
> various platforms - is this really necessary - it certainly took a long
> time to upload and constitutes a large amount of space.
>
</snip>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
Posted by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>.
> Another thing I have noticed is that there is no WCF component
> artifact in the beta build, is that something we plan to release with
> 0.6?
Yes. I contacted Andrew about this yesterday. JIRA coming soon.
Cliff
-----Original Message-----
From: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
Sent: Thursday, December 10, 2009 6:15 AM
To: dev@qpid.apache.org
Subject: RE: First Qpid 0.6 Beta Release available for download and testing
I have updated the release script to set the SVN version as a property on the Ant command line and modified the ant build scripts as mentioned below. I Also updated some straggling version numbers in the Java tree for the 0.6 release.
Another thing I have noticed is that there is no WCF component artifact in the beta build, is that something we plan to release with 0.6?
Robbie
> -----Original Message-----
> From: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
> Sent: 09 December 2009 22:42
> To: dev@qpid.apache.org
> Subject: RE: First Qpid 0.6 Beta Release available for download and
> testing
>
> You are indeed correct. I didn't actually look at the script before
> mentioning it as I just presumed it was the Git addition that did it
> hehe. Oh well, still needs fixing :)
>
> I'll look at it tomorrow, shouldn't take long to add a property check.
> I'll probably standardise the different areas that doo it too as I
> think they do it independently and slightly differently, and I recall
> there being an issue whereby if you dont actually have the svnversion
> command on your path Ant encounters an infinite loop property
> definition and refuses to build a second time ;)
>
> Robbie
>
> > -----Original Message-----
> > From: Andrew Stitcher [mailto:astitcher@redhat.com]
> > Sent: 09 December 2009 22:24
> > To: dev@qpid.apache.org
> > Subject: RE: First Qpid 0.6 Beta Release available for download and
> > testing
> >
> > On Wed, 2009-12-09 at 22:01 +0000, Robbie Gemmell wrote:
> > > No that explains it, it's just the same effect as using git would
> > have caused, I just assumed since you added that... :)
> > >
> > > By using svn export you don't get the .svn/ metadata directories
> > within each directory, and so svnversion cant detect the version when
> > run and assumes it was exported (which in this case, it actually
> was).
> > >
> > > I will have a look at updating the Ant scripting to allow
> specifying
> > the revision to handle this.
> >
> > FWIW in that case this isn't a regression as I believe previous
> > releases
> > were produced using svn export also.
> >
> > A
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: First Qpid 0.6 Beta Release available for download and testing
Posted by Robbie Gemmell <ro...@gmail.com>.
I have updated the release script to set the SVN version as a property on the Ant command line and modified the ant build scripts as mentioned below. I Also updated some straggling version numbers in the Java tree for the 0.6 release.
Another thing I have noticed is that there is no WCF component artifact in the beta build, is that something we plan to release with 0.6?
Robbie
> -----Original Message-----
> From: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
> Sent: 09 December 2009 22:42
> To: dev@qpid.apache.org
> Subject: RE: First Qpid 0.6 Beta Release available for download and
> testing
>
> You are indeed correct. I didn't actually look at the script before
> mentioning it as I just presumed it was the Git addition that did it
> hehe. Oh well, still needs fixing :)
>
> I'll look at it tomorrow, shouldn't take long to add a property check.
> I'll probably standardise the different areas that doo it too as I
> think they do it independently and slightly differently, and I recall
> there being an issue whereby if you dont actually have the svnversion
> command on your path Ant encounters an infinite loop property
> definition and refuses to build a second time ;)
>
> Robbie
>
> > -----Original Message-----
> > From: Andrew Stitcher [mailto:astitcher@redhat.com]
> > Sent: 09 December 2009 22:24
> > To: dev@qpid.apache.org
> > Subject: RE: First Qpid 0.6 Beta Release available for download and
> > testing
> >
> > On Wed, 2009-12-09 at 22:01 +0000, Robbie Gemmell wrote:
> > > No that explains it, it's just the same effect as using git would
> > have caused, I just assumed since you added that... :)
> > >
> > > By using svn export you don't get the .svn/ metadata directories
> > within each directory, and so svnversion cant detect the version when
> > run and assumes it was exported (which in this case, it actually
> was).
> > >
> > > I will have a look at updating the Ant scripting to allow
> specifying
> > the revision to handle this.
> >
> > FWIW in that case this isn't a regression as I believe previous
> > releases
> > were produced using svn export also.
> >
> > A
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: First Qpid 0.6 Beta Release available for download and testing
Posted by Robbie Gemmell <ro...@gmail.com>.
You are indeed correct. I didn't actually look at the script before mentioning it as I just presumed it was the Git addition that did it hehe. Oh well, still needs fixing :)
I'll look at it tomorrow, shouldn't take long to add a property check. I'll probably standardise the different areas that doo it too as I think they do it independently and slightly differently, and I recall there being an issue whereby if you dont actually have the svnversion command on your path Ant encounters an infinite loop property definition and refuses to build a second time ;)
Robbie
> -----Original Message-----
> From: Andrew Stitcher [mailto:astitcher@redhat.com]
> Sent: 09 December 2009 22:24
> To: dev@qpid.apache.org
> Subject: RE: First Qpid 0.6 Beta Release available for download and
> testing
>
> On Wed, 2009-12-09 at 22:01 +0000, Robbie Gemmell wrote:
> > No that explains it, it's just the same effect as using git would
> have caused, I just assumed since you added that... :)
> >
> > By using svn export you don't get the .svn/ metadata directories
> within each directory, and so svnversion cant detect the version when
> run and assumes it was exported (which in this case, it actually was).
> >
> > I will have a look at updating the Ant scripting to allow specifying
> the revision to handle this.
>
> FWIW in that case this isn't a regression as I believe previous
> releases
> were produced using svn export also.
>
> A
>
>
>
> ---------------------------------------------------------------------
> 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: First Qpid 0.6 Beta Release available for download and testing
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2009-12-09 at 22:01 +0000, Robbie Gemmell wrote:
> No that explains it, it's just the same effect as using git would have caused, I just assumed since you added that... :)
>
> By using svn export you don't get the .svn/ metadata directories within each directory, and so svnversion cant detect the version when run and assumes it was exported (which in this case, it actually was).
>
> I will have a look at updating the Ant scripting to allow specifying the revision to handle this.
FWIW in that case this isn't a regression as I believe previous releases
were produced using svn export also.
A
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
Posted by Robbie Gemmell <ro...@gmail.com>.
No that explains it, it's just the same effect as using git would have caused, I just assumed since you added that... :)
By using svn export you don't get the .svn/ metadata directories within each directory, and so svnversion cant detect the version when run and assumes it was exported (which in this case, it actually was).
I will have a look at updating the Ant scripting to allow specifying the revision to handle this.
Robbie
> -----Original Message-----
> From: Andrew Stitcher [mailto:astitcher@redhat.com]
> Sent: 09 December 2009 21:55
> To: dev@qpid.apache.org
> Subject: RE: First Qpid 0.6 Beta Release available for download and
> testing
>
> On Wed, 2009-12-09 at 20:36 +0000, Robbie Gemmell wrote:
> > I have updated (r888939) the build process to and release script so
> the QMan package is generated and copied over.
> >
> > Additionally, I have noticed that because you are using Git
> (presumably, since the ability was added recently) to do the checkout
> the Java modules are failing to identify the SVN revision used in the
> build and so are generating property files that contain "exported"
> where the revision should be, since svnversion didnt find the .svn
> folders. As a result, "exported" will show up wherever the revision
> would normally be mentioned, eg broker startup.
> >
>
> The actual released artifacts were produced from an svn export, not git
> - that was for convenience leading up to a final release as "svn
> export"
> is slow because it needs to go over the internet.
>
> So that doesn't explain this (unless I've made a mistake).
>
> Andrew
>
> > One way to handle this would be to add a property in the ant build
> process that can be set via command line in the release script with the
> value parsed from Git, and modify the build process to only use
> svnversion to figure it out the revision if that hasn't been set.
>
> That's certainly not in my skill set re java, I'm just about capable of
> running release.sh and seeing whether java built!
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> 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: First Qpid 0.6 Beta Release available for download and testing
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2009-12-09 at 20:36 +0000, Robbie Gemmell wrote:
> I have updated (r888939) the build process to and release script so the QMan package is generated and copied over.
>
> Additionally, I have noticed that because you are using Git (presumably, since the ability was added recently) to do the checkout the Java modules are failing to identify the SVN revision used in the build and so are generating property files that contain "exported" where the revision should be, since svnversion didnt find the .svn folders. As a result, "exported" will show up wherever the revision would normally be mentioned, eg broker startup.
>
The actual released artifacts were produced from an svn export, not git
- that was for convenience leading up to a final release as "svn export"
is slow because it needs to go over the internet.
So that doesn't explain this (unless I've made a mistake).
Andrew
> One way to handle this would be to add a property in the ant build process that can be set via command line in the release script with the value parsed from Git, and modify the build process to only use svnversion to figure it out the revision if that hasn't been set.
That's certainly not in my skill set re java, I'm just about capable of
running release.sh and seeing whether java built!
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
Posted by Robbie Gemmell <ro...@gmail.com>.
I have updated (r888939) the build process to and release script so the QMan package is generated and copied over.
Additionally, I have noticed that because you are using Git (presumably, since the ability was added recently) to do the checkout the Java modules are failing to identify the SVN revision used in the build and so are generating property files that contain "exported" where the revision should be, since svnversion didnt find the .svn folders. As a result, "exported" will show up wherever the revision would normally be mentioned, eg broker startup.
One way to handle this would be to add a property in the ant build process that can be set via command line in the release script with the value parsed from Git, and modify the build process to only use svnversion to figure it out the revision if that hasn't been set.
Robbie
< 2nd attempt at send as I didn't notice the first time that it only replied directly to me ;-) >
> -----Original Message-----
> From: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
> Sent: 09 December 2009 17:10
> To: dev@qpid.apache.org
> Subject: RE: First Qpid 0.6 Beta Release available for download and
> testing
>
> The single component package for QMan is not currently being created
> (although I seem to recall this happening with 0.5 as well). I think it
> uses a slightly non standard target to build the package just now, so
> ill see if I can modify it to be the same as the others and then the
> release script just needs updated to perform the copy.
>
> Robbie
>
> > -----Original Message-----
> > From: Andrew Stitcher [mailto:astitcher@redhat.com]
> > Sent: 03 December 2009 00:54
> > To: dev@qpid.apache.org
> > Subject: First Qpid 0.6 Beta Release available for download and
> testing
> >
> > Apologies for the long message, but there actually is a fair bit to
> > say:
> >
> > I've uploaded the artifacts for a 0.6 beta release to
> qpid.apache.org:
> >
> > http://qpid.apache.org/dist/qpid-0.6beta1/
> >
> > Please download and test this release. No, really, please download
> and
> > at least look at it.
> >
> > I've called it a beta because, it seems to me in the area that I know
> > (C
> > ++) and in the currently outstanding bugs it seems very usable.
> >
> > I plan that every one should give this a good beating for 1-2 weeks
> and
> > then I'll spin a release candidate, or if there are many problems
> found
> > and fixed a beta2.
> >
> > So all being well I'd like to vote on releasing 0.6 in a couple of
> > weeks.
> >
> > ---
> >
> > The status of this beta:
> >
> > My testing has been building the C++ tar source under various linux
> > platforms (using this release or very slightly earlier ones).
> > Essentially "configure; make check".
> >
> > Fedora 11/Fedora 12 (these both tested with the same results):
> >
> > Autotools build is fine including all broker modules. It doesn't seem
> > that the build as it stands in the C++ source release builds the qmf
> > bindings.
> >
> > Cmake build is mostly fine - however the clustering module doesn't
> > build
> > due to a complication of recent versions of boost. And r886259 breaks
> > building the clustering tests (due to missing the new
> > tests/cluster.cmake from EXTRA_DIST)
> >
> > Red Hat Enterprise Linux 5:
> >
> > Autotools builds fine.
> >
> > Cmake builds fine (but this was a slightly earlier release and this
> > would have been broken by r886259 as above).
> >
> > Debian 5 (lenny).
> >
> > Neither the clustering module nor the XML module have their necessary
> > prerequisites so can't be built here.
> >
> > Given this both autotools and cmake builds were fine.
> >
> > ---
> >
> > Overall Release Status:
> >
> > I've put up a page for the release on the wiki:
> >
> > http://cwiki.apache.org/confluence/display/qpid/0.6+Release
> >
> > (don't use the mirror on qpid.apache.org as it won't have the
> > dynamically updated bug list)
> >
> > Please edit the release page to add your understanding to it - it's a
> > little biased to the areas that I know about presently.
> >
> > One area that needs attention is the Release notes, I appeal to you
> to
> > add any release notes to that wiki page and I will turn them into
> > something to put in the release itself. Otherwise the only release
> > notes
> > will be for the C++ code and whatever I can get from the 0.6 fixed
> > bugs.
> >
> > ---
> >
> > Deficiencies:
> >
> > I've removed the separate dotnet package from the release as it
> doesn't
> > build for me using the release script. More about this separately.
> >
> > I've not packaged the wcf code separately as I've no idea how it
> should
> > look and I doubt I could build it under Linux anyway.
> >
> > I'm concerned there appear to be 5 13Mb eclipse plugins labelled for
> > various platforms - is this really necessary - it certainly took a
> long
> > time to upload and constitutes a large amount of space.
> >
> > ---
> >
> > At this point I suggest that any bugs important enough to be fixed
> > before the 0.6 release should be tagged with "Fix version" 0.6 and be
> a
> > blocker or critical.
> >
> > So if you find an issue that must be fixed before release then put it
> > in
> > Jira like this.
> >
> > Conversely if you know of a bug that is in this state that can be
> > resolved then resolve it poste haste.
> >
> > I will assume that as long as there *any* bugs like this 0.6 release
> is
> > blocked.
> >
> > Regards
> >
> > Andrew
> >
> >
> > ---------------------------------------------------------------------
> > 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: First Qpid 0.6 Beta Release available for download and testing
Posted by Robbie Gemmell <ro...@gmail.com>.
The single component package for QMan is not currently being created (although I seem to recall this happening with 0.5 as well). I think it uses a slightly non standard target to build the package just now, so ill see if I can modify it to be the same as the others and then the release script just needs updated to perform the copy.
Robbie
> -----Original Message-----
> From: Andrew Stitcher [mailto:astitcher@redhat.com]
> Sent: 03 December 2009 00:54
> To: dev@qpid.apache.org
> Subject: First Qpid 0.6 Beta Release available for download and testing
>
> Apologies for the long message, but there actually is a fair bit to
> say:
>
> I've uploaded the artifacts for a 0.6 beta release to qpid.apache.org:
>
> http://qpid.apache.org/dist/qpid-0.6beta1/
>
> Please download and test this release. No, really, please download and
> at least look at it.
>
> I've called it a beta because, it seems to me in the area that I know
> (C
> ++) and in the currently outstanding bugs it seems very usable.
>
> I plan that every one should give this a good beating for 1-2 weeks and
> then I'll spin a release candidate, or if there are many problems found
> and fixed a beta2.
>
> So all being well I'd like to vote on releasing 0.6 in a couple of
> weeks.
>
> ---
>
> The status of this beta:
>
> My testing has been building the C++ tar source under various linux
> platforms (using this release or very slightly earlier ones).
> Essentially "configure; make check".
>
> Fedora 11/Fedora 12 (these both tested with the same results):
>
> Autotools build is fine including all broker modules. It doesn't seem
> that the build as it stands in the C++ source release builds the qmf
> bindings.
>
> Cmake build is mostly fine - however the clustering module doesn't
> build
> due to a complication of recent versions of boost. And r886259 breaks
> building the clustering tests (due to missing the new
> tests/cluster.cmake from EXTRA_DIST)
>
> Red Hat Enterprise Linux 5:
>
> Autotools builds fine.
>
> Cmake builds fine (but this was a slightly earlier release and this
> would have been broken by r886259 as above).
>
> Debian 5 (lenny).
>
> Neither the clustering module nor the XML module have their necessary
> prerequisites so can't be built here.
>
> Given this both autotools and cmake builds were fine.
>
> ---
>
> Overall Release Status:
>
> I've put up a page for the release on the wiki:
>
> http://cwiki.apache.org/confluence/display/qpid/0.6+Release
>
> (don't use the mirror on qpid.apache.org as it won't have the
> dynamically updated bug list)
>
> Please edit the release page to add your understanding to it - it's a
> little biased to the areas that I know about presently.
>
> One area that needs attention is the Release notes, I appeal to you to
> add any release notes to that wiki page and I will turn them into
> something to put in the release itself. Otherwise the only release
> notes
> will be for the C++ code and whatever I can get from the 0.6 fixed
> bugs.
>
> ---
>
> Deficiencies:
>
> I've removed the separate dotnet package from the release as it doesn't
> build for me using the release script. More about this separately.
>
> I've not packaged the wcf code separately as I've no idea how it should
> look and I doubt I could build it under Linux anyway.
>
> I'm concerned there appear to be 5 13Mb eclipse plugins labelled for
> various platforms - is this really necessary - it certainly took a long
> time to upload and constitutes a large amount of space.
>
> ---
>
> At this point I suggest that any bugs important enough to be fixed
> before the 0.6 release should be tagged with "Fix version" 0.6 and be a
> blocker or critical.
>
> So if you find an issue that must be fixed before release then put it
> in
> Jira like this.
>
> Conversely if you know of a bug that is in this state that can be
> resolved then resolve it poste haste.
>
> I will assume that as long as there *any* bugs like this 0.6 release is
> blocked.
>
> Regards
>
> Andrew
>
>
> ---------------------------------------------------------------------
> 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: Release artifacts
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Dec 9, 2009 at 12:30 PM, Robert Godfrey <ro...@gmail.com> wrote:
> 2009/12/9 Rafael Schloming <ra...@redhat.com>
>
>> Robbie Gemmell wrote:
>>
>>> Hi all,
>>>
>>> Now that we have entered another release phase I think it would be a good
>>> time to discuss the release artifacts. I would like to see 0.6 ship with
>>> some updates to the artifacts we produce to make things more useful and
>>> obvious for our users.
>>>
>>
>> I think it's a bit late for 0.6, if I understand the timeline correctly.
>>
>>
>> The "Java broker, client, and tools" multi-component package appears to be
>>> just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/
>>> dir after performing a build and this makes it quite messy. A lot of test
>>> configuration files are left in the etc/ dir and there are loads of jars in
>>> the lib/ dir, which make it very hard to know which is being used where or
>>> allow splitting them up easily. You also end up with jars that just aren't
>>> intended to be used from there (eg the eclipse-plugin used in the JMX
>>> Management Console releases). We have single component packages for the Java
>>> broker, client, and management tools so if we want a multi-component package
>>> including any of these I think we should simply bundle those up instead of
>>> just tarring the build folder and mashing everything together.
>>>
>>
>> I sort of disagree with this. There is a "philosophy" behind using the
>> "just a copy" approach. The benefit is that we can eliminate a whole class
>> of bugs resulting from complex transformations necessary to turn the build
>> artifacts into release artifacts. Not to mention it is easier for us to
>> reproducer user issues if dev and user environments are as similar as
>> possible.
>>
>> That said I'm fine cleaning up the release artifacts and what not, I'm just
>> -1 on doing it by introducing complex transformations between build and
>> release artifacts. If we want the release artifacts to look different we
>> should make the build artifacts look different.
>>
>> As I've said before I'm happy to help with this, but we sort of need to
>> figure out what we want things to look like first, and IMHO such an effort
>> should also include making release artifacts more consistent across the
>> whole project.
>>
>>
> I think this is the key point - we need to work out how our build and
> release artefacts look; since what we have today is clearly unsatisfactory.
>
> If there are quick, non-risky, changes that we could put in place for 0.6
> that are universally acknowledged as a step in the right direction, I
> wouldn't necessarily be against them - however I don't think we want to
> embark on anything that will negatively impact a 0.6 release date at this
> stage. I am hugely +1 in doing this work before 0.7 (it's clearly a
> necessity for us if we ever want to get to a 1.0 release)
Totally agree here.
I think for the 0.7 release we definitely need to consider sorting out
our documentation and release artifacts a top priority.
I also agree that we need to have a consistent story across all our
components than a per language approach.
>>
>> Another result of the above is that QMan is shipped in the Java
>>> multi-component bundle despite the fact it is only useful if you have a C++
>>> broker. I realise it is written in Java, but those packages don't seem to me
>>> like they should necessarily be language specific. If anything I would say
>>> that QMan should surely ship in the multi-component bundle along with the
>>> items it can actually be used with (ie the C++ broker and client bundle), or
>>> just be made available standalone (which it already is). Users aren't
>>> necessarily going to expect they need to download both multi-component
>>> packages to make use of everything contained in one of them, and as
>>> mentioned above, splitting QMan alone out of the java multi-component bundle
>>> would be a bit hideous and non obvious anyway.
>>>
>>> I would also like to see us tagging the source-only release artifacts with
>>> 'src', ie the C++ and the "full" release artifact that is just a copy of the
>>> entire repo. It isn't exactly helpful for a user to download the 50MB file
>>> then find out what they are looking for isn't actually in there.
>>>
>>
>> I also think it's a shame that our artifacts look like they come from
>> entirely different projects. Even little things like readme capitalization,
>> general directory layout, etc is completely different from artifact to
>> artifact, and this is even after the release script hacks to rearchive stuff
>> to make things a bit more consistent.
>>
>>
> Agree again completely. We have a lot of work to do - which we should do as
> a matter of priority - in sorting out our artefacts to present a more
> consistent appearance across the project.
>
> -- Rob
>
>
>> --Rafael
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: Release artifacts
Posted by Robert Godfrey <ro...@gmail.com>.
2009/12/9 Rafael Schloming <ra...@redhat.com>
> Robbie Gemmell wrote:
>
>> Hi all,
>>
>> Now that we have entered another release phase I think it would be a good
>> time to discuss the release artifacts. I would like to see 0.6 ship with
>> some updates to the artifacts we produce to make things more useful and
>> obvious for our users.
>>
>
> I think it's a bit late for 0.6, if I understand the timeline correctly.
>
>
> The "Java broker, client, and tools" multi-component package appears to be
>> just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/
>> dir after performing a build and this makes it quite messy. A lot of test
>> configuration files are left in the etc/ dir and there are loads of jars in
>> the lib/ dir, which make it very hard to know which is being used where or
>> allow splitting them up easily. You also end up with jars that just aren't
>> intended to be used from there (eg the eclipse-plugin used in the JMX
>> Management Console releases). We have single component packages for the Java
>> broker, client, and management tools so if we want a multi-component package
>> including any of these I think we should simply bundle those up instead of
>> just tarring the build folder and mashing everything together.
>>
>
> I sort of disagree with this. There is a "philosophy" behind using the
> "just a copy" approach. The benefit is that we can eliminate a whole class
> of bugs resulting from complex transformations necessary to turn the build
> artifacts into release artifacts. Not to mention it is easier for us to
> reproducer user issues if dev and user environments are as similar as
> possible.
>
> That said I'm fine cleaning up the release artifacts and what not, I'm just
> -1 on doing it by introducing complex transformations between build and
> release artifacts. If we want the release artifacts to look different we
> should make the build artifacts look different.
>
> As I've said before I'm happy to help with this, but we sort of need to
> figure out what we want things to look like first, and IMHO such an effort
> should also include making release artifacts more consistent across the
> whole project.
>
>
I think this is the key point - we need to work out how our build and
release artefacts look; since what we have today is clearly unsatisfactory.
If there are quick, non-risky, changes that we could put in place for 0.6
that are universally acknowledged as a step in the right direction, I
wouldn't necessarily be against them - however I don't think we want to
embark on anything that will negatively impact a 0.6 release date at this
stage. I am hugely +1 in doing this work before 0.7 (it's clearly a
necessity for us if we ever want to get to a 1.0 release)
>
> Another result of the above is that QMan is shipped in the Java
>> multi-component bundle despite the fact it is only useful if you have a C++
>> broker. I realise it is written in Java, but those packages don't seem to me
>> like they should necessarily be language specific. If anything I would say
>> that QMan should surely ship in the multi-component bundle along with the
>> items it can actually be used with (ie the C++ broker and client bundle), or
>> just be made available standalone (which it already is). Users aren't
>> necessarily going to expect they need to download both multi-component
>> packages to make use of everything contained in one of them, and as
>> mentioned above, splitting QMan alone out of the java multi-component bundle
>> would be a bit hideous and non obvious anyway.
>>
>> I would also like to see us tagging the source-only release artifacts with
>> 'src', ie the C++ and the "full" release artifact that is just a copy of the
>> entire repo. It isn't exactly helpful for a user to download the 50MB file
>> then find out what they are looking for isn't actually in there.
>>
>
> I also think it's a shame that our artifacts look like they come from
> entirely different projects. Even little things like readme capitalization,
> general directory layout, etc is completely different from artifact to
> artifact, and this is even after the release script hacks to rearchive stuff
> to make things a bit more consistent.
>
>
Agree again completely. We have a lot of work to do - which we should do as
a matter of priority - in sorting out our artefacts to present a more
consistent appearance across the project.
-- Rob
> --Rafael
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: Release artifacts
Posted by Robbie Gemmell <ro...@gmail.com>.
We all seems to agree that it should change, so why dont we start work towards agreeing on what it should change to so everyone ends up happy :)
I like Martin's idea of having the build system output artifacts into build/broker, build/client etc, each composed of the jars needed to run that component rather than everything ending up in build/ as present. That way we can test exactly what we release, avoid class path hell as much as possible, reduce the number of potentially useless jars going into releases, and when it comes to release time all we do is tar up whichever module sub-directories we want in a particular component bundle...eg broker, client, broker + client, management/x, management/y, all of the above.
Robbie
> -----Original Message-----
> From: Rafael Schloming [mailto:rafaels@redhat.com]
> Sent: 10 December 2009 21:21
> To: dev@qpid.apache.org
> Subject: Re: Release artifacts
>
> Martin Ritchie wrote:
> > 2009/12/9 Rafael Schloming <ra...@redhat.com>:
> >> Robbie Gemmell wrote:
> >>> I think you have misunderstood what I meant by that entirely, as by
> "the
> >>> build system in general to always generate the release style
> artifacts" I
> >>> meant exactly what you are suggesting, that the build system should
> be
> >>> modified to generate something we can simply take a (partial)
> tarball of and
> >>> end up with what we release...ie release style. The reason there is
> anything
> >>> else in place right now is that they arent, IMO.
> >> Sorry, I see how you meant that now. My mistake. Clearly I've been
> too eager
> >> to rant recently. ;)
> >>
> >> --Rafael
> >
> > As the one who modified our current Java build system to produce
> > 'release' artefacts I can say it is very easy to generate a packaged
> > that contains the dependecies for a module. Add 1 line to the
> module's
> > build.xml:
> >
> > <target name="release-bin" depends="release-bin-tasks"/>
>
> I wasn't suggesting that this is difficult to do, merely that it uses a
> completely different mechanism than the one for generating build
> artifacts.
>
> > That said I undestand the desire to have a directory that we then
> just
> > tar up for release. However, the thought that tar-ing a directory is
> > in some way better than using the properties of the build system to
> > make a tar is some what erroneous. There is no reason that the two
> > cannot be the same.
>
> I think I may be missing something here. If they're the same, why not
> do
> it the simple way (i.e. tar up the directory).
>
> In any case, I'm not really saying that we shouldn't use build system
> properties. What I'm saying is that I don't want the process for
> generating release artifacts to be independent from the one used for
> generating build artifacts.
>
> I have to say I have NEVER used the files in the
> > build directory and the fact that all the jars end up in the lib dir
> > and so get put in to qpid-all.jar makes for a very dangerous
> situation
> > IMO. Testing with this setup can result in runtime dependencies not
> > being reflected by the build system.
>
> You may not use the files in the build directory directly, but you do
> use them indirectly because that's the environment that the tests are
> run in, e.g. when the external java broker is launched, it's done by
> executing build/bin/qpid-server.
>
> > I would be all for having the release artefacts being built in their
> > own build directories build/broker, build/client, build/qmf, etc. I'm
> > totally open to suggestions on how we can do this I simply used the
> > build system for the task last time as it has knowledge of all the
> > library dependencies and shipping jars that we don't need as part of
> > our packages is quite unhelpful, forcing these on to the class path
> > via qpid-all.jar as we do in the current build directory is just a
> > receipe for disaster.
> >
> > Now I feel I may have rant a bit, that wasn't really my intention. I
> > mearly wanted to point out that if we want to do component releases
> > form the Java directory for 0.6 it would take less that 2minutes to
> > sort out. So I think it is a totally doable.
>
> I completely agree qpid-all.jar is a bad idea. I believe it exists as a
> substitute for the giant client.jar that we used to generate by munging
> all the class files together into a single jar, and it replicates some
> of the same problems that system had. I'm not sure why this still
> exists, or indeed why it ever existed. I would be +1 on killing
> qpid-all.jar and using properly defined classpaths instead. (After 0.6
> goes out.)
>
> I'm also fine on adding a component release for qman for 0.6. What I
> don't think is a good idea at this stage (i.e. for 0.6) is to remove
> the
> full release or recompose it from the component releases since the full
> release is the environment that we actually run our tests in.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> 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: Release artifacts
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> 2009/12/9 Rafael Schloming <ra...@redhat.com>:
>> Robbie Gemmell wrote:
>>> I think you have misunderstood what I meant by that entirely, as by "the
>>> build system in general to always generate the release style artifacts" I
>>> meant exactly what you are suggesting, that the build system should be
>>> modified to generate something we can simply take a (partial) tarball of and
>>> end up with what we release...ie release style. The reason there is anything
>>> else in place right now is that they arent, IMO.
>> Sorry, I see how you meant that now. My mistake. Clearly I've been too eager
>> to rant recently. ;)
>>
>> --Rafael
>
> As the one who modified our current Java build system to produce
> 'release' artefacts I can say it is very easy to generate a packaged
> that contains the dependecies for a module. Add 1 line to the module's
> build.xml:
>
> <target name="release-bin" depends="release-bin-tasks"/>
I wasn't suggesting that this is difficult to do, merely that it uses a
completely different mechanism than the one for generating build artifacts.
> That said I undestand the desire to have a directory that we then just
> tar up for release. However, the thought that tar-ing a directory is
> in some way better than using the properties of the build system to
> make a tar is some what erroneous. There is no reason that the two
> cannot be the same.
I think I may be missing something here. If they're the same, why not do
it the simple way (i.e. tar up the directory).
In any case, I'm not really saying that we shouldn't use build system
properties. What I'm saying is that I don't want the process for
generating release artifacts to be independent from the one used for
generating build artifacts.
I have to say I have NEVER used the files in the
> build directory and the fact that all the jars end up in the lib dir
> and so get put in to qpid-all.jar makes for a very dangerous situation
> IMO. Testing with this setup can result in runtime dependencies not
> being reflected by the build system.
You may not use the files in the build directory directly, but you do
use them indirectly because that's the environment that the tests are
run in, e.g. when the external java broker is launched, it's done by
executing build/bin/qpid-server.
> I would be all for having the release artefacts being built in their
> own build directories build/broker, build/client, build/qmf, etc. I'm
> totally open to suggestions on how we can do this I simply used the
> build system for the task last time as it has knowledge of all the
> library dependencies and shipping jars that we don't need as part of
> our packages is quite unhelpful, forcing these on to the class path
> via qpid-all.jar as we do in the current build directory is just a
> receipe for disaster.
>
> Now I feel I may have rant a bit, that wasn't really my intention. I
> mearly wanted to point out that if we want to do component releases
> form the Java directory for 0.6 it would take less that 2minutes to
> sort out. So I think it is a totally doable.
I completely agree qpid-all.jar is a bad idea. I believe it exists as a
substitute for the giant client.jar that we used to generate by munging
all the class files together into a single jar, and it replicates some
of the same problems that system had. I'm not sure why this still
exists, or indeed why it ever existed. I would be +1 on killing
qpid-all.jar and using properly defined classpaths instead. (After 0.6
goes out.)
I'm also fine on adding a component release for qman for 0.6. What I
don't think is a good idea at this stage (i.e. for 0.6) is to remove the
full release or recompose it from the component releases since the full
release is the environment that we actually run our tests in.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release artifacts
Posted by Martin Ritchie <ri...@apache.org>.
2009/12/9 Rafael Schloming <ra...@redhat.com>:
> Robbie Gemmell wrote:
>>
>> I think you have misunderstood what I meant by that entirely, as by "the
>> build system in general to always generate the release style artifacts" I
>> meant exactly what you are suggesting, that the build system should be
>> modified to generate something we can simply take a (partial) tarball of and
>> end up with what we release...ie release style. The reason there is anything
>> else in place right now is that they arent, IMO.
>
> Sorry, I see how you meant that now. My mistake. Clearly I've been too eager
> to rant recently. ;)
>
> --Rafael
As the one who modified our current Java build system to produce
'release' artefacts I can say it is very easy to generate a packaged
that contains the dependecies for a module. Add 1 line to the module's
build.xml:
<target name="release-bin" depends="release-bin-tasks"/>
That said I undestand the desire to have a directory that we then just
tar up for release. However, the thought that tar-ing a directory is
in some way better than using the properties of the build system to
make a tar is some what erroneous. There is no reason that the two
cannot be the same. I have to say I have NEVER used the files in the
build directory and the fact that all the jars end up in the lib dir
and so get put in to qpid-all.jar makes for a very dangerous situation
IMO. Testing with this setup can result in runtime dependencies not
being reflected by the build system.
I would be all for having the release artefacts being built in their
own build directories build/broker, build/client, build/qmf, etc. I'm
totally open to suggestions on how we can do this I simply used the
build system for the task last time as it has knowledge of all the
library dependencies and shipping jars that we don't need as part of
our packages is quite unhelpful, forcing these on to the class path
via qpid-all.jar as we do in the current build directory is just a
receipe for disaster.
Now I feel I may have rant a bit, that wasn't really my intention. I
mearly wanted to point out that if we want to do component releases
form the Java directory for 0.6 it would take less that 2minutes to
sort out. So I think it is a totally doable.
Regards
Martin
> ---------------------------------------------------------------------
> 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: Release artifacts
Posted by Rafael Schloming <ra...@redhat.com>.
Robbie Gemmell wrote:
> I think you have misunderstood what I meant by that entirely, as by "the build system in general to always generate the release style artifacts" I meant exactly what you are suggesting, that the build system should be modified to generate something we can simply take a (partial) tarball of and end up with what we release...ie release style. The reason there is anything else in place right now is that they arent, IMO.
Sorry, I see how you meant that now. My mistake. Clearly I've been too
eager to rant recently. ;)
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release artifacts
Posted by Robbie Gemmell <ro...@gmail.com>.
I think you have misunderstood what I meant by that entirely, as by "the build system in general to always generate the release style artifacts" I meant exactly what you are suggesting, that the build system should be modified to generate something we can simply take a (partial) tarball of and end up with what we release...ie release style. The reason there is anything else in place right now is that they arent, IMO.
Robbie
> -----Original Message-----
> From: Rafael Schloming [mailto:rafaels@redhat.com]
> Sent: 09 December 2009 19:38
> To: dev@qpid.apache.org
> Subject: Re: Release artifacts
>
> Robbie Gemmell wrote:
> > I can see what you are saying and thus agree that it would be
> beneficial for the build system in general to always generate the
> release style artifacts. However I don't see that this means we
> shouldn't use what we have at our disposal now in order to give our
> users a better experience than we currently are.
>
> I'm saying more than just always generate the release style artifacts,
> they need to be generated in such a way that starting up a devel server
> is using the same scripting and artifacts that the end user encounters
> when they attempt the same sort of exercise from the release tarball.
> Moreover I'm saying that there should be no such thing as "release
> style
> artifacts", only build artifacts, and the various release tarballs
> should simply be archives (either whole or in part) of the build
> artifacts.
>
> And on top of all this it needs to be simple, fast, and properly do
> incremental builds so that it's actually usable for those of us who
> have
> chosen not to participate in this passing IDE fad. ;)
>
> I don't want to seem discouraging, I agree with your goals, I'm just
> particular about how we get there and I'm not eager to pile another
> quick hack on top of things. Doing all this without hacks shouldn't be
> terribly difficult as long as we figure out what we want first and
> choose something sensible.
>
> --Rafael
>
> ---------------------------------------------------------------------
> 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: Release artifacts
Posted by Rafael Schloming <ra...@redhat.com>.
Robbie Gemmell wrote:
> I can see what you are saying and thus agree that it would be beneficial for the build system in general to always generate the release style artifacts. However I don't see that this means we shouldn't use what we have at our disposal now in order to give our users a better experience than we currently are.
I'm saying more than just always generate the release style artifacts,
they need to be generated in such a way that starting up a devel server
is using the same scripting and artifacts that the end user encounters
when they attempt the same sort of exercise from the release tarball.
Moreover I'm saying that there should be no such thing as "release style
artifacts", only build artifacts, and the various release tarballs
should simply be archives (either whole or in part) of the build artifacts.
And on top of all this it needs to be simple, fast, and properly do
incremental builds so that it's actually usable for those of us who have
chosen not to participate in this passing IDE fad. ;)
I don't want to seem discouraging, I agree with your goals, I'm just
particular about how we get there and I'm not eager to pile another
quick hack on top of things. Doing all this without hacks shouldn't be
terribly difficult as long as we figure out what we want first and
choose something sensible.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release artifacts
Posted by Robbie Gemmell <ro...@gmail.com>.
I can see what you are saying and thus agree that it would be beneficial for the build system in general to always generate the release style artifacts. However I don't see that this means we shouldn't use what we have at our disposal now in order to give our users a better experience than we currently are.
Robbie
> -----Original Message-----
> From: Rafael Schloming [mailto:rafaels@redhat.com]
> Sent: 09 December 2009 17:45
> To: dev@qpid.apache.org
> Subject: Re: Release artifacts
>
> Robbie Gemmell wrote:
> > I'm not meaning to suggest doing any complex transformations, rather
> using what is already there. We have single-component packages that we
> already release separately for all these items, I'm just talking about
> whacking the relevant ones in a new tar and calling job done, instead
> of having a mashup that contains things people don't want or that can't
> even be used together.
>
> My issue with this is that the single-component packages weren't done
> according to the "philosophy" of the build system, and as such the
> process for producing component release artifacts diverges somewhat
> significantly from the process for producing build artifacts. So while
> what you suggest might not involve additional complex transformations,
> it does result in something that I would prefer to avoid, which is two
> separate systems, one for producing build artifacts, and the other for
> producing release artifacts.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> 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: Release artifacts
Posted by Rafael Schloming <ra...@redhat.com>.
Robbie Gemmell wrote:
> I'm not meaning to suggest doing any complex transformations, rather using what is already there. We have single-component packages that we already release separately for all these items, I'm just talking about whacking the relevant ones in a new tar and calling job done, instead of having a mashup that contains things people don't want or that can't even be used together.
My issue with this is that the single-component packages weren't done
according to the "philosophy" of the build system, and as such the
process for producing component release artifacts diverges somewhat
significantly from the process for producing build artifacts. So while
what you suggest might not involve additional complex transformations,
it does result in something that I would prefer to avoid, which is two
separate systems, one for producing build artifacts, and the other for
producing release artifacts.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release artifacts
Posted by Robbie Gemmell <ro...@gmail.com>.
I'm not meaning to suggest doing any complex transformations, rather using what is already there. We have single-component packages that we already release separately for all these items, I'm just talking about whacking the relevant ones in a new tar and calling job done, instead of having a mashup that contains things people don't want or that can't even be used together.
Robbie
> -----Original Message-----
> From: Rafael Schloming [mailto:rafaels@redhat.com]
> Sent: 09 December 2009 17:17
> To: dev@qpid.apache.org
> Subject: Re: Release artifacts
>
> Robbie Gemmell wrote:
> > Hi all,
> >
> > Now that we have entered another release phase I think it would be a
> good time to discuss the release artifacts. I would like to see 0.6
> ship with some updates to the artifacts we produce to make things more
> useful and obvious for our users.
>
> I think it's a bit late for 0.6, if I understand the timeline
> correctly.
>
> > The "Java broker, client, and tools" multi-component package appears
> to be just a copy of the etc/ lib/ and bin/ directories from the
> qpid/java/build/ dir after performing a build and this makes it quite
> messy. A lot of test configuration files are left in the etc/ dir and
> there are loads of jars in the lib/ dir, which make it very hard to
> know which is being used where or allow splitting them up easily. You
> also end up with jars that just aren't intended to be used from there
> (eg the eclipse-plugin used in the JMX Management Console releases). We
> have single component packages for the Java broker, client, and
> management tools so if we want a multi-component package including any
> of these I think we should simply bundle those up instead of just
> tarring the build folder and mashing everything together.
>
> I sort of disagree with this. There is a "philosophy" behind using the
> "just a copy" approach. The benefit is that we can eliminate a whole
> class of bugs resulting from complex transformations necessary to turn
> the build artifacts into release artifacts. Not to mention it is easier
> for us to reproducer user issues if dev and user environments are as
> similar as possible.
>
> That said I'm fine cleaning up the release artifacts and what not, I'm
> just -1 on doing it by introducing complex transformations between
> build
> and release artifacts. If we want the release artifacts to look
> different we should make the build artifacts look different.
>
> As I've said before I'm happy to help with this, but we sort of need to
> figure out what we want things to look like first, and IMHO such an
> effort should also include making release artifacts more consistent
> across the whole project.
>
> > Another result of the above is that QMan is shipped in the Java
> multi-component bundle despite the fact it is only useful if you have a
> C++ broker. I realise it is written in Java, but those packages don't
> seem to me like they should necessarily be language specific. If
> anything I would say that QMan should surely ship in the multi-
> component bundle along with the items it can actually be used with (ie
> the C++ broker and client bundle), or just be made available standalone
> (which it already is). Users aren't necessarily going to expect they
> need to download both multi-component packages to make use of
> everything contained in one of them, and as mentioned above, splitting
> QMan alone out of the java multi-component bundle would be a bit
> hideous and non obvious anyway.
> >
> > I would also like to see us tagging the source-only release artifacts
> with 'src', ie the C++ and the "full" release artifact that is just a
> copy of the entire repo. It isn't exactly helpful for a user to
> download the 50MB file then find out what they are looking for isn't
> actually in there.
>
> I also think it's a shame that our artifacts look like they come from
> entirely different projects. Even little things like readme
> capitalization, general directory layout, etc is completely different
> from artifact to artifact, and this is even after the release script
> hacks to rearchive stuff to make things a bit more consistent.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> 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: Release artifacts
Posted by Rafael Schloming <ra...@redhat.com>.
Robbie Gemmell wrote:
> Hi all,
>
> Now that we have entered another release phase I think it would be a good time to discuss the release artifacts. I would like to see 0.6 ship with some updates to the artifacts we produce to make things more useful and obvious for our users.
I think it's a bit late for 0.6, if I understand the timeline correctly.
> The "Java broker, client, and tools" multi-component package appears to be just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ dir after performing a build and this makes it quite messy. A lot of test configuration files are left in the etc/ dir and there are loads of jars in the lib/ dir, which make it very hard to know which is being used where or allow splitting them up easily. You also end up with jars that just aren't intended to be used from there (eg the eclipse-plugin used in the JMX Management Console releases). We have single component packages for the Java broker, client, and management tools so if we want a multi-component package including any of these I think we should simply bundle those up instead of just tarring the build folder and mashing everything together.
I sort of disagree with this. There is a "philosophy" behind using the
"just a copy" approach. The benefit is that we can eliminate a whole
class of bugs resulting from complex transformations necessary to turn
the build artifacts into release artifacts. Not to mention it is easier
for us to reproducer user issues if dev and user environments are as
similar as possible.
That said I'm fine cleaning up the release artifacts and what not, I'm
just -1 on doing it by introducing complex transformations between build
and release artifacts. If we want the release artifacts to look
different we should make the build artifacts look different.
As I've said before I'm happy to help with this, but we sort of need to
figure out what we want things to look like first, and IMHO such an
effort should also include making release artifacts more consistent
across the whole project.
> Another result of the above is that QMan is shipped in the Java multi-component bundle despite the fact it is only useful if you have a C++ broker. I realise it is written in Java, but those packages don't seem to me like they should necessarily be language specific. If anything I would say that QMan should surely ship in the multi-component bundle along with the items it can actually be used with (ie the C++ broker and client bundle), or just be made available standalone (which it already is). Users aren't necessarily going to expect they need to download both multi-component packages to make use of everything contained in one of them, and as mentioned above, splitting QMan alone out of the java multi-component bundle would be a bit hideous and non obvious anyway.
>
> I would also like to see us tagging the source-only release artifacts with 'src', ie the C++ and the "full" release artifact that is just a copy of the entire repo. It isn't exactly helpful for a user to download the 50MB file then find out what they are looking for isn't actually in there.
I also think it's a shame that our artifacts look like they come from
entirely different projects. Even little things like readme
capitalization, general directory layout, etc is completely different
from artifact to artifact, and this is even after the release script
hacks to rearchive stuff to make things a bit more consistent.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Release artifacts
Posted by Robbie Gemmell <ro...@gmail.com>.
Hi all,
Now that we have entered another release phase I think it would be a good time to discuss the release artifacts. I would like to see 0.6 ship with some updates to the artifacts we produce to make things more useful and obvious for our users.
The "Java broker, client, and tools" multi-component package appears to be just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ dir after performing a build and this makes it quite messy. A lot of test configuration files are left in the etc/ dir and there are loads of jars in the lib/ dir, which make it very hard to know which is being used where or allow splitting them up easily. You also end up with jars that just aren't intended to be used from there (eg the eclipse-plugin used in the JMX Management Console releases). We have single component packages for the Java broker, client, and management tools so if we want a multi-component package including any of these I think we should simply bundle those up instead of just tarring the build folder and mashing everything together.
Another result of the above is that QMan is shipped in the Java multi-component bundle despite the fact it is only useful if you have a C++ broker. I realise it is written in Java, but those packages don't seem to me like they should necessarily be language specific. If anything I would say that QMan should surely ship in the multi-component bundle along with the items it can actually be used with (ie the C++ broker and client bundle), or just be made available standalone (which it already is). Users aren't necessarily going to expect they need to download both multi-component packages to make use of everything contained in one of them, and as mentioned above, splitting QMan alone out of the java multi-component bundle would be a bit hideous and non obvious anyway.
I would also like to see us tagging the source-only release artifacts with 'src', ie the C++ and the "full" release artifact that is just a copy of the entire repo. It isn't exactly helpful for a user to download the 50MB file then find out what they are looking for isn't actually in there.
Robbie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: First Qpid 0.6 Beta Release available for download and testing
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Andrew,
Thanks for doing this ! I'll take a look/test shortly.
On the release notes front, afaik for the java that should be generated from
JIRA as this is pretty much accurate (for all completed items).
Hth,
Marnie
On Thu, Dec 3, 2009 at 12:53 AM, Andrew Stitcher <as...@redhat.com>wrote:
> Apologies for the long message, but there actually is a fair bit to say:
>
> I've uploaded the artifacts for a 0.6 beta release to qpid.apache.org:
>
> http://qpid.apache.org/dist/qpid-0.6beta1/
>
> Please download and test this release. No, really, please download and
> at least look at it.
>
> I've called it a beta because, it seems to me in the area that I know (C
> ++) and in the currently outstanding bugs it seems very usable.
>
> I plan that every one should give this a good beating for 1-2 weeks and
> then I'll spin a release candidate, or if there are many problems found
> and fixed a beta2.
>
> So all being well I'd like to vote on releasing 0.6 in a couple of
> weeks.
>
> ---
>
> The status of this beta:
>
> My testing has been building the C++ tar source under various linux
> platforms (using this release or very slightly earlier ones).
> Essentially "configure; make check".
>
> Fedora 11/Fedora 12 (these both tested with the same results):
>
> Autotools build is fine including all broker modules. It doesn't seem
> that the build as it stands in the C++ source release builds the qmf
> bindings.
>
> Cmake build is mostly fine - however the clustering module doesn't build
> due to a complication of recent versions of boost. And r886259 breaks
> building the clustering tests (due to missing the new
> tests/cluster.cmake from EXTRA_DIST)
>
> Red Hat Enterprise Linux 5:
>
> Autotools builds fine.
>
> Cmake builds fine (but this was a slightly earlier release and this
> would have been broken by r886259 as above).
>
> Debian 5 (lenny).
>
> Neither the clustering module nor the XML module have their necessary
> prerequisites so can't be built here.
>
> Given this both autotools and cmake builds were fine.
>
> ---
>
> Overall Release Status:
>
> I've put up a page for the release on the wiki:
>
> http://cwiki.apache.org/confluence/display/qpid/0.6+Release
>
> (don't use the mirror on qpid.apache.org as it won't have the
> dynamically updated bug list)
>
> Please edit the release page to add your understanding to it - it's a
> little biased to the areas that I know about presently.
>
> One area that needs attention is the Release notes, I appeal to you to
> add any release notes to that wiki page and I will turn them into
> something to put in the release itself. Otherwise the only release notes
> will be for the C++ code and whatever I can get from the 0.6 fixed bugs.
>
> ---
>
> Deficiencies:
>
> I've removed the separate dotnet package from the release as it doesn't
> build for me using the release script. More about this separately.
>
> I've not packaged the wcf code separately as I've no idea how it should
> look and I doubt I could build it under Linux anyway.
>
> I'm concerned there appear to be 5 13Mb eclipse plugins labelled for
> various platforms - is this really necessary - it certainly took a long
> time to upload and constitutes a large amount of space.
>
> ---
>
> At this point I suggest that any bugs important enough to be fixed
> before the 0.6 release should be tagged with "Fix version" 0.6 and be a
> blocker or critical.
>
> So if you find an issue that must be fixed before release then put it in
> Jira like this.
>
> Conversely if you know of a bug that is in this state that can be
> resolved then resolve it poste haste.
>
> I will assume that as long as there *any* bugs like this 0.6 release is
> blocked.
>
> Regards
>
> Andrew
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>