You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2008/10/13 15:54:44 UTC

[jira] Commented: (QPID-1257) Allow individual broker and client binary packages to be built

    [ https://issues.apache.org/jira/browse/QPID-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639055#action_12639055 ] 

Martin Ritchie commented on QPID-1257:
--------------------------------------

Summary from PartyChat:
["rhs"] to summarize my objections: 
["rhs"] 1. I don't like that there are distinct qpid-incubating jars in each release that have different contents. 
["rhs"] 2. The changes complicate the module level build system, but don't in fact seem to be that generically useful at a module level since it only makes sense to do this for certain combinations of things. 
["rhs"] 3. I think (although I have yet to investigate this) that the total change might be simpler if the bundling were done externally to the module level build system. 

<snip>

["rhs"] If someone starts out just using the client, and then downloads the management extensions later, they shouldn't end up with two sets of client and/or common jars. 
Martin  I would only provide a download that contains all dependencies for tools.
Martin  I would say the client package is client+common so you can use it
Martin  the management extensions would be qpid-management.jar and any extra bits it needs beyond what the client package is
Martin  as it should either sit in a client/plugins directory
Martin  or simply provide an easy way to be added to the classpath
["rhs"] ok, so you want tools to get fully bundled with all their dependencies, the client gets bundled with common, and everything else in the library category is an add-on to the client bundle? 
Martin  or an add-on to a tool bundle
Martin  yes
["rhs"] I'm ok with all of that. 

<snip>

Martin Great.. now how about the implementation :)
["rhs"] Well this is why I'm thinking it might be easier to do the bundling outside the module level build system. 
["rhs"] Since the rules for what you want to bundle are rather special case. 
["rhs"] perftests
integrationtests
junit-toolkit
testkit
systests

common
client
management-client
tools
examples

broker
broker-plugins

eclipse-plugins
qpid-cli 

["rhs"] those are the modules we have. 
["rhs"] I roughly grouped them by some arbitrary criteria. 
["rhs"] Looking at this list I think we probably have more modules than we need. 
Martin  I'd say common, examples, management-client, *plugins are the ones that would be library only... not sure what testkit is though 

<snip> 

Martin I'd view it much like the mina fokes. The ship -core which gets you going then you can add -ssl and -java5 for extra functionality
["rhs"] Although I suspect we could probably get something down to 512K if we were to strip it down to just the low level 0-10 client. 
Martin  for us I'd say client+common == core
["rhs"] I'd be inclined to throw tools in there as well. 

<snip>

[rob] I think we should be aiming to keep the core as small as possible... 
[rob] If anything I would be putting benchmarks etc eith examples 

<snip>

Martin In terms of the current implementation Rafi would you rather it was done outside of the module build?
["rhs"] I think having some ping style utility in client that you can run just as a sanity check that your broker is up and running is necessary. 
["rhs"] Martin: I think I'd like to take a look at that and see if it would be simpler 
["rhs"] Martin: But I'm fine doing that on my own if you don't mind letting the JIRA sit for a bit until I get the time. 
Martin  ok, my reasoning was to allow the modules to specify their customisations. So the broker pulls in common run scripts and etc scripts and the client builds the API and copies that in to its release.
Martin  I don't mid it sitting for a bit. I'll try and drop a summary of what we've discussed on to the JIRA for reference.
 
<snip>

Martin: I think it could work to let the modules specify things, I just want to avoid having multiple ways of copying together module contents into a release. 
["rhs"] Martin: at least as much as possible 
["rhs"] Martin: and right now there is a set of tasks that copies the module contents into the main build tree, and a separate set of tasks that copy the module contents into their distinct release trees 
Martin  Sounds good, I wanted to refrain from heavily parameterising the targets used by release 
Martin  so that it would be untouched. but happy to have the duplication removed, was never very happy about it but didn't want to change large chunks fo the system.
 






> Allow individual broker and client binary packages to be built
> --------------------------------------------------------------
>
>                 Key: QPID-1257
>                 URL: https://issues.apache.org/jira/browse/QPID-1257
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Ant Build System
>    Affects Versions: M3
>            Reporter: Martin Ritchie
>            Assignee: Rafael H. Schloming
>             Fix For: M4
>
>
> Currently our binary release includes classes, src and the jars for the whole project.
> It would be much cleaner if we had a broker and client jar package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.