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 <[email protected]>

> 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:[email protected]
>
>

Reply via email to