Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Geoff Macartney]

Thanks for taking this on Alex, it's a terrific bit of work. I've looked it
all over and added my approval, but I won't merge anything now, as I expect
others will want to look at it too.

Best,
Geoff


On Tue, 2 Jun 2020 at 10:48, Alex Heneveld  wrote:

>
> Hi team-
>
> I've taken a deeper look at the license/notice issues raised by Justin
> and I think have resolved them in PR [1] (and various PRs it
> references).  A summary is below.  Justin, thank you for spotting these
> bugs.
>
> If anyone has comments please reply here or on the issue [1].
>
> Regarding the use of Category-X [2] licenses:
>
> * net.java.dev.jna - this is dual-licensed under LGPL and ASL; the
> NOTICE incorrectly stated it was being used under the former; it now
> correctly states it is being used under the latter
>
> * com.google.code.findbugs.annotations - Apache Brooklyn does not use
> nor depend on this LGPL project. It is a compile-time-only dependency of
> libraries we use, but not accurately reported in those libraries as
> compile-time-only dependencies and so was picked up as a transient
> dependency of apache Brooklyn.  Our maven POMs now explicitly exclude
> this so it is no longer treated as a dependency, not included in our
> binary dist, and not noted in NOTICE.
>
> * With the above two fixes there are no longer any Category-X [2]
> licenses in our source or binary builds.
>
>
> Regarding the information included in our NOTICE files:
>
> * Our source dist and JAR NOTICE files (in the root of projects, in JARs
> and in the source dist artifact) previously for convenience reported the
> binary dependencies pulled in.  These were clearly labelled as such but
> nevertheless contrary to the philosophy that NOTICE files should contain
> only what is legally required.  These NOTICES have been fixed so that
> they only list third-party artifacts actually included in our source.
> Consequently they are much, much smaller.
>
> * Our binary dist NOTICE files (in binary TGZs, RPMs, WARs and all other
> binary artifacts) list all runtime dependencies included in the binary
> dist where a custom notice, attribution, and/or license for that
> dependency is appropriate.  Where there is doubt about any such
> obligation we have erred on the side of inclusion.
>
> * A non-statutory DEPENDENCIES file is now included alongside the source
> dist NOTICE files advising what binary dependencies will be included in
> the built artifact.  This file contains what was formerly in the source
> dist NOTICE files. This makes it easy for users to analyse the full set
> of dependencies of Apache Brooklyn without conferring the undue legal
> burden entailed by including this information in any of the statutory
> NOTICE files.
>
>
> There are some additional changes:
>
> * Some libraries have been updated or added recently and use the new
> licenses EPL v2 and EDL v1 which were not previously recognised
>
> * Some dependencies were overlooked in some reports where the "karaf"
> project did not depend on the bundles it incorporates; this is remedied,
> and the license/notice generation only applies to that relevant project
> (and license-gen running faster by only running on that project)
>
> * Some icons had been added from Apache projects and elsewhere, with no
> NOTICE; this is remedied
>
> I believe with [1] all LICENSE and NOTICE files will now be current,
> correct, and compliant with Apache policy.
>
> Best
> Alex
>
>
> [1] https://github.com/apache/brooklyn-dist/pull/164
>
> [2] https://www.apache.org/legal/resolved.html#category-x
>
>
> On 18/05/2020 10:18, Aled Sage wrote:
> > Hi Justin,
> >
> > Thanks for spotting this and reaching out.
> >
> > Looking at the license/notice generation, I think there are two things
> > that went wrong for 1.0 release:
> >
> > 1. The maven license plugin [1] picked the wrong license for
> > dependencies when there were multiple to choose from (i.e. LGPL vs
> > Apache 2.0 in [2]).
> >
> > 2. We're trying to include far too much stuff in NOTICE. Quoting the
> > really useful link you shared [3]:
> >
> > "Do not add anything to NOTICE which is not legally required."
> >
> > ---
> >
> > We should review point 1 above to confirm there really are no licenses
> > that are forbidden in apache projects. And we should review point 2 to
> > change the way we generate NOTICE files so it doesn't include everything.
> >
> > Aled
> >
> > [1] https://github.com/ahgittin/license-audit-maven-plugin
> >
> > [2] https://github.com/java-native-access/jna/blob/master/pom-jna.xml
> >
> > [3] http://www.apache.org/dev/licensing-howto.html
> >
> > [4] https://www.apache.org/legal/resolved.html#category-x
> >
> >
> > On 17/05/2020 10:20, Justin Mclean wrote:
> >> Hi,
> >>
> >> I was looking reviewing your board report and mailing list and took a
> >> look at your release. The current LICENSE and NOTICE are not in line
> >> with ASF policy. For instance, your license contains licenses that
> >> can't be used in a source release. 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Justin Mclean]

Hi,

> I've taken a deeper look at the license/notice issues raised by Justin and I 
> think have resolved them in PR [1] (and various PRs it references).  A 
> summary is below.  Justin, thank you for spotting these bugs.\\

Thanks so much for looking into it and fixing the issue. It’s far easier to 
point out that something may not be following policy than it is to correct it.

Kind Regards,
Justin

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Alex Heneveld]

Hi team-

I've taken a deeper look at the license/notice issues raised by Justin 
and I think have resolved them in PR [1] (and various PRs it 
references).  A summary is below.  Justin, thank you for spotting these 
bugs.


If anyone has comments please reply here or on the issue [1].

Regarding the use of Category-X [2] licenses:

* net.java.dev.jna - this is dual-licensed under LGPL and ASL; the 
NOTICE incorrectly stated it was being used under the former; it now 
correctly states it is being used under the latter


* com.google.code.findbugs.annotations - Apache Brooklyn does not use 
nor depend on this LGPL project. It is a compile-time-only dependency of 
libraries we use, but not accurately reported in those libraries as 
compile-time-only dependencies and so was picked up as a transient 
dependency of apache Brooklyn.  Our maven POMs now explicitly exclude 
this so it is no longer treated as a dependency, not included in our 
binary dist, and not noted in NOTICE.


* With the above two fixes there are no longer any Category-X [2] 
licenses in our source or binary builds.



Regarding the information included in our NOTICE files:

* Our source dist and JAR NOTICE files (in the root of projects, in JARs 
and in the source dist artifact) previously for convenience reported the 
binary dependencies pulled in.  These were clearly labelled as such but 
nevertheless contrary to the philosophy that NOTICE files should contain 
only what is legally required.  These NOTICES have been fixed so that 
they only list third-party artifacts actually included in our source. 
Consequently they are much, much smaller.


* Our binary dist NOTICE files (in binary TGZs, RPMs, WARs and all other 
binary artifacts) list all runtime dependencies included in the binary 
dist where a custom notice, attribution, and/or license for that 
dependency is appropriate.  Where there is doubt about any such 
obligation we have erred on the side of inclusion.


* A non-statutory DEPENDENCIES file is now included alongside the source 
dist NOTICE files advising what binary dependencies will be included in 
the built artifact.  This file contains what was formerly in the source 
dist NOTICE files. This makes it easy for users to analyse the full set 
of dependencies of Apache Brooklyn without conferring the undue legal 
burden entailed by including this information in any of the statutory 
NOTICE files.



There are some additional changes:

* Some libraries have been updated or added recently and use the new 
licenses EPL v2 and EDL v1 which were not previously recognised


* Some dependencies were overlooked in some reports where the "karaf" 
project did not depend on the bundles it incorporates; this is remedied, 
and the license/notice generation only applies to that relevant project 
(and license-gen running faster by only running on that project)


* Some icons had been added from Apache projects and elsewhere, with no 
NOTICE; this is remedied


I believe with [1] all LICENSE and NOTICE files will now be current, 
correct, and compliant with Apache policy.


Best
Alex


[1] https://github.com/apache/brooklyn-dist/pull/164

[2] https://www.apache.org/legal/resolved.html#category-x


On 18/05/2020 10:18, Aled Sage wrote:

Hi Justin,

Thanks for spotting this and reaching out.

Looking at the license/notice generation, I think there are two things 
that went wrong for 1.0 release:


1. The maven license plugin [1] picked the wrong license for 
dependencies when there were multiple to choose from (i.e. LGPL vs 
Apache 2.0 in [2]).


2. We're trying to include far too much stuff in NOTICE. Quoting the 
really useful link you shared [3]:


        "Do not add anything to NOTICE which is not legally required."

---

We should review point 1 above to confirm there really are no licenses 
that are forbidden in apache projects. And we should review point 2 to 
change the way we generate NOTICE files so it doesn't include everything.


Aled

[1] https://github.com/ahgittin/license-audit-maven-plugin

[2] https://github.com/java-native-access/jna/blob/master/pom-jna.xml

[3] http://www.apache.org/dev/licensing-howto.html

[4] https://www.apache.org/legal/resolved.html#category-x


On 17/05/2020 10:20, Justin Mclean wrote:

Hi,

I was looking reviewing your board report and mailing list and took a 
look at your release. The current LICENSE and NOTICE are not in line 
with ASF policy. For instance, your license contains licenses that 
can't be used in a source release. I think what you have 
misunderstood is that you're listing the licenses of all dependencies 
rather than just what is bundled in the release. Your notice file 
also doesn't need to list dependencies but just required notices, 
content from other ALv2 notice files and relocated copyright notices. 
This is a good guide [1] if you need help on fixing this, please 
reach out.


Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Justin Mclean]

Hi,

> All, I'm not sure what the procedure here should be. Do we need to
> re-release 1.0.0 or is that horse gone, and we should release a fixed 1.0.1?

I would just fix it when you make a new release.

Thanks,
Justin

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Geoff Macartney]

Thanks for pointing this out, Justin.

All, I'm not sure what the procedure here should be. Do we need to
re-release 1.0.0 or is that horse gone, and we should release a fixed 1.0.1?

Regards
Geoff


On Mon, 18 May 2020, 10:18 Aled Sage,  wrote:

> Hi Justin,
>
> Thanks for spotting this and reaching out.
>
> Looking at the license/notice generation, I think there are two things
> that went wrong for 1.0 release:
>
> 1. The maven license plugin [1] picked the wrong license for
> dependencies when there were multiple to choose from (i.e. LGPL vs
> Apache 2.0 in [2]).
>
> 2. We're trying to include far too much stuff in NOTICE. Quoting the
> really useful link you shared [3]:
>
>  "Do not add anything to NOTICE which is not legally required."
>
> ---
>
> We should review point 1 above to confirm there really are no licenses
> that are forbidden in apache projects. And we should review point 2 to
> change the way we generate NOTICE files so it doesn't include everything.
>
> Aled
>
> [1] https://github.com/ahgittin/license-audit-maven-plugin
>
> [2] https://github.com/java-native-access/jna/blob/master/pom-jna.xml
>
> [3] http://www.apache.org/dev/licensing-howto.html
>
> [4] https://www.apache.org/legal/resolved.html#category-x
>
>
> On 17/05/2020 10:20, Justin Mclean wrote:
> > Hi,
> >
> > I was looking reviewing your board report and mailing list and took a
> look at your release. The current LICENSE and NOTICE are not in line with
> ASF policy. For instance, your license contains licenses that can't be used
> in a source release. I think what you have misunderstood is that you're
> listing the licenses of all dependencies rather than just what is bundled
> in the release. Your notice file also doesn't need to list dependencies but
> just required notices, content from other ALv2 notice files and relocated
> copyright notices. This is a good guide [1] if you need help on fixing
> this, please reach out.
> >
> > Thanks,
> > Justin
> >
> > 1. http://www.apache.org/dev/licensing-howto.html
>

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Aled Sage]

Hi Justin,

Thanks for spotting this and reaching out.

Looking at the license/notice generation, I think there are two things 
that went wrong for 1.0 release:


1. The maven license plugin [1] picked the wrong license for 
dependencies when there were multiple to choose from (i.e. LGPL vs 
Apache 2.0 in [2]).


2. We're trying to include far too much stuff in NOTICE. Quoting the 
really useful link you shared [3]:


        "Do not add anything to NOTICE which is not legally required."

---

We should review point 1 above to confirm there really are no licenses 
that are forbidden in apache projects. And we should review point 2 to 
change the way we generate NOTICE files so it doesn't include everything.


Aled

[1] https://github.com/ahgittin/license-audit-maven-plugin

[2] https://github.com/java-native-access/jna/blob/master/pom-jna.xml

[3] http://www.apache.org/dev/licensing-howto.html

[4] https://www.apache.org/legal/resolved.html#category-x


On 17/05/2020 10:20, Justin Mclean wrote:

Hi,

I was looking reviewing your board report and mailing list and took a look at 
your release. The current LICENSE and NOTICE are not in line with ASF policy. 
For instance, your license contains licenses that can't be used in a source 
release. I think what you have misunderstood is that you're listing the 
licenses of all dependencies rather than just what is bundled in the release. 
Your notice file also doesn't need to list dependencies but just required 
notices, content from other ALv2 notice files and relocated copyright notices. 
This is a good guide [1] if you need help on fixing this, please reach out.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Justin Mclean]

Hi,

I was looking reviewing your board report and mailing list and took a look at 
your release. The current LICENSE and NOTICE are not in line with ASF policy. 
For instance, your license contains licenses that can't be used in a source 
release. I think what you have misunderstood is that you're listing the 
licenses of all dependencies rather than just what is bundled in the release. 
Your notice file also doesn't need to list dependencies but just required 
notices, content from other ALv2 notice files and relocated copyright notices. 
This is a good guide [1] if you need help on fixing this, please reach out.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[John McCabe]

Awesome, congratulations to you all !

On Tue, Feb 25, 2020 at 1:57 PM Geoff Macartney 
wrote:

> Thanks Richard,
>
> That's great news. I don't know about you all but I find this very
> exciting!
>
> Many congratulations to everyone who has contributed to building Apache
> Brooklyn in the first place, and thanks to everyone who's helped pull
> together the fixes and polish for the 1.0.0 release, and especially Richard
> for doing the onerous task of Release Master.
>
> Geoff
>
>
>
> On Tue, 25 Feb 2020 at 07:48, Светослав Нейков 
> wrote:
>
> > Congrats on the 1.0.0 release!
> >
> > A little bit late to the party, but here's one from me as well.
> >
> > +1 (binding)
> >
> > I downloaded the zip package on MacOS and successfully started the
> "Python
> > Web Server" example template on the jclouds-vagrant location.
> >
> > Svet.
> >
> >
> > На вт, 25.02.2020 г. в 8:38 Juan Cabrerizo  написа:
> >
> > > +1 from me.
> > > I run some tests with the zip version on Windows 10 pro
> > >
> > > Juan
> > >
> > > On Fri, 21 Feb 2020 at 16:22, Geoff Macartney <
> geoff.macart...@gmail.com
> > >
> > > wrote:
> > >
> > > > > For the dockerfile not working out-of-the-box with base image
> > > > > `maven:3.6.3-jdk-8`, that's something we should include in the
> > release
> > > > > notes (saying what the simple workaround is). However, I don't
> think
> > > > > this has to be a blocker - we don't use this to release an image to
> > > > > doc>ker hub (or equivalent) as part of the brooklyn release. Also,
> > that
> > > > > dockerfile is a convenience for building (if I understand
> correctly)
> > > > > rather than impacting end-users who are running Brooklyn; the build
> > > > > outside of docker still works.
> > > >
> > > > OK, you have convinced me Aled!  :-)
> > > >
> > > > +1 from me
> > > >
> > > > Geoff
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 21 Feb 2020 at 12:46, Iuliana Cosmina <
> > > > iuliana.cosm...@cloudsoftcorp.com> wrote:
> > > >
> > > > > +1 from me
> > > > >
> > > > > Successfully started unpacked and started
> > > > > apache-brooklyn-1.0.0-rc3-vagrant.zip on macOS Catalina 10.15.3.
> All
> > > > nodes
> > > > > were correctly created.
> > > > >
> > > > > Observation:  Since this is a RC release, the
> > files/install_brooklyn.sh
> > > > > had to be modified and the BROOKLYN_URL variable had to be
> explicitly
> > > > set to
> > > > > "
> > > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3/apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> > > > > ”.
> > > > > Because the script seems to be meant to work only with final
> > releases.
> > > > >
> > > > >
> > > > > Also, successfully unpacked and started
> > > > > apache-brooklyn-1.0.0-rc3-bin.tar.gz on macOS Catalina 10.15.3. On
> > this
> > > > > instance I tried all templates in the Quick Launch and they all
> > > deployed
> > > > > correctly on AWS instances.  I used Firefox 73.0.2 to access Apache
> > > > > Brooklyn.
> > > > >
> > > > > Observation: for the composed templates ( 3 and 4 use template 2 )
> > the
> > > > > blueprints composer cannot visually display the blueprint because
> it
> > > does
> > > > > not recognise the `locations: []` construct and the workaround is
> to
> > > edit
> > > > > the YAML file and replace it with `location: your_location`, than
> the
> > > > > blueprint is recognised and the visual components are depicted
> > > correctly.
> > > > >
> > > > >
> > > > > Iuliana Cosmina
> > > > > SoftwareEngineer
> > > > >
> > > > > Cloudsoft | Bringing Business to the Cloud
> > > > >
> > > > > E: iuli...@cloudsoft.io
> > > > > M: 07745054173
> > > > > T: _iulianacosmina
> > > > > L: https://www.linkedin.com/in/iulianacosmina/
> > > > > On 21 Feb 2020, 10:42 +, Aled Sage ,
> wrote:
> > > > > > +1 from me.
> > > > > >
> > > > > > I did some exploratory testing on OS X with the tar.gz, and
> > deployed
> > > a
> > > > > > few blueprints.
> > > > > >
> > > > > > --
> > > > > >
> > > > > > For the dockerfile not working out-of-the-box with base image
> > > > > > `maven:3.6.3-jdk-8`, that's something we should include in the
> > > release
> > > > > > notes (saying what the simple workaround is). However, I don't
> > think
> > > > > > this has to be a blocker - we don't use this to release an image
> to
> > > > > > docker hub (or equivalent) as part of the brooklyn release. Also,
> > > that
> > > > > > dockerfile is a convenience for building (if I understand
> > correctly)
> > > > > > rather than impacting end-users who are running Brooklyn; the
> build
> > > > > > outside of docker still works.
> > > > > >
> > > > > > Aled
> > > > > >
> > > > > >
> > > > > > On 18/02/2020 23:37, Richard Downer wrote:
> > > > > > > This is to call for a vote for the release of Apache Brooklyn
> > > 1.0.0.
> > > > > > >
> > > > > > > This release comprises of a source code distribution, and a
> > > > > corresponding
> > > > > > > binary distribution, and Maven artifacts.
> > > > > > >
> > > > > > > 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Geoff Macartney]

Thanks Richard,

That's great news. I don't know about you all but I find this very exciting!

Many congratulations to everyone who has contributed to building Apache
Brooklyn in the first place, and thanks to everyone who's helped pull
together the fixes and polish for the 1.0.0 release, and especially Richard
for doing the onerous task of Release Master.

Geoff



On Tue, 25 Feb 2020 at 07:48, Светослав Нейков 
wrote:

> Congrats on the 1.0.0 release!
>
> A little bit late to the party, but here's one from me as well.
>
> +1 (binding)
>
> I downloaded the zip package on MacOS and successfully started the "Python
> Web Server" example template on the jclouds-vagrant location.
>
> Svet.
>
>
> На вт, 25.02.2020 г. в 8:38 Juan Cabrerizo  написа:
>
> > +1 from me.
> > I run some tests with the zip version on Windows 10 pro
> >
> > Juan
> >
> > On Fri, 21 Feb 2020 at 16:22, Geoff Macartney  >
> > wrote:
> >
> > > > For the dockerfile not working out-of-the-box with base image
> > > > `maven:3.6.3-jdk-8`, that's something we should include in the
> release
> > > > notes (saying what the simple workaround is). However, I don't think
> > > > this has to be a blocker - we don't use this to release an image to
> > > > doc>ker hub (or equivalent) as part of the brooklyn release. Also,
> that
> > > > dockerfile is a convenience for building (if I understand correctly)
> > > > rather than impacting end-users who are running Brooklyn; the build
> > > > outside of docker still works.
> > >
> > > OK, you have convinced me Aled!  :-)
> > >
> > > +1 from me
> > >
> > > Geoff
> > >
> > >
> > >
> > >
> > >
> > > On Fri, 21 Feb 2020 at 12:46, Iuliana Cosmina <
> > > iuliana.cosm...@cloudsoftcorp.com> wrote:
> > >
> > > > +1 from me
> > > >
> > > > Successfully started unpacked and started
> > > > apache-brooklyn-1.0.0-rc3-vagrant.zip on macOS Catalina 10.15.3. All
> > > nodes
> > > > were correctly created.
> > > >
> > > > Observation:  Since this is a RC release, the
> files/install_brooklyn.sh
> > > > had to be modified and the BROOKLYN_URL variable had to be explicitly
> > > set to
> > > > "
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3/apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> > > > ”.
> > > > Because the script seems to be meant to work only with final
> releases.
> > > >
> > > >
> > > > Also, successfully unpacked and started
> > > > apache-brooklyn-1.0.0-rc3-bin.tar.gz on macOS Catalina 10.15.3. On
> this
> > > > instance I tried all templates in the Quick Launch and they all
> > deployed
> > > > correctly on AWS instances.  I used Firefox 73.0.2 to access Apache
> > > > Brooklyn.
> > > >
> > > > Observation: for the composed templates ( 3 and 4 use template 2 )
> the
> > > > blueprints composer cannot visually display the blueprint because it
> > does
> > > > not recognise the `locations: []` construct and the workaround is to
> > edit
> > > > the YAML file and replace it with `location: your_location`, than the
> > > > blueprint is recognised and the visual components are depicted
> > correctly.
> > > >
> > > >
> > > > Iuliana Cosmina
> > > > SoftwareEngineer
> > > >
> > > > Cloudsoft | Bringing Business to the Cloud
> > > >
> > > > E: iuli...@cloudsoft.io
> > > > M: 07745054173
> > > > T: _iulianacosmina
> > > > L: https://www.linkedin.com/in/iulianacosmina/
> > > > On 21 Feb 2020, 10:42 +, Aled Sage , wrote:
> > > > > +1 from me.
> > > > >
> > > > > I did some exploratory testing on OS X with the tar.gz, and
> deployed
> > a
> > > > > few blueprints.
> > > > >
> > > > > --
> > > > >
> > > > > For the dockerfile not working out-of-the-box with base image
> > > > > `maven:3.6.3-jdk-8`, that's something we should include in the
> > release
> > > > > notes (saying what the simple workaround is). However, I don't
> think
> > > > > this has to be a blocker - we don't use this to release an image to
> > > > > docker hub (or equivalent) as part of the brooklyn release. Also,
> > that
> > > > > dockerfile is a convenience for building (if I understand
> correctly)
> > > > > rather than impacting end-users who are running Brooklyn; the build
> > > > > outside of docker still works.
> > > > >
> > > > > Aled
> > > > >
> > > > >
> > > > > On 18/02/2020 23:37, Richard Downer wrote:
> > > > > > This is to call for a vote for the release of Apache Brooklyn
> > 1.0.0.
> > > > > >
> > > > > > This release comprises of a source code distribution, and a
> > > > corresponding
> > > > > > binary distribution, and Maven artifacts.
> > > > > >
> > > > > > The source and binary distributions, including signatures,
> digests,
> > > > etc.
> > > > > > can be found at:
> > > > > >
> > > > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3
> > > > > >
> > > > > > The artifact SHA-256 checksums are as follows:
> > > > > >
> > > > > > f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> > > > > > 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Светослав Нейков]

Congrats on the 1.0.0 release!

A little bit late to the party, but here's one from me as well.

+1 (binding)

I downloaded the zip package on MacOS and successfully started the "Python
Web Server" example template on the jclouds-vagrant location.

Svet.


На вт, 25.02.2020 г. в 8:38 Juan Cabrerizo  написа:

> +1 from me.
> I run some tests with the zip version on Windows 10 pro
>
> Juan
>
> On Fri, 21 Feb 2020 at 16:22, Geoff Macartney 
> wrote:
>
> > > For the dockerfile not working out-of-the-box with base image
> > > `maven:3.6.3-jdk-8`, that's something we should include in the release
> > > notes (saying what the simple workaround is). However, I don't think
> > > this has to be a blocker - we don't use this to release an image to
> > > doc>ker hub (or equivalent) as part of the brooklyn release. Also, that
> > > dockerfile is a convenience for building (if I understand correctly)
> > > rather than impacting end-users who are running Brooklyn; the build
> > > outside of docker still works.
> >
> > OK, you have convinced me Aled!  :-)
> >
> > +1 from me
> >
> > Geoff
> >
> >
> >
> >
> >
> > On Fri, 21 Feb 2020 at 12:46, Iuliana Cosmina <
> > iuliana.cosm...@cloudsoftcorp.com> wrote:
> >
> > > +1 from me
> > >
> > > Successfully started unpacked and started
> > > apache-brooklyn-1.0.0-rc3-vagrant.zip on macOS Catalina 10.15.3. All
> > nodes
> > > were correctly created.
> > >
> > > Observation:  Since this is a RC release, the files/install_brooklyn.sh
> > > had to be modified and the BROOKLYN_URL variable had to be explicitly
> > set to
> > > "
> > >
> >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3/apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> > > ”.
> > > Because the script seems to be meant to work only with final releases.
> > >
> > >
> > > Also, successfully unpacked and started
> > > apache-brooklyn-1.0.0-rc3-bin.tar.gz on macOS Catalina 10.15.3. On this
> > > instance I tried all templates in the Quick Launch and they all
> deployed
> > > correctly on AWS instances.  I used Firefox 73.0.2 to access Apache
> > > Brooklyn.
> > >
> > > Observation: for the composed templates ( 3 and 4 use template 2 ) the
> > > blueprints composer cannot visually display the blueprint because it
> does
> > > not recognise the `locations: []` construct and the workaround is to
> edit
> > > the YAML file and replace it with `location: your_location`, than the
> > > blueprint is recognised and the visual components are depicted
> correctly.
> > >
> > >
> > > Iuliana Cosmina
> > > SoftwareEngineer
> > >
> > > Cloudsoft | Bringing Business to the Cloud
> > >
> > > E: iuli...@cloudsoft.io
> > > M: 07745054173
> > > T: _iulianacosmina
> > > L: https://www.linkedin.com/in/iulianacosmina/
> > > On 21 Feb 2020, 10:42 +, Aled Sage , wrote:
> > > > +1 from me.
> > > >
> > > > I did some exploratory testing on OS X with the tar.gz, and deployed
> a
> > > > few blueprints.
> > > >
> > > > --
> > > >
> > > > For the dockerfile not working out-of-the-box with base image
> > > > `maven:3.6.3-jdk-8`, that's something we should include in the
> release
> > > > notes (saying what the simple workaround is). However, I don't think
> > > > this has to be a blocker - we don't use this to release an image to
> > > > docker hub (or equivalent) as part of the brooklyn release. Also,
> that
> > > > dockerfile is a convenience for building (if I understand correctly)
> > > > rather than impacting end-users who are running Brooklyn; the build
> > > > outside of docker still works.
> > > >
> > > > Aled
> > > >
> > > >
> > > > On 18/02/2020 23:37, Richard Downer wrote:
> > > > > This is to call for a vote for the release of Apache Brooklyn
> 1.0.0.
> > > > >
> > > > > This release comprises of a source code distribution, and a
> > > corresponding
> > > > > binary distribution, and Maven artifacts.
> > > > >
> > > > > The source and binary distributions, including signatures, digests,
> > > etc.
> > > > > can be found at:
> > > > >
> > > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3
> > > > >
> > > > > The artifact SHA-256 checksums are as follows:
> > > > >
> > > > > f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> > > > > *apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> > > > > 7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
> > > > > *apache-brooklyn-1.0.0-rc3-bin.tar.gz
> > > > > 9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
> > > > > *apache-brooklyn-1.0.0-rc3-bin.zip
> > > > > e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
> > > > > *apache-brooklyn-1.0.0-rc3-classic.tar.gz
> > > > > e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
> > > > > *apache-brooklyn-1.0.0-rc3-classic.zip
> > > > > 3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
> > > > > *apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
> > > > > eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
> 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Richard Downer]

+1 (binding)

Tests performed:

Build from source
Run from .tar.gz on Ubuntu Linux 18.04
Connect br client from Windows 10 Professional
Deploy a quickstart blueprint
Try some more complex blueprints


On Tue, 18 Feb 2020 at 23:37, Richard Downer  wrote:

> This is to call for a vote for the release of Apache Brooklyn 1.0.0.
>
> This release comprises of a source code distribution, and a corresponding
> binary distribution, and Maven artifacts.
>
> The source and binary distributions, including signatures, digests, etc.
> can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3
>
> The artifact SHA-256 checksums are as follows:
>
>   f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> *apache-brooklyn-1.0.0-rc3-1.noarch.rpm
>   7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
> *apache-brooklyn-1.0.0-rc3-bin.tar.gz
>   9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
> *apache-brooklyn-1.0.0-rc3-bin.zip
>   e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
> *apache-brooklyn-1.0.0-rc3-classic.tar.gz
>   e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
> *apache-brooklyn-1.0.0-rc3-classic.zip
>   3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
> *apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
>   eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
> *apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
>   13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82
> *apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz
>   f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24
> *apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip
>   8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5
> *apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz
>   ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277
> *apache-brooklyn-1.0.0-rc3-client-cli-windows.zip
>   9d6a7a04fe10f95a34b6167f2896a219f7863e16e66e107e4243ce32695d5b49
> *apache-brooklyn-1.0.0-rc3-src.tar.gz
>   a9e622854b2774790e0f7421b21b680a04983c18e09a086628c4360248670fa3
> *apache-brooklyn-1.0.0-rc3-src.zip
>   164898a211dea73397fb22faa7b8198ff4d63d0941e1c690a20c39515cfadbcc
> *apache-brooklyn-1.0.0-rc3-vagrant.tar.gz
>   ac81a3c07b4b59213362abc6ecbac3a57de500cee63a9793f06a42e8821ffce1
> *apache-brooklyn-1.0.0-rc3-vagrant.zip
>   9e45418d12edb0332dec8a3e93b991dcb0f9afa55d9f2fef4d5cd6c6c65b9a26
> *apache-brooklyn-1.0.0-rc3.deb
>
> The Nexus staging repository for the Maven artifacts is located at:
>
>
> https://repository.apache.org/content/repositories/orgapachebrooklyn-1055
>
> All release artifacts are signed with the following key:
>
> https://people.apache.org/keys/committer/richard.asc
>
> KEYS file available here:
>
> https://dist.apache.org/repos/dist/release/brooklyn/KEYS
>
>
> The artifacts were built from git commit IDs:
>
> brooklyn: d3ef75f26240bee38d288d507364616380e4d853
> brooklyn-client: 52b5546a5434eb6ecae55233d134f6dc11ce617b
> brooklyn-dist: d55424d0c5994d9bceb804bcf0ecc7c80560370e
> brooklyn-docs: d142ba2e2a65801e5bebea9e48bdc476d0265b7a
> brooklyn-library: cb57d7ff725e6b59ac8ec2a533696664c298e917
> brooklyn-server: 029fa6d1723550b500483aac5144749c28b6d6b7
> brooklyn-ui: c209d0b9e9612f39ea462c912bf58b121932e3d0
> All of the above have been tagged as "apache-brooklyn-1.0.0-rc3"
>
> Please vote on releasing this package as Apache Brooklyn 1.0.0.
>
> The vote will be open for at least 72 hours.
> [ ] +1 Release this package as Apache Brooklyn 1.0.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
>
> Thanks!
>

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Juan Cabrerizo]

+1 from me.
I run some tests with the zip version on Windows 10 pro

Juan

On Fri, 21 Feb 2020 at 16:22, Geoff Macartney 
wrote:

> > For the dockerfile not working out-of-the-box with base image
> > `maven:3.6.3-jdk-8`, that's something we should include in the release
> > notes (saying what the simple workaround is). However, I don't think
> > this has to be a blocker - we don't use this to release an image to
> > doc>ker hub (or equivalent) as part of the brooklyn release. Also, that
> > dockerfile is a convenience for building (if I understand correctly)
> > rather than impacting end-users who are running Brooklyn; the build
> > outside of docker still works.
>
> OK, you have convinced me Aled!  :-)
>
> +1 from me
>
> Geoff
>
>
>
>
>
> On Fri, 21 Feb 2020 at 12:46, Iuliana Cosmina <
> iuliana.cosm...@cloudsoftcorp.com> wrote:
>
> > +1 from me
> >
> > Successfully started unpacked and started
> > apache-brooklyn-1.0.0-rc3-vagrant.zip on macOS Catalina 10.15.3. All
> nodes
> > were correctly created.
> >
> > Observation:  Since this is a RC release, the files/install_brooklyn.sh
> > had to be modified and the BROOKLYN_URL variable had to be explicitly
> set to
> > "
> >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3/apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> > ”.
> > Because the script seems to be meant to work only with final releases.
> >
> >
> > Also, successfully unpacked and started
> > apache-brooklyn-1.0.0-rc3-bin.tar.gz on macOS Catalina 10.15.3. On this
> > instance I tried all templates in the Quick Launch and they all deployed
> > correctly on AWS instances.  I used Firefox 73.0.2 to access Apache
> > Brooklyn.
> >
> > Observation: for the composed templates ( 3 and 4 use template 2 ) the
> > blueprints composer cannot visually display the blueprint because it does
> > not recognise the `locations: []` construct and the workaround is to edit
> > the YAML file and replace it with `location: your_location`, than the
> > blueprint is recognised and the visual components are depicted correctly.
> >
> >
> > Iuliana Cosmina
> > SoftwareEngineer
> >
> > Cloudsoft | Bringing Business to the Cloud
> >
> > E: iuli...@cloudsoft.io
> > M: 07745054173
> > T: _iulianacosmina
> > L: https://www.linkedin.com/in/iulianacosmina/
> > On 21 Feb 2020, 10:42 +, Aled Sage , wrote:
> > > +1 from me.
> > >
> > > I did some exploratory testing on OS X with the tar.gz, and deployed a
> > > few blueprints.
> > >
> > > --
> > >
> > > For the dockerfile not working out-of-the-box with base image
> > > `maven:3.6.3-jdk-8`, that's something we should include in the release
> > > notes (saying what the simple workaround is). However, I don't think
> > > this has to be a blocker - we don't use this to release an image to
> > > docker hub (or equivalent) as part of the brooklyn release. Also, that
> > > dockerfile is a convenience for building (if I understand correctly)
> > > rather than impacting end-users who are running Brooklyn; the build
> > > outside of docker still works.
> > >
> > > Aled
> > >
> > >
> > > On 18/02/2020 23:37, Richard Downer wrote:
> > > > This is to call for a vote for the release of Apache Brooklyn 1.0.0.
> > > >
> > > > This release comprises of a source code distribution, and a
> > corresponding
> > > > binary distribution, and Maven artifacts.
> > > >
> > > > The source and binary distributions, including signatures, digests,
> > etc.
> > > > can be found at:
> > > >
> > > >
> >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3
> > > >
> > > > The artifact SHA-256 checksums are as follows:
> > > >
> > > > f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> > > > *apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> > > > 7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
> > > > *apache-brooklyn-1.0.0-rc3-bin.tar.gz
> > > > 9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
> > > > *apache-brooklyn-1.0.0-rc3-bin.zip
> > > > e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
> > > > *apache-brooklyn-1.0.0-rc3-classic.tar.gz
> > > > e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
> > > > *apache-brooklyn-1.0.0-rc3-classic.zip
> > > > 3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
> > > > *apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
> > > > eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
> > > > *apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
> > > > 13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82
> > > > *apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz
> > > > f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24
> > > > *apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip
> > > > 8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5
> > > > *apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz
> > > > ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277
> > > > 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Geoff Macartney]

> For the dockerfile not working out-of-the-box with base image
> `maven:3.6.3-jdk-8`, that's something we should include in the release
> notes (saying what the simple workaround is). However, I don't think
> this has to be a blocker - we don't use this to release an image to
> doc>ker hub (or equivalent) as part of the brooklyn release. Also, that
> dockerfile is a convenience for building (if I understand correctly)
> rather than impacting end-users who are running Brooklyn; the build
> outside of docker still works.

OK, you have convinced me Aled!  :-)

+1 from me

Geoff





On Fri, 21 Feb 2020 at 12:46, Iuliana Cosmina <
iuliana.cosm...@cloudsoftcorp.com> wrote:

> +1 from me
>
> Successfully started unpacked and started
> apache-brooklyn-1.0.0-rc3-vagrant.zip on macOS Catalina 10.15.3. All nodes
> were correctly created.
>
> Observation:  Since this is a RC release, the files/install_brooklyn.sh
> had to be modified and the BROOKLYN_URL variable had to be explicitly set to
> "
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3/apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> ”.
> Because the script seems to be meant to work only with final releases.
>
>
> Also, successfully unpacked and started
> apache-brooklyn-1.0.0-rc3-bin.tar.gz on macOS Catalina 10.15.3. On this
> instance I tried all templates in the Quick Launch and they all deployed
> correctly on AWS instances.  I used Firefox 73.0.2 to access Apache
> Brooklyn.
>
> Observation: for the composed templates ( 3 and 4 use template 2 ) the
> blueprints composer cannot visually display the blueprint because it does
> not recognise the `locations: []` construct and the workaround is to edit
> the YAML file and replace it with `location: your_location`, than the
> blueprint is recognised and the visual components are depicted correctly.
>
>
> Iuliana Cosmina
> SoftwareEngineer
>
> Cloudsoft | Bringing Business to the Cloud
>
> E: iuli...@cloudsoft.io
> M: 07745054173
> T: _iulianacosmina
> L: https://www.linkedin.com/in/iulianacosmina/
> On 21 Feb 2020, 10:42 +, Aled Sage , wrote:
> > +1 from me.
> >
> > I did some exploratory testing on OS X with the tar.gz, and deployed a
> > few blueprints.
> >
> > --
> >
> > For the dockerfile not working out-of-the-box with base image
> > `maven:3.6.3-jdk-8`, that's something we should include in the release
> > notes (saying what the simple workaround is). However, I don't think
> > this has to be a blocker - we don't use this to release an image to
> > docker hub (or equivalent) as part of the brooklyn release. Also, that
> > dockerfile is a convenience for building (if I understand correctly)
> > rather than impacting end-users who are running Brooklyn; the build
> > outside of docker still works.
> >
> > Aled
> >
> >
> > On 18/02/2020 23:37, Richard Downer wrote:
> > > This is to call for a vote for the release of Apache Brooklyn 1.0.0.
> > >
> > > This release comprises of a source code distribution, and a
> corresponding
> > > binary distribution, and Maven artifacts.
> > >
> > > The source and binary distributions, including signatures, digests,
> etc.
> > > can be found at:
> > >
> > >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3
> > >
> > > The artifact SHA-256 checksums are as follows:
> > >
> > > f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> > > *apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> > > 7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
> > > *apache-brooklyn-1.0.0-rc3-bin.tar.gz
> > > 9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
> > > *apache-brooklyn-1.0.0-rc3-bin.zip
> > > e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
> > > *apache-brooklyn-1.0.0-rc3-classic.tar.gz
> > > e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
> > > *apache-brooklyn-1.0.0-rc3-classic.zip
> > > 3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
> > > *apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
> > > eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
> > > *apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
> > > 13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82
> > > *apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz
> > > f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24
> > > *apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip
> > > 8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5
> > > *apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz
> > > ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277
> > > *apache-brooklyn-1.0.0-rc3-client-cli-windows.zip
> > > 9d6a7a04fe10f95a34b6167f2896a219f7863e16e66e107e4243ce32695d5b49
> > > *apache-brooklyn-1.0.0-rc3-src.tar.gz
> > > a9e622854b2774790e0f7421b21b680a04983c18e09a086628c4360248670fa3
> > > *apache-brooklyn-1.0.0-rc3-src.zip
> > > 164898a211dea73397fb22faa7b8198ff4d63d0941e1c690a20c39515cfadbcc
> > > 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Iuliana Cosmina]

+1 from me

Successfully started unpacked and started apache-brooklyn-1.0.0-rc3-vagrant.zip 
on macOS Catalina 10.15.3. All nodes were correctly created.

Observation:  Since this is a RC release, the files/install_brooklyn.sh had to 
be modified and the BROOKLYN_URL variable had to be explicitly set to
"https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3/apache-brooklyn-1.0.0-rc3-1.noarch.rpm”.
Because the script seems to be meant to work only with final releases.


Also, successfully unpacked and started apache-brooklyn-1.0.0-rc3-bin.tar.gz on 
macOS Catalina 10.15.3. On this instance I tried all templates in the Quick 
Launch and they all deployed correctly on AWS instances.  I used Firefox 73.0.2 
to access Apache Brooklyn.

Observation: for the composed templates ( 3 and 4 use template 2 ) the 
blueprints composer cannot visually display the blueprint because it does not 
recognise the `locations: []` construct and the workaround is to edit the YAML 
file and replace it with `location: your_location`, than the blueprint is 
recognised and the visual components are depicted correctly.


Iuliana Cosmina
SoftwareEngineer

Cloudsoft | Bringing Business to the Cloud

E: iuli...@cloudsoft.io
M: 07745054173
T: _iulianacosmina
L: https://www.linkedin.com/in/iulianacosmina/
On 21 Feb 2020, 10:42 +, Aled Sage , wrote:
> +1 from me.
>
> I did some exploratory testing on OS X with the tar.gz, and deployed a
> few blueprints.
>
> --
>
> For the dockerfile not working out-of-the-box with base image
> `maven:3.6.3-jdk-8`, that's something we should include in the release
> notes (saying what the simple workaround is). However, I don't think
> this has to be a blocker - we don't use this to release an image to
> docker hub (or equivalent) as part of the brooklyn release. Also, that
> dockerfile is a convenience for building (if I understand correctly)
> rather than impacting end-users who are running Brooklyn; the build
> outside of docker still works.
>
> Aled
>
>
> On 18/02/2020 23:37, Richard Downer wrote:
> > This is to call for a vote for the release of Apache Brooklyn 1.0.0.
> >
> > This release comprises of a source code distribution, and a corresponding
> > binary distribution, and Maven artifacts.
> >
> > The source and binary distributions, including signatures, digests, etc.
> > can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3
> >
> > The artifact SHA-256 checksums are as follows:
> >
> > f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> > *apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> > 7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
> > *apache-brooklyn-1.0.0-rc3-bin.tar.gz
> > 9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
> > *apache-brooklyn-1.0.0-rc3-bin.zip
> > e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
> > *apache-brooklyn-1.0.0-rc3-classic.tar.gz
> > e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
> > *apache-brooklyn-1.0.0-rc3-classic.zip
> > 3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
> > *apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
> > eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
> > *apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
> > 13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82
> > *apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz
> > f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24
> > *apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip
> > 8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5
> > *apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz
> > ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277
> > *apache-brooklyn-1.0.0-rc3-client-cli-windows.zip
> > 9d6a7a04fe10f95a34b6167f2896a219f7863e16e66e107e4243ce32695d5b49
> > *apache-brooklyn-1.0.0-rc3-src.tar.gz
> > a9e622854b2774790e0f7421b21b680a04983c18e09a086628c4360248670fa3
> > *apache-brooklyn-1.0.0-rc3-src.zip
> > 164898a211dea73397fb22faa7b8198ff4d63d0941e1c690a20c39515cfadbcc
> > *apache-brooklyn-1.0.0-rc3-vagrant.tar.gz
> > ac81a3c07b4b59213362abc6ecbac3a57de500cee63a9793f06a42e8821ffce1
> > *apache-brooklyn-1.0.0-rc3-vagrant.zip
> > 9e45418d12edb0332dec8a3e93b991dcb0f9afa55d9f2fef4d5cd6c6c65b9a26
> > *apache-brooklyn-1.0.0-rc3.deb
> >
> > The Nexus staging repository for the Maven artifacts is located at:
> >
> >
> > https://repository.apache.org/content/repositories/orgapachebrooklyn-1055
> >
> > All release artifacts are signed with the following key:
> >
> > https://people.apache.org/keys/committer/richard.asc
> >
> > KEYS file available here:
> >
> > https://dist.apache.org/repos/dist/release/brooklyn/KEYS
> >
> >
> > The artifacts were built from git commit IDs:
> >
> > brooklyn: d3ef75f26240bee38d288d507364616380e4d853
> > brooklyn-client: 52b5546a5434eb6ecae55233d134f6dc11ce617b
> > brooklyn-dist: d55424d0c5994d9bceb804bcf0ecc7c80560370e
> > brooklyn-docs: 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Aled Sage]

+1 from me.

I did some exploratory testing on OS X with the tar.gz, and deployed a 
few blueprints.


--

For the dockerfile not working out-of-the-box with base image 
`maven:3.6.3-jdk-8`, that's something we should include in the release 
notes (saying what the simple workaround is). However, I don't think 
this has to be a blocker - we don't use this to release an image to 
docker hub (or equivalent) as part of the brooklyn release. Also, that 
dockerfile is a convenience for building (if I understand correctly) 
rather than impacting end-users who are running Brooklyn; the build 
outside of docker still works.


Aled


On 18/02/2020 23:37, Richard Downer wrote:

This is to call for a vote for the release of Apache Brooklyn 1.0.0.

This release comprises of a source code distribution, and a corresponding
binary distribution, and Maven artifacts.

The source and binary distributions, including signatures, digests, etc.
can be found at:

   https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3

The artifact SHA-256 checksums are as follows:

   f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
*apache-brooklyn-1.0.0-rc3-1.noarch.rpm
   7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
*apache-brooklyn-1.0.0-rc3-bin.tar.gz
   9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
*apache-brooklyn-1.0.0-rc3-bin.zip
   e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
*apache-brooklyn-1.0.0-rc3-classic.tar.gz
   e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
*apache-brooklyn-1.0.0-rc3-classic.zip
   3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
*apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
   eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
*apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
   13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82
*apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz
   f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24
*apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip
   8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5
*apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz
   ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277
*apache-brooklyn-1.0.0-rc3-client-cli-windows.zip
   9d6a7a04fe10f95a34b6167f2896a219f7863e16e66e107e4243ce32695d5b49
*apache-brooklyn-1.0.0-rc3-src.tar.gz
   a9e622854b2774790e0f7421b21b680a04983c18e09a086628c4360248670fa3
*apache-brooklyn-1.0.0-rc3-src.zip
   164898a211dea73397fb22faa7b8198ff4d63d0941e1c690a20c39515cfadbcc
*apache-brooklyn-1.0.0-rc3-vagrant.tar.gz
   ac81a3c07b4b59213362abc6ecbac3a57de500cee63a9793f06a42e8821ffce1
*apache-brooklyn-1.0.0-rc3-vagrant.zip
   9e45418d12edb0332dec8a3e93b991dcb0f9afa55d9f2fef4d5cd6c6c65b9a26
*apache-brooklyn-1.0.0-rc3.deb

The Nexus staging repository for the Maven artifacts is located at:


https://repository.apache.org/content/repositories/orgapachebrooklyn-1055

All release artifacts are signed with the following key:

 https://people.apache.org/keys/committer/richard.asc

KEYS file available here:

 https://dist.apache.org/repos/dist/release/brooklyn/KEYS


The artifacts were built from git commit IDs:

brooklyn: d3ef75f26240bee38d288d507364616380e4d853
brooklyn-client: 52b5546a5434eb6ecae55233d134f6dc11ce617b
brooklyn-dist: d55424d0c5994d9bceb804bcf0ecc7c80560370e
brooklyn-docs: d142ba2e2a65801e5bebea9e48bdc476d0265b7a
brooklyn-library: cb57d7ff725e6b59ac8ec2a533696664c298e917
brooklyn-server: 029fa6d1723550b500483aac5144749c28b6d6b7
brooklyn-ui: c209d0b9e9612f39ea462c912bf58b121932e3d0
All of the above have been tagged as "apache-brooklyn-1.0.0-rc3"

Please vote on releasing this package as Apache Brooklyn 1.0.0.

The vote will be open for at least 72 hours.
[ ] +1 Release this package as Apache Brooklyn 1.0.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...


Thanks!

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Aled Sage]

Hi Geoff, all,

For using vagrant, Iuliana said:

    "Successfully started unpacked and started 
apache-brooklyn-1.0.0-rc3-vagrant.zip. All nodes were correctly created."


Geoff, did your steps match the vagrant instructions at 
http://brooklyn.apache.org/v/latest/start/running.html?


*Iuliana*, can you add anything about how you ran it?

--

The error is interesting, it is trying to use:

https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-1.0.0/apache-brooklyn-1.0.0.noarch.rpm

That wouldn't work because we haven't released 1.0.0 yet.

Comparing that against the 0.12.0 release path, it's similar:

https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-0.12.0/apache-brooklyn-0.12.0-1.noarch.rpm

Note the need for the "-1" in the file name though.

Aled


On 20/02/2020 23:13, Geoff Macartney wrote:

My current appraisal of the RC is:

verify_brooklyn_rc.sh looks ok, tail of output (tidied):

[✓] Build from sources successful
~/brooklyn_releases/apache-brooklyn-1.0.0-rc3 ~/brooklyn_releases

---

Additional steps requiring manual intervention (execute in source
distribution folder apache-brooklyn-1.0.0-src:
...etc

Checks successfully completed:
[✓] Download links work.
[✓] Checksums and PGP signatures are valid.
[✓] Expanded source archive matches contents of RC tag.
[✓] Expanded source archive builds and passes tests.
[✓] LICENSE is present and correct.
[✓] NOTICE is present and correct, including copyright date.
[✓] No compiled archives bundled in source archive.

Checks left to do manually with the help of above instructions:
[✓] All files have license headers where appropriate.
[✓] All dependencies have compatible licenses.

Remaning items from checklist:
[✓] Binaries work.
[✓] I follow this project’s commits list.


So far so good. Also did:

[✓] Was able to use UI to create and install simple apps (on AWS - a
server, and Tomcat 8 with demo war).
[✓] br cli works (OSX binary, haven't tried the others)

On the other hand, I get a failure running the Vagrant release. I am not
sure I'm doing this right though; it's a long time since I've used this. I
just unpacked that tarball, cd-ed to that directory, and did "vagrant up".
It churns away for a bit, then I get a 404 at the "download release
archive" step. I tweaked the script to output the URL it's downloading and
it says

 brooklyn: Downloading Brooklyn release archive
https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-1.0.0/apache-brooklyn-1.0.0.noarch.rpm
 brooklyn: curl: (22) The requested URL returned error: 404 Not Found
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.


Does anyone recognise this, or know what's up?

regards
Geoff








On Thu, 20 Feb 2020 at 18:33, Geoff Macartney 
wrote:


Note that's different from the situation with the Docker image above. If
we are distributing source with a Dockerfile, I'd really expect that to
"Just Work". I'm tending towards thinking this will mean a -1 from me -
open to debate the matter though, what do you all think?

Geoff


On Thu, 20 Feb 2020 at 18:30, Geoff Macartney 
wrote:


Hi Paul,


Given Debian Buster, the current version doesn't provide a Java 8 JRE,

the

Debian package of Apache Brooklyn won't work on that version.
Getting this to work would require the user to install a system-wide

JRE 8

on their machine.

That's perfectly OK, we require a Java 8 runtime but we don't make any
stipulations about how you get that. It's quite a normal option to consider
getting a machine, installing Java, and then running Brooklyn on it.

Cheers
Geoff





On Thu, 20 Feb 2020 at 17:02, Duncan Grant 
wrote:


+1 (binding)

I don't think Paul's reported issue above is a blocker - but I do think
we
should address this soon.

I've run some tests on mac using tar.gz and deployed some apps to aws and
gce.  All worked as expected so I'm happy for the release to go ahead.

Duncan

On Thu, 20 Feb 2020 at 16:03, Paul Campbell 
wrote:


Hi,

I think I've pinned down my errors to my machine having openjdk-11-jre
installed.

Given Debian Buster, the current version doesn't provide a Java 8 JRE,

the

Debian package of Apache Brooklyn won't work on that version.

Getting this to work would require the user to install a system-wide

JRE 8

on their machine. (i.e. download, unpack and update system environment
variables)

Paul

On Thu, 20 Feb 2020 at 14:41, Paul Campbell <

paul.campb...@cloudsoft.io>

wrote:


Hi,

Trying to test the RC3 deb package on Debian 10 (Buster).

I'm not able to start the 'brooklyn' service properly when installed

from

the Debian package.

sudo dpkg -i apache-brooklyn-1.0.0-rc3.deb
sudo service brooklyn start

Apache Brooklyn never completes startup, but doesn't die either. Port

8081

never 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Geoff Macartney]

My current appraisal of the RC is:

verify_brooklyn_rc.sh looks ok, tail of output (tidied):

[✓] Build from sources successful
~/brooklyn_releases/apache-brooklyn-1.0.0-rc3 ~/brooklyn_releases

---

Additional steps requiring manual intervention (execute in source
distribution folder apache-brooklyn-1.0.0-src:
...etc

Checks successfully completed:
[✓] Download links work.
[✓] Checksums and PGP signatures are valid.
[✓] Expanded source archive matches contents of RC tag.
[✓] Expanded source archive builds and passes tests.
[✓] LICENSE is present and correct.
[✓] NOTICE is present and correct, including copyright date.
[✓] No compiled archives bundled in source archive.

Checks left to do manually with the help of above instructions:
[✓] All files have license headers where appropriate.
[✓] All dependencies have compatible licenses.

Remaning items from checklist:
[✓] Binaries work.
[✓] I follow this project’s commits list.


So far so good. Also did:

[✓] Was able to use UI to create and install simple apps (on AWS - a
server, and Tomcat 8 with demo war).
[✓] br cli works (OSX binary, haven't tried the others)

On the other hand, I get a failure running the Vagrant release. I am not
sure I'm doing this right though; it's a long time since I've used this. I
just unpacked that tarball, cd-ed to that directory, and did "vagrant up".
It churns away for a bit, then I get a 404 at the "download release
archive" step. I tweaked the script to output the URL it's downloading and
it says

brooklyn: Downloading Brooklyn release archive
https://www.apache.org/dyn/closer.lua?action=download=brooklyn/apache-brooklyn-1.0.0/apache-brooklyn-1.0.0.noarch.rpm
brooklyn: curl: (22) The requested URL returned error: 404 Not Found
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.


Does anyone recognise this, or know what's up?

regards
Geoff








On Thu, 20 Feb 2020 at 18:33, Geoff Macartney 
wrote:

> Note that's different from the situation with the Docker image above. If
> we are distributing source with a Dockerfile, I'd really expect that to
> "Just Work". I'm tending towards thinking this will mean a -1 from me -
> open to debate the matter though, what do you all think?
>
> Geoff
>
>
> On Thu, 20 Feb 2020 at 18:30, Geoff Macartney 
> wrote:
>
>> Hi Paul,
>>
>> >Given Debian Buster, the current version doesn't provide a Java 8 JRE,
>> the
>> > Debian package of Apache Brooklyn won't work on that version.
>>
>> > Getting this to work would require the user to install a system-wide
>> JRE 8
>> > on their machine.
>>
>> That's perfectly OK, we require a Java 8 runtime but we don't make any
>> stipulations about how you get that. It's quite a normal option to consider
>> getting a machine, installing Java, and then running Brooklyn on it.
>>
>> Cheers
>> Geoff
>>
>>
>>
>>
>>
>> On Thu, 20 Feb 2020 at 17:02, Duncan Grant 
>> wrote:
>>
>>> +1 (binding)
>>>
>>> I don't think Paul's reported issue above is a blocker - but I do think
>>> we
>>> should address this soon.
>>>
>>> I've run some tests on mac using tar.gz and deployed some apps to aws and
>>> gce.  All worked as expected so I'm happy for the release to go ahead.
>>>
>>> Duncan
>>>
>>> On Thu, 20 Feb 2020 at 16:03, Paul Campbell 
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > I think I've pinned down my errors to my machine having openjdk-11-jre
>>> > installed.
>>> >
>>> > Given Debian Buster, the current version doesn't provide a Java 8 JRE,
>>> the
>>> > Debian package of Apache Brooklyn won't work on that version.
>>> >
>>> > Getting this to work would require the user to install a system-wide
>>> JRE 8
>>> > on their machine. (i.e. download, unpack and update system environment
>>> > variables)
>>> >
>>> > Paul
>>> >
>>> > On Thu, 20 Feb 2020 at 14:41, Paul Campbell <
>>> paul.campb...@cloudsoft.io>
>>> > wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > Trying to test the RC3 deb package on Debian 10 (Buster).
>>> > >
>>> > > I'm not able to start the 'brooklyn' service properly when installed
>>> from
>>> > > the Debian package.
>>> > >
>>> > > sudo dpkg -i apache-brooklyn-1.0.0-rc3.deb
>>> > > sudo service brooklyn start
>>> > >
>>> > > Apache Brooklyn never completes startup, but doesn't die either. Port
>>> > 8081
>>> > > never opens.
>>> > >
>>> > > The log file has the following errors:
>>> > >
>>> > > 2020-02-20T14:32:11,577 - ERROR  11 o.a.k.f.i.s.BootFeaturesInstaller
>>> > > [vator-1-thread-2] Error installing boot features
>>> > > org.apache.felix.resolver.reason.ReasonException: Unable to resolve
>>> root:
>>> > > missing requirement [root] osgi.identity;
>>> > osgi.identity=brooklyn-headless;
>>> > > type=karaf.feature; version=0;
>>> > >
>>> >
>>> filter:="(&(osgi.identity=brooklyn-headless)(type=karaf.feature)(version>=0.0.0))"
>>> > > [caused by: 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Geoff Macartney]

Note that's different from the situation with the Docker image above. If we
are distributing source with a Dockerfile, I'd really expect that to "Just
Work". I'm tending towards thinking this will mean a -1 from me - open to
debate the matter though, what do you all think?

Geoff


On Thu, 20 Feb 2020 at 18:30, Geoff Macartney 
wrote:

> Hi Paul,
>
> >Given Debian Buster, the current version doesn't provide a Java 8 JRE, the
> > Debian package of Apache Brooklyn won't work on that version.
>
> > Getting this to work would require the user to install a system-wide JRE
> 8
> > on their machine.
>
> That's perfectly OK, we require a Java 8 runtime but we don't make any
> stipulations about how you get that. It's quite a normal option to consider
> getting a machine, installing Java, and then running Brooklyn on it.
>
> Cheers
> Geoff
>
>
>
>
>
> On Thu, 20 Feb 2020 at 17:02, Duncan Grant 
> wrote:
>
>> +1 (binding)
>>
>> I don't think Paul's reported issue above is a blocker - but I do think we
>> should address this soon.
>>
>> I've run some tests on mac using tar.gz and deployed some apps to aws and
>> gce.  All worked as expected so I'm happy for the release to go ahead.
>>
>> Duncan
>>
>> On Thu, 20 Feb 2020 at 16:03, Paul Campbell 
>> wrote:
>>
>> > Hi,
>> >
>> > I think I've pinned down my errors to my machine having openjdk-11-jre
>> > installed.
>> >
>> > Given Debian Buster, the current version doesn't provide a Java 8 JRE,
>> the
>> > Debian package of Apache Brooklyn won't work on that version.
>> >
>> > Getting this to work would require the user to install a system-wide
>> JRE 8
>> > on their machine. (i.e. download, unpack and update system environment
>> > variables)
>> >
>> > Paul
>> >
>> > On Thu, 20 Feb 2020 at 14:41, Paul Campbell > >
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > Trying to test the RC3 deb package on Debian 10 (Buster).
>> > >
>> > > I'm not able to start the 'brooklyn' service properly when installed
>> from
>> > > the Debian package.
>> > >
>> > > sudo dpkg -i apache-brooklyn-1.0.0-rc3.deb
>> > > sudo service brooklyn start
>> > >
>> > > Apache Brooklyn never completes startup, but doesn't die either. Port
>> > 8081
>> > > never opens.
>> > >
>> > > The log file has the following errors:
>> > >
>> > > 2020-02-20T14:32:11,577 - ERROR  11 o.a.k.f.i.s.BootFeaturesInstaller
>> > > [vator-1-thread-2] Error installing boot features
>> > > org.apache.felix.resolver.reason.ReasonException: Unable to resolve
>> root:
>> > > missing requirement [root] osgi.identity;
>> > osgi.identity=brooklyn-headless;
>> > > type=karaf.feature; version=0;
>> > >
>> >
>> filter:="(&(osgi.identity=brooklyn-headless)(type=karaf.feature)(version>=0.0.0))"
>> > > [caused by: Unable to resolve brooklyn-headless/1.0.0: missing
>> > requirement
>> > > [brooklyn-headless/1.0.0] osgi.identity;
>> osgi.identity=brooklyn-commands;
>> > > type=karaf.feature [caused by: Unable to resolve
>> brooklyn-commands/1.0.0:
>> > > missing requirement [brooklyn-commands/1.0.0] osgi.identity;
>> > > osgi.identity=brooklyn-commands; type=osgi.bundle;
>> > version="[1.0.0,1.0.0]";
>> > > resolution:=mandatory [caused by: Unable to resolve
>> > > brooklyn-commands/1.0.0: missing requirement [brooklyn-commands/1.0.0]
>> > > osgi.wiring.package;
>> > >
>> >
>> filter:="(&(osgi.wiring.package=org.apache.brooklyn.launcher.command.support)(version>=1.0.0)(!(version>=2.0.0)))"
>> > > [caused by: Unable to resolve
>> org.apache.brooklyn.launcher-common/1.0.0:
>> > > missing requirement [org.apache.brooklyn.launcher-common/1.0.0]
>> > > osgi.wiring.package;
>> > >
>> >
>> filter:="(&(osgi.wiring.package=org.apache.brooklyn.entity.software.base)(version>=1.0.0)(!(version>=2.0.0)))"
>> > > [caused by: Unable to resolve org.apache.brooklyn.software-base/1.0.0:
>> > > missing requirement [org.apache.brooklyn.software-base/1.0.0]
>> > > osgi.wiring.package;
>> > > filter:="(osgi.wiring.package=javax.management.remote.jmxmp)" [caused
>> by:
>> > > Unable to resolve
>> > >
>> >
>> wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0:
>> > > missing requirement
>> > >
>> >
>> [wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0]
>> > > osgi.wiring.package;
>> filter:="(osgi.wiring.package=org.omg.CORBA)"]]
>> > > at
>> > >
>> >
>> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
>> > > ~[?:?]
>> > > at
>> > org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:392)
>> > > ~[?:?]
>> > > at
>> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
>> > > ~[?:?]
>> > > at
>> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
>> > > ~[?:?]
>> > > at
>> > >
>> >
>> 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Geoff Macartney]

Hi Paul,

>Given Debian Buster, the current version doesn't provide a Java 8 JRE, the
> Debian package of Apache Brooklyn won't work on that version.

> Getting this to work would require the user to install a system-wide JRE 8
> on their machine.

That's perfectly OK, we require a Java 8 runtime but we don't make any
stipulations about how you get that. It's quite a normal option to consider
getting a machine, installing Java, and then running Brooklyn on it.

Cheers
Geoff





On Thu, 20 Feb 2020 at 17:02, Duncan Grant 
wrote:

> +1 (binding)
>
> I don't think Paul's reported issue above is a blocker - but I do think we
> should address this soon.
>
> I've run some tests on mac using tar.gz and deployed some apps to aws and
> gce.  All worked as expected so I'm happy for the release to go ahead.
>
> Duncan
>
> On Thu, 20 Feb 2020 at 16:03, Paul Campbell 
> wrote:
>
> > Hi,
> >
> > I think I've pinned down my errors to my machine having openjdk-11-jre
> > installed.
> >
> > Given Debian Buster, the current version doesn't provide a Java 8 JRE,
> the
> > Debian package of Apache Brooklyn won't work on that version.
> >
> > Getting this to work would require the user to install a system-wide JRE
> 8
> > on their machine. (i.e. download, unpack and update system environment
> > variables)
> >
> > Paul
> >
> > On Thu, 20 Feb 2020 at 14:41, Paul Campbell 
> > wrote:
> >
> > > Hi,
> > >
> > > Trying to test the RC3 deb package on Debian 10 (Buster).
> > >
> > > I'm not able to start the 'brooklyn' service properly when installed
> from
> > > the Debian package.
> > >
> > > sudo dpkg -i apache-brooklyn-1.0.0-rc3.deb
> > > sudo service brooklyn start
> > >
> > > Apache Brooklyn never completes startup, but doesn't die either. Port
> > 8081
> > > never opens.
> > >
> > > The log file has the following errors:
> > >
> > > 2020-02-20T14:32:11,577 - ERROR  11 o.a.k.f.i.s.BootFeaturesInstaller
> > > [vator-1-thread-2] Error installing boot features
> > > org.apache.felix.resolver.reason.ReasonException: Unable to resolve
> root:
> > > missing requirement [root] osgi.identity;
> > osgi.identity=brooklyn-headless;
> > > type=karaf.feature; version=0;
> > >
> >
> filter:="(&(osgi.identity=brooklyn-headless)(type=karaf.feature)(version>=0.0.0))"
> > > [caused by: Unable to resolve brooklyn-headless/1.0.0: missing
> > requirement
> > > [brooklyn-headless/1.0.0] osgi.identity;
> osgi.identity=brooklyn-commands;
> > > type=karaf.feature [caused by: Unable to resolve
> brooklyn-commands/1.0.0:
> > > missing requirement [brooklyn-commands/1.0.0] osgi.identity;
> > > osgi.identity=brooklyn-commands; type=osgi.bundle;
> > version="[1.0.0,1.0.0]";
> > > resolution:=mandatory [caused by: Unable to resolve
> > > brooklyn-commands/1.0.0: missing requirement [brooklyn-commands/1.0.0]
> > > osgi.wiring.package;
> > >
> >
> filter:="(&(osgi.wiring.package=org.apache.brooklyn.launcher.command.support)(version>=1.0.0)(!(version>=2.0.0)))"
> > > [caused by: Unable to resolve
> org.apache.brooklyn.launcher-common/1.0.0:
> > > missing requirement [org.apache.brooklyn.launcher-common/1.0.0]
> > > osgi.wiring.package;
> > >
> >
> filter:="(&(osgi.wiring.package=org.apache.brooklyn.entity.software.base)(version>=1.0.0)(!(version>=2.0.0)))"
> > > [caused by: Unable to resolve org.apache.brooklyn.software-base/1.0.0:
> > > missing requirement [org.apache.brooklyn.software-base/1.0.0]
> > > osgi.wiring.package;
> > > filter:="(osgi.wiring.package=javax.management.remote.jmxmp)" [caused
> by:
> > > Unable to resolve
> > >
> >
> wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0:
> > > missing requirement
> > >
> >
> [wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0]
> > > osgi.wiring.package;
> filter:="(osgi.wiring.package=org.omg.CORBA)"]]
> > > at
> > >
> >
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
> > > ~[?:?]
> > > at
> > org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:392)
> > > ~[?:?]
> > > at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
> > > ~[?:?]
> > > at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
> > > ~[?:?]
> > > at
> > >
> >
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
> > > ~[?:?]
> > > at
> > >
> >
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:393)
> > > ~[?:?]
> > > at
> > >
> >
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1116)
> > > ~[?:?]
> > > at
> > >
> >
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> > > ~[?:?]
> > > at
> > >
> >
> 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Duncan Grant]

+1 (binding)

I don't think Paul's reported issue above is a blocker - but I do think we
should address this soon.

I've run some tests on mac using tar.gz and deployed some apps to aws and
gce.  All worked as expected so I'm happy for the release to go ahead.

Duncan

On Thu, 20 Feb 2020 at 16:03, Paul Campbell 
wrote:

> Hi,
>
> I think I've pinned down my errors to my machine having openjdk-11-jre
> installed.
>
> Given Debian Buster, the current version doesn't provide a Java 8 JRE, the
> Debian package of Apache Brooklyn won't work on that version.
>
> Getting this to work would require the user to install a system-wide JRE 8
> on their machine. (i.e. download, unpack and update system environment
> variables)
>
> Paul
>
> On Thu, 20 Feb 2020 at 14:41, Paul Campbell 
> wrote:
>
> > Hi,
> >
> > Trying to test the RC3 deb package on Debian 10 (Buster).
> >
> > I'm not able to start the 'brooklyn' service properly when installed from
> > the Debian package.
> >
> > sudo dpkg -i apache-brooklyn-1.0.0-rc3.deb
> > sudo service brooklyn start
> >
> > Apache Brooklyn never completes startup, but doesn't die either. Port
> 8081
> > never opens.
> >
> > The log file has the following errors:
> >
> > 2020-02-20T14:32:11,577 - ERROR  11 o.a.k.f.i.s.BootFeaturesInstaller
> > [vator-1-thread-2] Error installing boot features
> > org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
> > missing requirement [root] osgi.identity;
> osgi.identity=brooklyn-headless;
> > type=karaf.feature; version=0;
> >
> filter:="(&(osgi.identity=brooklyn-headless)(type=karaf.feature)(version>=0.0.0))"
> > [caused by: Unable to resolve brooklyn-headless/1.0.0: missing
> requirement
> > [brooklyn-headless/1.0.0] osgi.identity; osgi.identity=brooklyn-commands;
> > type=karaf.feature [caused by: Unable to resolve brooklyn-commands/1.0.0:
> > missing requirement [brooklyn-commands/1.0.0] osgi.identity;
> > osgi.identity=brooklyn-commands; type=osgi.bundle;
> version="[1.0.0,1.0.0]";
> > resolution:=mandatory [caused by: Unable to resolve
> > brooklyn-commands/1.0.0: missing requirement [brooklyn-commands/1.0.0]
> > osgi.wiring.package;
> >
> filter:="(&(osgi.wiring.package=org.apache.brooklyn.launcher.command.support)(version>=1.0.0)(!(version>=2.0.0)))"
> > [caused by: Unable to resolve org.apache.brooklyn.launcher-common/1.0.0:
> > missing requirement [org.apache.brooklyn.launcher-common/1.0.0]
> > osgi.wiring.package;
> >
> filter:="(&(osgi.wiring.package=org.apache.brooklyn.entity.software.base)(version>=1.0.0)(!(version>=2.0.0)))"
> > [caused by: Unable to resolve org.apache.brooklyn.software-base/1.0.0:
> > missing requirement [org.apache.brooklyn.software-base/1.0.0]
> > osgi.wiring.package;
> > filter:="(osgi.wiring.package=javax.management.remote.jmxmp)" [caused by:
> > Unable to resolve
> >
> wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0:
> > missing requirement
> >
> [wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0]
> > osgi.wiring.package; filter:="(osgi.wiring.package=org.omg.CORBA)"]]
> > at
> >
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
> > ~[?:?]
> > at
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:392)
> > ~[?:?]
> > at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
> > ~[?:?]
> > at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
> > ~[?:?]
> > at
> >
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
> > ~[?:?]
> > at
> >
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:393)
> > ~[?:?]
> > at
> >
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1116)
> > ~[?:?]
> > at
> >
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> > ~[?:?]
> > at
> >
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062)
> > ~[?:?]
> > at
> >
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998)
> > ~[?:?]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> > [?:?]
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> > [?:?]
> > at java.lang.Thread.run(Thread.java:834) [?:?]
> > Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to
> > resolve brooklyn-headless/1.0.0: missing requirement
> > [brooklyn-headless/1.0.0] osgi.identity; osgi.identity=brooklyn-commands;
> > 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Paul Campbell]

Hi,

I think I've pinned down my errors to my machine having openjdk-11-jre
installed.

Given Debian Buster, the current version doesn't provide a Java 8 JRE, the
Debian package of Apache Brooklyn won't work on that version.

Getting this to work would require the user to install a system-wide JRE 8
on their machine. (i.e. download, unpack and update system environment
variables)

Paul

On Thu, 20 Feb 2020 at 14:41, Paul Campbell 
wrote:

> Hi,
>
> Trying to test the RC3 deb package on Debian 10 (Buster).
>
> I'm not able to start the 'brooklyn' service properly when installed from
> the Debian package.
>
> sudo dpkg -i apache-brooklyn-1.0.0-rc3.deb
> sudo service brooklyn start
>
> Apache Brooklyn never completes startup, but doesn't die either. Port 8081
> never opens.
>
> The log file has the following errors:
>
> 2020-02-20T14:32:11,577 - ERROR  11 o.a.k.f.i.s.BootFeaturesInstaller
> [vator-1-thread-2] Error installing boot features
> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
> missing requirement [root] osgi.identity; osgi.identity=brooklyn-headless;
> type=karaf.feature; version=0;
> filter:="(&(osgi.identity=brooklyn-headless)(type=karaf.feature)(version>=0.0.0))"
> [caused by: Unable to resolve brooklyn-headless/1.0.0: missing requirement
> [brooklyn-headless/1.0.0] osgi.identity; osgi.identity=brooklyn-commands;
> type=karaf.feature [caused by: Unable to resolve brooklyn-commands/1.0.0:
> missing requirement [brooklyn-commands/1.0.0] osgi.identity;
> osgi.identity=brooklyn-commands; type=osgi.bundle; version="[1.0.0,1.0.0]";
> resolution:=mandatory [caused by: Unable to resolve
> brooklyn-commands/1.0.0: missing requirement [brooklyn-commands/1.0.0]
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.apache.brooklyn.launcher.command.support)(version>=1.0.0)(!(version>=2.0.0)))"
> [caused by: Unable to resolve org.apache.brooklyn.launcher-common/1.0.0:
> missing requirement [org.apache.brooklyn.launcher-common/1.0.0]
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.apache.brooklyn.entity.software.base)(version>=1.0.0)(!(version>=2.0.0)))"
> [caused by: Unable to resolve org.apache.brooklyn.software-base/1.0.0:
> missing requirement [org.apache.brooklyn.software-base/1.0.0]
> osgi.wiring.package;
> filter:="(osgi.wiring.package=javax.management.remote.jmxmp)" [caused by:
> Unable to resolve
> wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0:
> missing requirement
> [wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0]
> osgi.wiring.package; filter:="(osgi.wiring.package=org.omg.CORBA)"]]
> at
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
> ~[?:?]
> at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:392)
> ~[?:?]
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
> ~[?:?]
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
> ~[?:?]
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
> ~[?:?]
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:393)
> ~[?:?]
> at
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1116)
> ~[?:?]
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> ~[?:?]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062)
> ~[?:?]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998)
> ~[?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to
> resolve brooklyn-headless/1.0.0: missing requirement
> [brooklyn-headless/1.0.0] osgi.identity; osgi.identity=brooklyn-commands;
> type=karaf.feature [caused by: Unable to resolve brooklyn-commands/1.0.0:
> missing requirement [brooklyn-commands/1.0.0] osgi.identity;
> osgi.identity=brooklyn-commands; type=osgi.bundle; version="[1.0.0,1.0.0]";
> resolution:=mandatory [caused by: Unable to resolve
> brooklyn-commands/1.0.0: missing requirement [brooklyn-commands/1.0.0]
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.apache.brooklyn.launcher.command.support)(version>=1.0.0)(!(version>=2.0.0)))"
> [caused by: Unable to resolve org.apache.brooklyn.launcher-common/1.0.0:
> 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Paul Campbell]

Hi,

Trying to test the RC3 deb package on Debian 10 (Buster).

I'm not able to start the 'brooklyn' service properly when installed from
the Debian package.

sudo dpkg -i apache-brooklyn-1.0.0-rc3.deb
sudo service brooklyn start

Apache Brooklyn never completes startup, but doesn't die either. Port 8081
never opens.

The log file has the following errors:

2020-02-20T14:32:11,577 - ERROR  11 o.a.k.f.i.s.BootFeaturesInstaller
[vator-1-thread-2] Error installing boot features
org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=brooklyn-headless;
type=karaf.feature; version=0;
filter:="(&(osgi.identity=brooklyn-headless)(type=karaf.feature)(version>=0.0.0))"
[caused by: Unable to resolve brooklyn-headless/1.0.0: missing requirement
[brooklyn-headless/1.0.0] osgi.identity; osgi.identity=brooklyn-commands;
type=karaf.feature [caused by: Unable to resolve brooklyn-commands/1.0.0:
missing requirement [brooklyn-commands/1.0.0] osgi.identity;
osgi.identity=brooklyn-commands; type=osgi.bundle; version="[1.0.0,1.0.0]";
resolution:=mandatory [caused by: Unable to resolve
brooklyn-commands/1.0.0: missing requirement [brooklyn-commands/1.0.0]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.apache.brooklyn.launcher.command.support)(version>=1.0.0)(!(version>=2.0.0)))"
[caused by: Unable to resolve org.apache.brooklyn.launcher-common/1.0.0:
missing requirement [org.apache.brooklyn.launcher-common/1.0.0]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.apache.brooklyn.entity.software.base)(version>=1.0.0)(!(version>=2.0.0)))"
[caused by: Unable to resolve org.apache.brooklyn.software-base/1.0.0:
missing requirement [org.apache.brooklyn.software-base/1.0.0]
osgi.wiring.package;
filter:="(osgi.wiring.package=javax.management.remote.jmxmp)" [caused by:
Unable to resolve
wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0:
missing requirement
[wrap_file__opt_brooklyn-1.0.0_system_org_glassfish_external_opendmk_jmxremote_optional_jar_1.0-b01-ea_opendmk_jmxremote_optional_jar-1.0-b01-ea.jar_Import-Package_javax.management.openmbean__/0.0.0]
osgi.wiring.package; filter:="(osgi.wiring.package=org.omg.CORBA)"]]
at
org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
~[?:?]
at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:392)
~[?:?]
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
~[?:?]
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
~[?:?]
at
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
~[?:?]
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:393)
~[?:?]
at
org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1116)
~[?:?]
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
~[?:?]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062)
~[?:?]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998)
~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to
resolve brooklyn-headless/1.0.0: missing requirement
[brooklyn-headless/1.0.0] osgi.identity; osgi.identity=brooklyn-commands;
type=karaf.feature [caused by: Unable to resolve brooklyn-commands/1.0.0:
missing requirement [brooklyn-commands/1.0.0] osgi.identity;
osgi.identity=brooklyn-commands; type=osgi.bundle; version="[1.0.0,1.0.0]";
resolution:=mandatory [caused by: Unable to resolve
brooklyn-commands/1.0.0: missing requirement [brooklyn-commands/1.0.0]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.apache.brooklyn.launcher.command.support)(version>=1.0.0)(!(version>=2.0.0)))"
[caused by: Unable to resolve org.apache.brooklyn.launcher-common/1.0.0:
missing requirement [org.apache.brooklyn.launcher-common/1.0.0]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.apache.brooklyn.entity.software.base)(version>=1.0.0)(!(version>=2.0.0)))"
[caused by: Unable to resolve org.apache.brooklyn.software-base/1.0.0:
missing requirement [org.apache.brooklyn.software-base/1.0.0]
osgi.wiring.package;
filter:="(osgi.wiring.package=javax.management.remote.jmxmp)" [caused by:
Unable to resolve

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Geoff Macartney]

I'm a bit suspicious as to where the "FROM: maven:3.6.3-jdk-8" is coming
from - it looks as if the -rc3 branch is not entirely up to date with
https://github.com/apache/brooklyn/commits/master, which contains a tweak
to the base image version from about a week ago (
https://github.com/apache/brooklyn/commit/667083e648d52c0aba7f4da600ff17e5510d9b1b
).





On Wed, 19 Feb 2020 at 10:51, Paul Campbell 
wrote:

> Richard,
>
> I hadn't tried that. The image maintainer appears to have installed it 'by
> hand' rather than through apt-get.
>
> Commenting out that line allows me to build the image.
>
> However, building with this new image gives me this error, which is the
> same error I get when I try to build without using Docker:
>
> Tests run: 2371, Failures: 1, Errors: 0, Skipped: 39, Time elapsed: 146.302
> sec <<< FAILURE! - in TestSuite
>
> testInjectCertificateAuthority(org.apache.brooklyn.util.core.crypto.SecureKeysAndSignerTest)
>  Time elapsed: 0.319 sec  <<< FAILURE!
> java.lang.AssertionError: expected [true] but found [false]
> at
>
> org.apache.brooklyn.util.core.crypto.SecureKeysAndSignerTest.testInjectCertificateAuthority(SecureKeysAndSignerTest.java:89)
>
> 2020-02-19 10:48:50,747 INFO  - Brooklyn shutdown: stopping entities
> [TestEntityImpl{id=mkj2izoo11}, TestEntityImpl{id=jcq2uf7496},
> BlockingEntityImpl{id=xkfebswc0y}]
>
> Results :
>
> Failed tests:
>   SecureKeysAndSignerTest.testInjectCertificateAuthority:89 expected [true]
> but found [false]
>
> Tests run: 2367, Failures: 1, Errors: 0, Skipped: 35
>
> [INFO]
> 
> [INFO] Reactor Summary for Brooklyn Root 1.0.0:
> [INFO]
> [INFO] Brooklyn Server Root ... SUCCESS [
>  0.701 s]
> [INFO] Brooklyn Parent Project  SUCCESS [
>  1.791 s]
> [INFO] Brooklyn Test Support Utilities  SUCCESS [
>  3.579 s]
> [INFO] Brooklyn Logback Includable Configuration .. SUCCESS [
>  0.429 s]
> [INFO] Brooklyn Common Utilities .. SUCCESS [
> 20.798 s]
> [INFO] Brooklyn API ... SUCCESS [
>  1.419 s]
> [INFO] CAMP Server Parent Project . SUCCESS [
>  0.138 s]
> [INFO] CAMP Base .. SUCCESS [
>  2.046 s]
> [INFO] Brooklyn Test Support .. SUCCESS [
>  1.822 s]
> [INFO] Brooklyn REST Swagger Apidoc Utilities . SUCCESS [
>  0.826 s]
> [INFO] Brooklyn Logback Configuration . SUCCESS [
>  0.179 s]
> [INFO] CAMP Server  SUCCESS [
>  3.680 s]
> [INFO] Brooklyn Felix Runtime . SUCCESS [
>  2.057 s]
> [INFO] Brooklyn Groovy Utilities .. SUCCESS [
>  1.680 s]
> [INFO] Brooklyn Core .. FAILURE [03:02
> min]
>
> I've tried four times, but keep hitting this error.
>
>
> Paul
>
> On Wed, 19 Feb 2020 at 10:28, Richard Downer  wrote:
>
> > Paul,
> >
> > Forgive me if I'm missing anything as I avoid Docker where I generally
> can.
> >
> > Bringing up a shell on that Docker image, I can see JDK 8 is already
> > installed:
> >
> > root@6ec502dbd5bb:/# which java
> > /usr/local/openjdk-8/bin/java
> > root@6ec502dbd5bb:/# java -version
> > openjdk version "1.8.0_242"
> > OpenJDK Runtime Environment (build 1.8.0_242-b08)
> > OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
> > root@6ec502dbd5bb:/# javac -version
> > javac 1.8.0_242
> >
> > Is the workaround to simply remove attempt to install JDK 8 from the
> > Dockerfile?
> >
> > I'd also consider the Dockerfile to be a non-core part of Brooklyn and
> > therefore this should not be a release blocker. Does anyone
> agree/disagree?
> >
> > Richard.
> >
> >
> > On Wed, 19 Feb 2020 at 10:09, Paul Campbell 
> > wrote:
> >
> > > Hi,
> > >
> > > When I try to create the brooklyn docker image for building (i.e.
> docker
> > > build -t brooklyn .) I get the following error:
> > >
> > > pcampbell@cloudsoft:~/Downloads/apache-brooklyn-1.0.0-src$ docker
> > > build -t brooklyn .
> > > Sending build context to Docker daemon  38.09MB
> > > Step 1/8 : FROM maven:3.6.3-jdk-8
> > > 3.6.3-jdk-8: Pulling from library/maven
> > > dc65f448a2e2: Pull complete
> > > 346ffb2b67d7: Pull complete
> > > dea4ecac934f: Pull complete
> > > 8ac92ddf84b3: Pull complete
> > > d8ef64070a18: Pull complete
> > > 6577248b0d6e: Pull complete
> > > 576c0a3a6af9: Pull complete
> > > b96f1ed3d8ce: Pull complete
> > > a42ee290f6d0: Pull complete
> > > b85c95a261d3: Pull complete
> > > Digest:
> > > sha256:c822fa30ca61b434f87f415be39357cbee36f3ef88f2d65445437ab055d1266b
> > > Status: Downloaded newer image for maven:3.6.3-jdk-8
> > >  ---> a4ae0fe55e86
> > > Step 2/8 : RUN apt-get update && apt-get install -y openjdk-8-jre
> > >  ---> Running in a27050aa0206
> > > Get:1 http://deb.debian.org/debian buster 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Paul Campbell]

Richard,

I hadn't tried that. The image maintainer appears to have installed it 'by
hand' rather than through apt-get.

Commenting out that line allows me to build the image.

However, building with this new image gives me this error, which is the
same error I get when I try to build without using Docker:

Tests run: 2371, Failures: 1, Errors: 0, Skipped: 39, Time elapsed: 146.302
sec <<< FAILURE! - in TestSuite
testInjectCertificateAuthority(org.apache.brooklyn.util.core.crypto.SecureKeysAndSignerTest)
 Time elapsed: 0.319 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at
org.apache.brooklyn.util.core.crypto.SecureKeysAndSignerTest.testInjectCertificateAuthority(SecureKeysAndSignerTest.java:89)

2020-02-19 10:48:50,747 INFO  - Brooklyn shutdown: stopping entities
[TestEntityImpl{id=mkj2izoo11}, TestEntityImpl{id=jcq2uf7496},
BlockingEntityImpl{id=xkfebswc0y}]

Results :

Failed tests:
  SecureKeysAndSignerTest.testInjectCertificateAuthority:89 expected [true]
but found [false]

Tests run: 2367, Failures: 1, Errors: 0, Skipped: 35

[INFO]

[INFO] Reactor Summary for Brooklyn Root 1.0.0:
[INFO]
[INFO] Brooklyn Server Root ... SUCCESS [
 0.701 s]
[INFO] Brooklyn Parent Project  SUCCESS [
 1.791 s]
[INFO] Brooklyn Test Support Utilities  SUCCESS [
 3.579 s]
[INFO] Brooklyn Logback Includable Configuration .. SUCCESS [
 0.429 s]
[INFO] Brooklyn Common Utilities .. SUCCESS [
20.798 s]
[INFO] Brooklyn API ... SUCCESS [
 1.419 s]
[INFO] CAMP Server Parent Project . SUCCESS [
 0.138 s]
[INFO] CAMP Base .. SUCCESS [
 2.046 s]
[INFO] Brooklyn Test Support .. SUCCESS [
 1.822 s]
[INFO] Brooklyn REST Swagger Apidoc Utilities . SUCCESS [
 0.826 s]
[INFO] Brooklyn Logback Configuration . SUCCESS [
 0.179 s]
[INFO] CAMP Server  SUCCESS [
 3.680 s]
[INFO] Brooklyn Felix Runtime . SUCCESS [
 2.057 s]
[INFO] Brooklyn Groovy Utilities .. SUCCESS [
 1.680 s]
[INFO] Brooklyn Core .. FAILURE [03:02
min]

I've tried four times, but keep hitting this error.


Paul

On Wed, 19 Feb 2020 at 10:28, Richard Downer  wrote:

> Paul,
>
> Forgive me if I'm missing anything as I avoid Docker where I generally can.
>
> Bringing up a shell on that Docker image, I can see JDK 8 is already
> installed:
>
> root@6ec502dbd5bb:/# which java
> /usr/local/openjdk-8/bin/java
> root@6ec502dbd5bb:/# java -version
> openjdk version "1.8.0_242"
> OpenJDK Runtime Environment (build 1.8.0_242-b08)
> OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
> root@6ec502dbd5bb:/# javac -version
> javac 1.8.0_242
>
> Is the workaround to simply remove attempt to install JDK 8 from the
> Dockerfile?
>
> I'd also consider the Dockerfile to be a non-core part of Brooklyn and
> therefore this should not be a release blocker. Does anyone agree/disagree?
>
> Richard.
>
>
> On Wed, 19 Feb 2020 at 10:09, Paul Campbell 
> wrote:
>
> > Hi,
> >
> > When I try to create the brooklyn docker image for building (i.e. docker
> > build -t brooklyn .) I get the following error:
> >
> > pcampbell@cloudsoft:~/Downloads/apache-brooklyn-1.0.0-src$ docker
> > build -t brooklyn .
> > Sending build context to Docker daemon  38.09MB
> > Step 1/8 : FROM maven:3.6.3-jdk-8
> > 3.6.3-jdk-8: Pulling from library/maven
> > dc65f448a2e2: Pull complete
> > 346ffb2b67d7: Pull complete
> > dea4ecac934f: Pull complete
> > 8ac92ddf84b3: Pull complete
> > d8ef64070a18: Pull complete
> > 6577248b0d6e: Pull complete
> > 576c0a3a6af9: Pull complete
> > b96f1ed3d8ce: Pull complete
> > a42ee290f6d0: Pull complete
> > b85c95a261d3: Pull complete
> > Digest:
> > sha256:c822fa30ca61b434f87f415be39357cbee36f3ef88f2d65445437ab055d1266b
> > Status: Downloaded newer image for maven:3.6.3-jdk-8
> >  ---> a4ae0fe55e86
> > Step 2/8 : RUN apt-get update && apt-get install -y openjdk-8-jre
> >  ---> Running in a27050aa0206
> > Get:1 http://deb.debian.org/debian buster InRelease [122 kB]
> > Get:2 http://security.debian.org/debian-security buster/updates
> > InRelease [65.4 kB]
> > Get:3 http://deb.debian.org/debian buster-updates InRelease [49.3 kB]
> > Get:4 http://security.debian.org/debian-security buster/updates/main
> > amd64 Packages [177 kB]
> > Get:5 http://deb.debian.org/debian buster/main amd64 Packages [7907 kB]
> > Get:6 http://deb.debian.org/debian buster-updates/main amd64 Packages
> > [5792 B]
> > Fetched 8326 kB in 3s (2504 kB/s)
> > Reading package lists...
> > Reading package lists...
> > Building dependency tree...
> > Reading state information...
> > E: Unable to locate package openjdk-8-jre
> > The 

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Richard Downer]

Paul,

Forgive me if I'm missing anything as I avoid Docker where I generally can.

Bringing up a shell on that Docker image, I can see JDK 8 is already
installed:

root@6ec502dbd5bb:/# which java
/usr/local/openjdk-8/bin/java
root@6ec502dbd5bb:/# java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
root@6ec502dbd5bb:/# javac -version
javac 1.8.0_242

Is the workaround to simply remove attempt to install JDK 8 from the
Dockerfile?

I'd also consider the Dockerfile to be a non-core part of Brooklyn and
therefore this should not be a release blocker. Does anyone agree/disagree?

Richard.


On Wed, 19 Feb 2020 at 10:09, Paul Campbell 
wrote:

> Hi,
>
> When I try to create the brooklyn docker image for building (i.e. docker
> build -t brooklyn .) I get the following error:
>
> pcampbell@cloudsoft:~/Downloads/apache-brooklyn-1.0.0-src$ docker
> build -t brooklyn .
> Sending build context to Docker daemon  38.09MB
> Step 1/8 : FROM maven:3.6.3-jdk-8
> 3.6.3-jdk-8: Pulling from library/maven
> dc65f448a2e2: Pull complete
> 346ffb2b67d7: Pull complete
> dea4ecac934f: Pull complete
> 8ac92ddf84b3: Pull complete
> d8ef64070a18: Pull complete
> 6577248b0d6e: Pull complete
> 576c0a3a6af9: Pull complete
> b96f1ed3d8ce: Pull complete
> a42ee290f6d0: Pull complete
> b85c95a261d3: Pull complete
> Digest:
> sha256:c822fa30ca61b434f87f415be39357cbee36f3ef88f2d65445437ab055d1266b
> Status: Downloaded newer image for maven:3.6.3-jdk-8
>  ---> a4ae0fe55e86
> Step 2/8 : RUN apt-get update && apt-get install -y openjdk-8-jre
>  ---> Running in a27050aa0206
> Get:1 http://deb.debian.org/debian buster InRelease [122 kB]
> Get:2 http://security.debian.org/debian-security buster/updates
> InRelease [65.4 kB]
> Get:3 http://deb.debian.org/debian buster-updates InRelease [49.3 kB]
> Get:4 http://security.debian.org/debian-security buster/updates/main
> amd64 Packages [177 kB]
> Get:5 http://deb.debian.org/debian buster/main amd64 Packages [7907 kB]
> Get:6 http://deb.debian.org/debian buster-updates/main amd64 Packages
> [5792 B]
> Fetched 8326 kB in 3s (2504 kB/s)
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> E: Unable to locate package openjdk-8-jre
> The command '/bin/sh -c apt-get update && apt-get install -y
> openjdk-8-jre' returned a non-zero code: 100
>
> This is because of a problem with the base maven image:
>
> pcampbell@cloudsoft:~/Downloads/apache-brooklyn-1.0.0-src$ docker run
> -it maven:3.6.3-jdk-8 /bin/bash
> root@ee5eb6fdf173:/# apt-get update
> Get:1 http://security.debian.org/debian-security buster/updates
> InRelease [65.4 kB]
> Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
> Get:3 http://security.debian.org/debian-security buster/updates/main
> amd64 Packages [177 kB]
> Get:4 http://deb.debian.org/debian buster-updates InRelease [49.3 kB]
> Get:5 http://deb.debian.org/debian buster/main amd64 Packages [7907 kB]
> Get:6 http://deb.debian.org/debian buster-updates/main amd64 Packages
> [5792 B]
> Fetched 8326 kB in 6s (1480 kB/s)
> Reading package lists... Done
> root@ee5eb6fdf173:/# apt-cache search openjdk|grep jre
> openjdk-11-jre - OpenJDK Java runtime, using Hotspot JIT
> openjdk-11-jre-headless - OpenJDK Java runtime, using Hotspot JIT
> (headless)
> openjdk-11-jre-zero - Alternative JVM for OpenJDK, using Zero
> openjdk-11-jre-dcevm - Alternative VM for OpenJDK 11 with enhanced
> class redefinition
>
> Despite being tagged as 'jdk-8' it doesn't have a JDK8 package available.
>
> Paul
>
>
> On Tue, 18 Feb 2020 at 23:37, Richard Downer  wrote:
>
> > This is to call for a vote for the release of Apache Brooklyn 1.0.0.
> >
> > This release comprises of a source code distribution, and a corresponding
> > binary distribution, and Maven artifacts.
> >
> > The source and binary distributions, including signatures, digests, etc.
> > can be found at:
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3
> >
> > The artifact SHA-256 checksums are as follows:
> >
> >   f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> > *apache-brooklyn-1.0.0-rc3-1.noarch.rpm
> >   7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
> > *apache-brooklyn-1.0.0-rc3-bin.tar.gz
> >   9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
> > *apache-brooklyn-1.0.0-rc3-bin.zip
> >   e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
> > *apache-brooklyn-1.0.0-rc3-classic.tar.gz
> >   e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
> > *apache-brooklyn-1.0.0-rc3-classic.zip
> >   3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
> > *apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
> >   eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
> > *apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
> >   

Re: [VOTE] Release Apache Brooklyn 1.0.0 [rc3]

[Paul Campbell]

Hi,

When I try to create the brooklyn docker image for building (i.e. docker
build -t brooklyn .) I get the following error:

pcampbell@cloudsoft:~/Downloads/apache-brooklyn-1.0.0-src$ docker
build -t brooklyn .
Sending build context to Docker daemon  38.09MB
Step 1/8 : FROM maven:3.6.3-jdk-8
3.6.3-jdk-8: Pulling from library/maven
dc65f448a2e2: Pull complete
346ffb2b67d7: Pull complete
dea4ecac934f: Pull complete
8ac92ddf84b3: Pull complete
d8ef64070a18: Pull complete
6577248b0d6e: Pull complete
576c0a3a6af9: Pull complete
b96f1ed3d8ce: Pull complete
a42ee290f6d0: Pull complete
b85c95a261d3: Pull complete
Digest: sha256:c822fa30ca61b434f87f415be39357cbee36f3ef88f2d65445437ab055d1266b
Status: Downloaded newer image for maven:3.6.3-jdk-8
 ---> a4ae0fe55e86
Step 2/8 : RUN apt-get update && apt-get install -y openjdk-8-jre
 ---> Running in a27050aa0206
Get:1 http://deb.debian.org/debian buster InRelease [122 kB]
Get:2 http://security.debian.org/debian-security buster/updates
InRelease [65.4 kB]
Get:3 http://deb.debian.org/debian buster-updates InRelease [49.3 kB]
Get:4 http://security.debian.org/debian-security buster/updates/main
amd64 Packages [177 kB]
Get:5 http://deb.debian.org/debian buster/main amd64 Packages [7907 kB]
Get:6 http://deb.debian.org/debian buster-updates/main amd64 Packages [5792 B]
Fetched 8326 kB in 3s (2504 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package openjdk-8-jre
The command '/bin/sh -c apt-get update && apt-get install -y
openjdk-8-jre' returned a non-zero code: 100

This is because of a problem with the base maven image:

pcampbell@cloudsoft:~/Downloads/apache-brooklyn-1.0.0-src$ docker run
-it maven:3.6.3-jdk-8 /bin/bash
root@ee5eb6fdf173:/# apt-get update
Get:1 http://security.debian.org/debian-security buster/updates
InRelease [65.4 kB]
Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
Get:3 http://security.debian.org/debian-security buster/updates/main
amd64 Packages [177 kB]
Get:4 http://deb.debian.org/debian buster-updates InRelease [49.3 kB]
Get:5 http://deb.debian.org/debian buster/main amd64 Packages [7907 kB]
Get:6 http://deb.debian.org/debian buster-updates/main amd64 Packages [5792 B]
Fetched 8326 kB in 6s (1480 kB/s)
Reading package lists... Done
root@ee5eb6fdf173:/# apt-cache search openjdk|grep jre
openjdk-11-jre - OpenJDK Java runtime, using Hotspot JIT
openjdk-11-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless)
openjdk-11-jre-zero - Alternative JVM for OpenJDK, using Zero
openjdk-11-jre-dcevm - Alternative VM for OpenJDK 11 with enhanced
class redefinition

Despite being tagged as 'jdk-8' it doesn't have a JDK8 package available.

Paul


On Tue, 18 Feb 2020 at 23:37, Richard Downer  wrote:

> This is to call for a vote for the release of Apache Brooklyn 1.0.0.
>
> This release comprises of a source code distribution, and a corresponding
> binary distribution, and Maven artifacts.
>
> The source and binary distributions, including signatures, digests, etc.
> can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-1.0.0-rc3
>
> The artifact SHA-256 checksums are as follows:
>
>   f6b199faadee7391a1a0509a853619aef37b0d3c1a6ecf01ecff2b07d729c42a
> *apache-brooklyn-1.0.0-rc3-1.noarch.rpm
>   7481b2c24949de9c29bfd1c5c9a32e1199c9fa0504af01d9a9bca764721def61
> *apache-brooklyn-1.0.0-rc3-bin.tar.gz
>   9e2d594021056fa3ecc76c87648609be6e0884222f4f921b8bad1f529896cd9c
> *apache-brooklyn-1.0.0-rc3-bin.zip
>   e0148e4bd5aa6be2979edda29609432f060cee60b36a79608de150f3263aa480
> *apache-brooklyn-1.0.0-rc3-classic.tar.gz
>   e0b26edd4d2e340513f06d8e089d2be12e1b882cb1dc4ffd27061fe53c72bc84
> *apache-brooklyn-1.0.0-rc3-classic.zip
>   3742424ce5a58813591c21ab556072915c20eb390eb0484e2650b8f8ed605494
> *apache-brooklyn-1.0.0-rc3-client-cli-linux.tar.gz
>   eafded3bfc5f8a63ddd543c98e142f928eae9f423ba8da68f7e062be2796a06d
> *apache-brooklyn-1.0.0-rc3-client-cli-linux.zip
>   13f025116cd9d3ffa40d328c522e50c9d18a6d3a1fc77238e3310a2098a92c82
> *apache-brooklyn-1.0.0-rc3-client-cli-macosx.tar.gz
>   f554fa5d95ce11f5f08d7b9f66e7be4a0219acdc3064067a44e4b1524d437d24
> *apache-brooklyn-1.0.0-rc3-client-cli-macosx.zip
>   8c41c4902004ad283f6e08a71256be82d5e747cc553d54e16f22b40214210cf5
> *apache-brooklyn-1.0.0-rc3-client-cli-windows.tar.gz
>   ffb1a7dd912d74968b2282b9a224dbc019f6fc81bec1c81d03fd17bf34b58277
> *apache-brooklyn-1.0.0-rc3-client-cli-windows.zip
>   9d6a7a04fe10f95a34b6167f2896a219f7863e16e66e107e4243ce32695d5b49
> *apache-brooklyn-1.0.0-rc3-src.tar.gz
>   a9e622854b2774790e0f7421b21b680a04983c18e09a086628c4360248670fa3
> *apache-brooklyn-1.0.0-rc3-src.zip
>   164898a211dea73397fb22faa7b8198ff4d63d0941e1c690a20c39515cfadbcc
> *apache-brooklyn-1.0.0-rc3-vagrant.tar.gz
>   ac81a3c07b4b59213362abc6ecbac3a57de500cee63a9793f06a42e8821ffce1
> *apache-brooklyn-1.0.0-rc3-vagrant.zip
>