brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Macartney <geoff.macart...@cloudsoftcorp.com>
Subject Re: CLI packaging problem
Date Thu, 24 Mar 2016 18:47:18 GMT

The brooklyn-client Apache build adds the CLI binaries in a zip file to the Apache Jenkins.

E.g. See links at end of https://builds.apache.org/view/Brooklyn/job/brooklyn-client-master/9/console

…
Uploaded: https://repository.apache.org/content/repositories/snapshots/org/apache/brooklyn/brooklyn-client-cli/0.9.0-SNAPSHOT/brooklyn-client-cli-0.9.0-20160321.101320-2-bin.zip
<https://repository.apache.org/content/repositories/snapshots/org/apache/brooklyn/brooklyn-client-cli/0.9.0-SNAPSHOT/brooklyn-client-cli-0.9.0-20160321.101320-2-bin.zip>




All you would need to do would be to add that to the same location as the main Brooklyn zip.


As discussed with Duncan, for convenience it would be good to unpack the zip file before uploading
it so users could just get the right binary without having to download the zip.  I’d just
put up the Windows, Mac and Linux builds.




————————————————————
Gnu PGP key - http://is.gd/TTTTuI


> On 24 Mar 2016, at 18:32, Aled Sage <aled.sage@gmail.com> wrote:
> 
> +1
> 
> We won't have the brooklyn-client RPM in time for a 0.9.0 release, but we should definitely
work on that afterwards.
> 
> ---
> We can add a download link for the CLI to http://brooklyn.apache.org/download/index.html,
once there is an official apache release of the CLI.
> 
> I believe the release manager copies the final artifacts to the right place in apache,
giving us the nice download links. We can do the same for the CLI, as long as we have an appropriate
artifact to put there from the 0.9.0 release process.
> 
> Aled
> 
> 
> On 24/03/2016 18:12, John McCabe wrote:
>> +1 Geoff
>> Having a CLI download alongside the brooklyn release as well makes sense,
>> like the web ui the user should be able to run the client from their local
>> machine to connect to a remote brooklyn instance (which is supported and
>> imho preferable since it keeps you off the server), bundling it only in the
>> release means the user has to either copy br from the node brooklyn is
>> running on or download a full brooklyn release only to get at the cli tool
>> which seems unnecessary.
>> I'd be inclined to package it (rpm, brew etc) separately as well -
>> installing the brooklyn rpm would pull in the client as a dep (will need to
>> be in a repo to make this painless). For a client install you could use
>> brew/port on OSX, possibly Chocolatey on Windows.
>> 
>> On Thu, 24 Mar 2016 at 17:56 Geoff Macartney <
>> geoff.macartney@cloudsoftcorp.com> wrote:
>> 
>>> I suggest adding the CLI artifacts to the release alongside the brooklyn
>>> zip.  At the same time as the brooklyn zip is copied to the release
>>> location, get the CLI artifact out of the Maven repository, for good
>>> measure unpack it, and upload the individual builds of the CLI tool to the
>>> same location.  Then update docs to explain how to download it too.
>>> 
>>> Remember the vagrant approach is really there as a Getting Started track,
>>> it’s not the typical path for using Brooklyn in anger.
>>> 
>>> 
>>> ————————————————————
>>> Gnu PGP key - http://is.gd/TTTTuI
>>> 
>>> 
>>>> On 24 Mar 2016, at 17:51, Duncan Godwin <duncan.godwin@cloudsoftcorp.com>
>>> wrote:
>>>> Hi All,
>>>> 
>>>> I've found a problem with the way the CLI is distributed for Brooklyn.
>>> It's
>>>> included in the release files which means when an initial user uses the
>>>> vagrant getting started guide, the CLI is inside the vagrant box, not on
>>>> the users machine. As there's no download link to the CLI anywhere it
>>> means
>>>> the flow of the documentation no longer works.
>>>> 
>>>> The solutions to this could be:
>>>> 
>>>> * Add additional downloads for each of the CLI versions somewhere
>>>> * Extract the correct CLI from the vagrant box to the users machine in
>>> the
>>>> instructions
>>>> * Download the CLI bundle and extract and install the correct one
>>>> 
>>>> What are everyone's thoughts?
>>>> 
>>>> Many thanks
>>>> 
>>>> Duncan
>>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message