[
https://issues.apache.org/jira/browse/QPID-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914468#comment-13914468
]
Robbie Gemmell commented on QPID-5550:
--------------------------------------
Just thought I'd chime in to say that I would echo Justin's comments.
We had a related discussion on the list years ago, indicating we should only
maintain a single source archive [for a given component]; if for none of the
other good reasons, then simply because we don't test them all equally. I
mentioned this when there was indication of creating some of these additional
artifacts originally, and I think they subsequently got removed though have
since come back. There is also the confusion around what bits go with what
else: do people use python-qpid_messaging-0.26.tar.gz or
qpid-python-0.26.tar.gz for example? (I know the answer is obvious if you
inspect them, but it isn't from the name). Once you download
python-qpid_messaging-0.26.tar.gz, how do you use it without also downloading
one of the two other source archives that also happen to include the same
content?
We obviously still have multiple source artifacts for particular components,
since we have the 'full release' as well as various other source archives, so
these aren't alone in that. However, we are currently working to overhaul the
build system for the current Java tree to allow later splitting it up and
moving towards the major components being independently releasable. This could
then also help us in stopping having multiple artifacts containing the elements
of the current C++ tree as well for example.
> Simplify binding artifacts and build metadata
> ---------------------------------------------
>
> Key: QPID-5550
> URL: https://issues.apache.org/jira/browse/QPID-5550
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client, Packaging, Perl Client, Python Client
> Reporter: Justin Ross
> Assignee: Darryl L. Pierce
>
> Right now we build special tarballs for the perl and wrapped python bindings
> of the messaging api in the release.sh script.
> First, what motivates this? Wouldn't be simpler from a packaging standpoint
> to simply build these when you build the C++ parts of the messaging api,
> using just the one cpp source tarball?
> Second, this logic belongs in the cpp subtree, not in the release.sh script.
> We can call into any "make special dist variant" targets we may need from the
> release script.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
