[
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.
