Jenkins build is back to normal : brooklyn-library-master #453

[Apache Jenkins Server]

See 

Re: [PROPOSAL] Deprecate @SetFromFlag

[bostko]

Hi,

I'd like to address one more glitch which I think is not discussed.
Setting a config for VanillaSoftwareProcess type which is be predefined 
for that type could cause confusion.

For example [1] using brooklyn.config:
- version is set to the install.version config
- downloadUrl is set to the download.url config

Valentin.
[1] https://github.com/apache/brooklyn-library/pull/134/files
On 2017-05-12 16:56, Thomas Bouron  wrote:
> Hi all.>
>
> I just pushed a PR on brooklyn-docs[1] that goes toward this proposal 
by>
> enforcing the use of `brooklyn.config` and real configkey names 
throughout>

> all yaml examples.>
>
> Best.>
>
> [1] https://github.com/apache/brooklyn-docs/pull/182>
>
> On Thu, 8 Dec 2016 at 13:49 Aled Sage  wrote:>
>

--
VA

[jira] [Commented] (BROOKLYN-541) ActiveMQ Artemis Component

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/BROOKLYN-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196927#comment-16196927
 ] 

ASF GitHub Bot commented on BROOKLYN-541:
-

GitHub user bostko opened a pull request:

https://github.com/apache/brooklyn-library/pull/134

Add Apache ActiveMQ Artemis catalog item

Catalog item is visible in Apache Brooklyn karaf build
BROOKLYN-541

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bostko/brooklyn-library add-artemis

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/brooklyn-library/pull/134.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #134


commit 50c30f81125c60509db85018a4ac9f6f8665f782
Author: Valentin Aitken 
Date:   2017-10-09T13:09:11Z

Add Apache ActiveMQ Artemis catalog item

Catalog item is visible in Apache Brooklyn karaf build
BROOKLYN-541




> ActiveMQ Artemis Component
> --
>
> Key: BROOKLYN-541
> URL: https://issues.apache.org/jira/browse/BROOKLYN-541
> Project: Brooklyn
>  Issue Type: New Feature
>Reporter: Michael Andre Pearce
>
> Currently there is an Apache ActiveMQ component, but the is no component for 
> Apache ActiveMQ Artemis which is the next gen JMS 2.0 compliant broker.
> https://activemq.apache.org/artemis/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] brooklyn-library pull request #134: Add Apache ActiveMQ Artemis catalog item

[bostko]

GitHub user bostko opened a pull request:

https://github.com/apache/brooklyn-library/pull/134

Add Apache ActiveMQ Artemis catalog item

Catalog item is visible in Apache Brooklyn karaf build
BROOKLYN-541

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bostko/brooklyn-library add-artemis

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/brooklyn-library/pull/134.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #134


commit 50c30f81125c60509db85018a4ac9f6f8665f782
Author: Valentin Aitken 
Date:   2017-10-09T13:09:11Z

Add Apache ActiveMQ Artemis catalog item

Catalog item is visible in Apache Brooklyn karaf build
BROOKLYN-541




---

Re: [PROPOSAL] Delete "classic-mode" (always use Karaf)

[Mark McKenna]

+1

*Mark McKenna*

*Twitter ::* @m4rkmckenna 

*Github :: *m4rkmckenna 

*PGP :: A7A9 24DE 638C 681A 8DEA FAD4 2B5D C759 B1EB 76A7
*

On 9 October 2017 at 13:09, Graeme Miller  wrote:

> +1
>
> On 9 October 2017 at 12:56, Thomas Bouron  >
> wrote:
>
> > +1
> >
> > On Mon, 9 Oct 2017 at 12:39 Geoff Macartney <
> geoff.macart...@cloudsoft.io>
> > wrote:
> >
> > > +1
> > >
> > > On Mon, 9 Oct 2017 at 12:38 Duncan Godwin  > com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On 9 October 2017 at 12:24, Richard Downer 
> wrote:
> > > >
> > > > > I offer my opinion through the medium of GIFs:
> > > > >
> > > > > https://media.giphy.com/media/vohOR29F78sGk/giphy.gif
> > > > >
> > > > > Richard.
> > > > >
> > > > >
> > > > > On 9 October 2017 at 12:13, Aled Sage  wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I propose that we *delete* Brooklyn classic-mode from master now,
> > in
> > > > > > preparation for the 1.0.0 release.
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > In 0.12.0, we switched the main distro to be the karaf-mode. We
> > also
> > > > > built
> > > > > > the classic-mode distro - the intent being for users to have a
> > usable
> > > > > > classic mode, rather than being forced immediately to switch to
> > karaf
> > > > > > without advanced warning.
> > > > > >
> > > > > > However, we unfortunately did not deprecate classic-mode as
> clearly
> > > as
> > > > we
> > > > > > should have (e.g. didn't explicitly say that it will be deleted
> in
> > an
> > > > > > upcoming release, and didn't deprecate the `Main` class).
> > > > > >
> > > > > > I think it's still ok to delete it for several reasons:
> > > > > >
> > > > > > 1. This is a "mode" of running Brooklyn, rather than underlying
> > > > > >Brooklyn functionality.
> > > > > > 2. The `Main` class [1] etc should not be considered part of our
> > > > > >*public* API (even though we didn't explicitly tell people
> that
> > it
> > > > > >was internal).
> > > > > > 3. As part of 0.12.0 release, we added to the docs instructions
> for
> > > > > >upgrading to Karaf [2].
> > > > > > 4. Supporting classic to the same standard as Karaf will become
> > > > > >increasingly painful as we do more and more with Bundles!
> > > > > > 5. It's a major release, so if we are going to delete it then
> 1.0.0
> > > is
> > > > > >the perfect time!
> > > > > >
> > > > > > Aled
> > > > > >
> > > > > > [1] https://github.com/apache/brooklyn-server/blob/master/server
> > > > > > -cli/src/main/java/org/apache/brooklyn/cli/Main.java
> > > > > >
> > > > > > [2] http://brooklyn.apache.org/v/0.12.0/ops/upgrade.html#upgrade
> > > > > > -from-apache-brooklyn-0110-and-below
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > --
> >
> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > https://cloudsoft.io/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
>

Jenkins build is back to normal : brooklyn-master-build #1259

[Apache Jenkins Server]

See 

Jenkins build is back to normal : brooklyn-server-master #764

[Apache Jenkins Server]

See 

Re: [PROPOSAL] Delete "classic-mode" (always use Karaf)

[Graeme Miller]

+1

On 9 October 2017 at 12:56, Thomas Bouron 
wrote:

> +1
>
> On Mon, 9 Oct 2017 at 12:39 Geoff Macartney 
> wrote:
>
> > +1
> >
> > On Mon, 9 Oct 2017 at 12:38 Duncan Godwin  com>
> > wrote:
> >
> > > +1
> > >
> > > On 9 October 2017 at 12:24, Richard Downer  wrote:
> > >
> > > > I offer my opinion through the medium of GIFs:
> > > >
> > > > https://media.giphy.com/media/vohOR29F78sGk/giphy.gif
> > > >
> > > > Richard.
> > > >
> > > >
> > > > On 9 October 2017 at 12:13, Aled Sage  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I propose that we *delete* Brooklyn classic-mode from master now,
> in
> > > > > preparation for the 1.0.0 release.
> > > > >
> > > > > ---
> > > > >
> > > > > In 0.12.0, we switched the main distro to be the karaf-mode. We
> also
> > > > built
> > > > > the classic-mode distro - the intent being for users to have a
> usable
> > > > > classic mode, rather than being forced immediately to switch to
> karaf
> > > > > without advanced warning.
> > > > >
> > > > > However, we unfortunately did not deprecate classic-mode as clearly
> > as
> > > we
> > > > > should have (e.g. didn't explicitly say that it will be deleted in
> an
> > > > > upcoming release, and didn't deprecate the `Main` class).
> > > > >
> > > > > I think it's still ok to delete it for several reasons:
> > > > >
> > > > > 1. This is a "mode" of running Brooklyn, rather than underlying
> > > > >Brooklyn functionality.
> > > > > 2. The `Main` class [1] etc should not be considered part of our
> > > > >*public* API (even though we didn't explicitly tell people that
> it
> > > > >was internal).
> > > > > 3. As part of 0.12.0 release, we added to the docs instructions for
> > > > >upgrading to Karaf [2].
> > > > > 4. Supporting classic to the same standard as Karaf will become
> > > > >increasingly painful as we do more and more with Bundles!
> > > > > 5. It's a major release, so if we are going to delete it then 1.0.0
> > is
> > > > >the perfect time!
> > > > >
> > > > > Aled
> > > > >
> > > > > [1] https://github.com/apache/brooklyn-server/blob/master/server
> > > > > -cli/src/main/java/org/apache/brooklyn/cli/Main.java
> > > > >
> > > > > [2] http://brooklyn.apache.org/v/0.12.0/ops/upgrade.html#upgrade
> > > > > -from-apache-brooklyn-0110-and-below
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> --
>
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> https://cloudsoft.io/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>

Re: [PROPOSAL] Delete "classic-mode" (always use Karaf)

[Thomas Bouron]

+1

On Mon, 9 Oct 2017 at 12:39 Geoff Macartney 
wrote:

> +1
>
> On Mon, 9 Oct 2017 at 12:38 Duncan Godwin 
> wrote:
>
> > +1
> >
> > On 9 October 2017 at 12:24, Richard Downer  wrote:
> >
> > > I offer my opinion through the medium of GIFs:
> > >
> > > https://media.giphy.com/media/vohOR29F78sGk/giphy.gif
> > >
> > > Richard.
> > >
> > >
> > > On 9 October 2017 at 12:13, Aled Sage  wrote:
> > >
> > > > Hi all,
> > > >
> > > > I propose that we *delete* Brooklyn classic-mode from master now, in
> > > > preparation for the 1.0.0 release.
> > > >
> > > > ---
> > > >
> > > > In 0.12.0, we switched the main distro to be the karaf-mode. We also
> > > built
> > > > the classic-mode distro - the intent being for users to have a usable
> > > > classic mode, rather than being forced immediately to switch to karaf
> > > > without advanced warning.
> > > >
> > > > However, we unfortunately did not deprecate classic-mode as clearly
> as
> > we
> > > > should have (e.g. didn't explicitly say that it will be deleted in an
> > > > upcoming release, and didn't deprecate the `Main` class).
> > > >
> > > > I think it's still ok to delete it for several reasons:
> > > >
> > > > 1. This is a "mode" of running Brooklyn, rather than underlying
> > > >Brooklyn functionality.
> > > > 2. The `Main` class [1] etc should not be considered part of our
> > > >*public* API (even though we didn't explicitly tell people that it
> > > >was internal).
> > > > 3. As part of 0.12.0 release, we added to the docs instructions for
> > > >upgrading to Karaf [2].
> > > > 4. Supporting classic to the same standard as Karaf will become
> > > >increasingly painful as we do more and more with Bundles!
> > > > 5. It's a major release, so if we are going to delete it then 1.0.0
> is
> > > >the perfect time!
> > > >
> > > > Aled
> > > >
> > > > [1] https://github.com/apache/brooklyn-server/blob/master/server
> > > > -cli/src/main/java/org/apache/brooklyn/cli/Main.java
> > > >
> > > > [2] http://brooklyn.apache.org/v/0.12.0/ops/upgrade.html#upgrade
> > > > -from-apache-brooklyn-0110-and-below
> > > >
> > > >
> > > >
> > >
> >
>
-- 

Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
https://cloudsoft.io/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron

[GitHub] brooklyn-server pull request #858: Fixes broken ClassLoaderFromStackOfBrookl...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/brooklyn-server/pull/858


---

[GitHub] brooklyn-server issue #858: Fixes broken ClassLoaderFromStackOfBrooklynClass...

[aledsage]

Github user aledsage commented on the issue:

https://github.com/apache/brooklyn-server/pull/858
  
Thanks @nakomis - LGTM.

For the record, the jars needed recompiled because their MANIFEST.mf 
depended on brooklyn `[0.12,1.0)`. When we bumped brooklyn version to 
1.0.0-SNAPSHOT, it meant all tests using any of these test bundles failed.


---

[GitHub] brooklyn-docs pull request #220: Delete 'migrating to 0.8.0'

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/brooklyn-docs/pull/220


---

Re: [PROPOSAL] Delete "classic-mode" (always use Karaf)

[Geoff Macartney]

+1

On Mon, 9 Oct 2017 at 12:38 Duncan Godwin 
wrote:

> +1
>
> On 9 October 2017 at 12:24, Richard Downer  wrote:
>
> > I offer my opinion through the medium of GIFs:
> >
> > https://media.giphy.com/media/vohOR29F78sGk/giphy.gif
> >
> > Richard.
> >
> >
> > On 9 October 2017 at 12:13, Aled Sage  wrote:
> >
> > > Hi all,
> > >
> > > I propose that we *delete* Brooklyn classic-mode from master now, in
> > > preparation for the 1.0.0 release.
> > >
> > > ---
> > >
> > > In 0.12.0, we switched the main distro to be the karaf-mode. We also
> > built
> > > the classic-mode distro - the intent being for users to have a usable
> > > classic mode, rather than being forced immediately to switch to karaf
> > > without advanced warning.
> > >
> > > However, we unfortunately did not deprecate classic-mode as clearly as
> we
> > > should have (e.g. didn't explicitly say that it will be deleted in an
> > > upcoming release, and didn't deprecate the `Main` class).
> > >
> > > I think it's still ok to delete it for several reasons:
> > >
> > > 1. This is a "mode" of running Brooklyn, rather than underlying
> > >Brooklyn functionality.
> > > 2. The `Main` class [1] etc should not be considered part of our
> > >*public* API (even though we didn't explicitly tell people that it
> > >was internal).
> > > 3. As part of 0.12.0 release, we added to the docs instructions for
> > >upgrading to Karaf [2].
> > > 4. Supporting classic to the same standard as Karaf will become
> > >increasingly painful as we do more and more with Bundles!
> > > 5. It's a major release, so if we are going to delete it then 1.0.0 is
> > >the perfect time!
> > >
> > > Aled
> > >
> > > [1] https://github.com/apache/brooklyn-server/blob/master/server
> > > -cli/src/main/java/org/apache/brooklyn/cli/Main.java
> > >
> > > [2] http://brooklyn.apache.org/v/0.12.0/ops/upgrade.html#upgrade
> > > -from-apache-brooklyn-0110-and-below
> > >
> > >
> > >
> >
>

Re: [PROPOSAL] Delete "classic-mode" (always use Karaf)

[Duncan Godwin]

+1

On 9 October 2017 at 12:24, Richard Downer  wrote:

> I offer my opinion through the medium of GIFs:
>
> https://media.giphy.com/media/vohOR29F78sGk/giphy.gif
>
> Richard.
>
>
> On 9 October 2017 at 12:13, Aled Sage  wrote:
>
> > Hi all,
> >
> > I propose that we *delete* Brooklyn classic-mode from master now, in
> > preparation for the 1.0.0 release.
> >
> > ---
> >
> > In 0.12.0, we switched the main distro to be the karaf-mode. We also
> built
> > the classic-mode distro - the intent being for users to have a usable
> > classic mode, rather than being forced immediately to switch to karaf
> > without advanced warning.
> >
> > However, we unfortunately did not deprecate classic-mode as clearly as we
> > should have (e.g. didn't explicitly say that it will be deleted in an
> > upcoming release, and didn't deprecate the `Main` class).
> >
> > I think it's still ok to delete it for several reasons:
> >
> > 1. This is a "mode" of running Brooklyn, rather than underlying
> >Brooklyn functionality.
> > 2. The `Main` class [1] etc should not be considered part of our
> >*public* API (even though we didn't explicitly tell people that it
> >was internal).
> > 3. As part of 0.12.0 release, we added to the docs instructions for
> >upgrading to Karaf [2].
> > 4. Supporting classic to the same standard as Karaf will become
> >increasingly painful as we do more and more with Bundles!
> > 5. It's a major release, so if we are going to delete it then 1.0.0 is
> >the perfect time!
> >
> > Aled
> >
> > [1] https://github.com/apache/brooklyn-server/blob/master/server
> > -cli/src/main/java/org/apache/brooklyn/cli/Main.java
> >
> > [2] http://brooklyn.apache.org/v/0.12.0/ops/upgrade.html#upgrade
> > -from-apache-brooklyn-0110-and-below
> >
> >
> >
>

Re: [PROPOSAL] Delete "classic-mode" (always use Karaf)

[Richard Downer]

I offer my opinion through the medium of GIFs:

https://media.giphy.com/media/vohOR29F78sGk/giphy.gif

Richard.


On 9 October 2017 at 12:13, Aled Sage  wrote:

> Hi all,
>
> I propose that we *delete* Brooklyn classic-mode from master now, in
> preparation for the 1.0.0 release.
>
> ---
>
> In 0.12.0, we switched the main distro to be the karaf-mode. We also built
> the classic-mode distro - the intent being for users to have a usable
> classic mode, rather than being forced immediately to switch to karaf
> without advanced warning.
>
> However, we unfortunately did not deprecate classic-mode as clearly as we
> should have (e.g. didn't explicitly say that it will be deleted in an
> upcoming release, and didn't deprecate the `Main` class).
>
> I think it's still ok to delete it for several reasons:
>
> 1. This is a "mode" of running Brooklyn, rather than underlying
>Brooklyn functionality.
> 2. The `Main` class [1] etc should not be considered part of our
>*public* API (even though we didn't explicitly tell people that it
>was internal).
> 3. As part of 0.12.0 release, we added to the docs instructions for
>upgrading to Karaf [2].
> 4. Supporting classic to the same standard as Karaf will become
>increasingly painful as we do more and more with Bundles!
> 5. It's a major release, so if we are going to delete it then 1.0.0 is
>the perfect time!
>
> Aled
>
> [1] https://github.com/apache/brooklyn-server/blob/master/server
> -cli/src/main/java/org/apache/brooklyn/cli/Main.java
>
> [2] http://brooklyn.apache.org/v/0.12.0/ops/upgrade.html#upgrade
> -from-apache-brooklyn-0110-and-below
>
>
>

[GitHub] brooklyn-docs pull request #220: Delete 'migrating to 0.8.0'

[aledsage]

GitHub user aledsage opened a pull request:

https://github.com/apache/brooklyn-docs/pull/220

Delete 'migrating to 0.8.0'

The page http://brooklyn.apache.org/v/0.12.0/misc/index.html includes a 
bullet point link "Migrating to 0.8.0". I think we can safely say that we don't 
want people to migrate to 0.8.0, so I'm deleting it.

The purpose of the page is to help people get from the `brooklyn.*` package 
names to the `org.apache.*` package names, which we did in the 0.8.0 release. 
If someone wants to see those docs, it is still available at 
http://brooklyn.apache.org/v/0.8.0-incubating/misc/migrate-to-0.8.0.html

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/aledsage/brooklyn-docs delete-migrate-to-0_8

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/brooklyn-docs/pull/220.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #220


commit 9986a23b87e2f42c7a10625561368fa1c8674573
Author: Aled Sage 
Date:   2017-10-09T11:16:02Z

Delete 'migrating to 0.8.0'




---

[PROPOSAL] Delete "classic-mode" (always use Karaf)

[Aled Sage]

Hi all,

I propose that we *delete* Brooklyn classic-mode from master now, in 
preparation for the 1.0.0 release.


---

In 0.12.0, we switched the main distro to be the karaf-mode. We also 
built the classic-mode distro - the intent being for users to have a 
usable classic mode, rather than being forced immediately to switch to 
karaf without advanced warning.


However, we unfortunately did not deprecate classic-mode as clearly as 
we should have (e.g. didn't explicitly say that it will be deleted in an 
upcoming release, and didn't deprecate the `Main` class).


I think it's still ok to delete it for several reasons:

1. This is a "mode" of running Brooklyn, rather than underlying
   Brooklyn functionality.
2. The `Main` class [1] etc should not be considered part of our
   *public* API (even though we didn't explicitly tell people that it
   was internal).
3. As part of 0.12.0 release, we added to the docs instructions for
   upgrading to Karaf [2].
4. Supporting classic to the same standard as Karaf will become
   increasingly painful as we do more and more with Bundles!
5. It's a major release, so if we are going to delete it then 1.0.0 is
   the perfect time!

Aled

[1] 
https://github.com/apache/brooklyn-server/blob/master/server-cli/src/main/java/org/apache/brooklyn/cli/Main.java


[2] 
http://brooklyn.apache.org/v/0.12.0/ops/upgrade.html#upgrade-from-apache-brooklyn-0110-and-below

Re: Deprecating `@Catalog` annotation?

[Aled Sage]

Hi all,

I've finally deprecated this - see 
https://github.com/apache/brooklyn-server/pull/857.


---
However, I haven't changed the use of `--jar` in `ItemLister`: that will 
still look for Java classes that implement Entity etc and/or classes 
annotated with `@Catalog`; it is run via the non-karaf CLI.


It should really look for a `catalog.bom` in the jar, and should re-use 
as much code as possible from `BrooklynCatalog` and `BrooklynTypeRegistry`.


I think that would involve a re-think / re-write. We could achieve the 
same functionality by querying the catalog of a running Brooklyn's 
catalog, rather than as a separate offline tool.


I suggest we ignore the existing `ItemLister` for now, and deprecate it 
at the same time as we deprecate the classic (non-karaf) mode of Brooklyn.


Aled


On 15/09/2017 15:33, Thomas Bouron wrote:

+1

On Fri, 15 Sep 2017 at 15:04 Richard Downer  wrote:


+1

On 15 September 2017 at 14:12, Aled Sage  wrote:


Hi all,

I'd like to deprecate the `@Catalog` annotation [1], and the support for
`scanFromAnnotations` [2].

Previously, we annotated some entity/policy Java classes with catalog
information, such as descriptions and icon urls. However, we've moved to
using .bom files as the way to define catalog items. Therefore the
`@Catalog` is not normally used.

It is also supported/used by the `./brooklyn list-objects` CLI, to scan
jars [3]. It find the annotated entities etc, gets the catalog metadata,
and writes that out in json format. However, I don't think that's what we
want to do moving forward. We should focus on getting the metadata from

the

.bom files, which is how things should be defined for the catalog.

Any objections to deprecating these?

Aled

[1] https://github.com/apache/brooklyn-server/blob/master/api/
src/main/java/org/apache/brooklyn/api/catalog/Catalog.java
[2] https://github.com/apache/brooklyn-server/blob/master/core/
src/main/java/org/apache/brooklyn/core/catalog/internal/
CatalogClasspathDo.java#L199-L209
[3] https://github.com/apache/brooklyn-server/blob/master/server
-cli/src/main/java/org/apache/brooklyn/cli/ItemLister.java#L88-L94

[GitHub] brooklyn-server pull request #858: Fixes broken ClassLoaderFromStackOfBrookl...

[nakomis]

GitHub user nakomis opened a pull request:

https://github.com/apache/brooklyn-server/pull/858

Fixes broken 
ClassLoaderFromStackOfBrooklynClassLoadingContextTest.testLoadClassFromBundle 
test

Updates test jars to fix broken 
ClassLoaderFromStackOfBrooklynClassLoadingContextTest.testLoadClassFromBundle 
test and other tests

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nakomis/brooklyn-server fix/classloader-tests

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/brooklyn-server/pull/858.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #858


commit 09b25fea0459e8c9346aa910094418c294d581cb
Author: Martin Harris 
Date:   2017-10-09T10:39:00Z

Fixes broken 
ClassLoaderFromStackOfBrooklynClassLoadingContextTest.testLoadClassFromBundle 
test




---

[GitHub] brooklyn-server pull request #857: Deprecate `@Catalog` annotation

[tbouron]

Github user tbouron commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/857#discussion_r143427971
  
--- Diff: 
core/src/main/java/org/apache/brooklyn/core/catalog/internal/BasicBrooklynCatalog.java
 ---
@@ -671,6 +671,8 @@ private void 
collectCatalogItemsFromItemMetadataBlock(String sourceYaml, Managed
 if (scanJavaAnnotations==null || !scanJavaAnnotations) {
 // don't scan
 } else {
+log.warn("Deprecated use of scanJavaAnnotations" + 
(containingBundle != null ? " in bundle " + containingBundle.getVersionedName() 
: ""));
--- End diff --

Shouldn't we say `Use catalog.bom instead` here?


---