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

See

[GitHub] brooklyn-dist pull request #98: Don't avoid importing jclouds google compute...

GitHub user geomacy opened a pull request: https://github.com/apache/brooklyn-dist/pull/98 Don't avoid importing jclouds google compute engine. This is a bundle by now. This change is required in a downstream project to be able to access GCE correctly from within Karaf.

Re: Proposal: Add appId optional paramater to deploy api

Hi, Taking a step back to justify why this kind of thing is really important... This has come up because we want to call Brooklyn in a robust way from another system, and to handle a whole load of failure scenarios (e.g. that Brooklyn is temporarily down, connection fails at some point during

Re: Proposal: Add appId optional paramater to deploy api

Hi Duncan, I've solved this problem before by adding a caller generated config key on the app (now it's also possible to tag them), then iterating over the deployed apps, looking for the key. An alternative which I'd like to mention is creating an async deploy operation which immediately

Re: Proposal: Add appId optional paramater to deploy api

good idea. however the application's ID is not meant to be user-supplied. maybe this could be called `deploymentId` and set (compare against) a config key called `deploymentId` ? --a On 07/07/2017 16:33, Duncan Grant wrote: I'd like to propose adding an appId parameter to the deploy

Proposal: Add appId optional paramater to deploy api

I'd like to propose adding an appId parameter to the deploy endpoint. This would be optional and would presumably reject any attempt to start a second app with the same id. If set the appId would obviously be used in place of the generated id. This proposal would be of use in scripting

Re: BROOKLYN-519 suggestion to remove BasicSpecParameter from serializing

Hi Valentin, Parameters set on the specs are later converted to config keys on the entity which are then used for type inference and applying restrictions (can mark parameters as required). That's why I think it would be useful to keep the parameters passed in from yaml. We had a similar

BROOKLYN-519 suggestion to remove BasicSpecParameter from serializing

Hi, Like I described in BROOKLYN-519 AbstractBrooklynObjectSpec config serialization could be source of deserialization problems in backwards compatibility. I reviewed the code and I consider EntitySpecParameters are consumed only from the API describing Spec types and catalog items. I

[GitHub] brooklyn-server pull request #758: Adds patent pom relative path to `brookly...

Github user asfgit closed the pull request at: https://github.com/apache/brooklyn-server/pull/758 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the

[GitHub] brooklyn-server issue #758: Adds patent pom relative path to `brooklyn-locat...

Github user geomacy commented on the issue: https://github.com/apache/brooklyn-server/pull/758 merging --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or

[GitHub] brooklyn-server issue #746: Auto wrap YAML BOMs as catalog bundles

Github user ahgittin commented on the issue: https://github.com/apache/brooklyn-server/pull/746 right, see note on last commit which should solve the karaf mode problem you spotted @geomacy. also does a little something to solve the situation you encountered @richardcloudsoft .

[GitHub] brooklyn-server pull request #758: Adds patent pom relative path to `brookly...

GitHub user m4rkmckenna opened a pull request: https://github.com/apache/brooklyn-server/pull/758 Adds patent pom relative path to `brooklyn-locations-container` Without this the build will fail when preforming a release You can merge this pull request into a Git repository by

[GitHub] brooklyn-server pull request #757: [WIP] BROOKLYN-519 no BasicSpecParameter ...

GitHub user bostko opened a pull request: https://github.com/apache/brooklyn-server/pull/757 [WIP] BROOKLYN-519 no BasicSpecParameter serialization BasicSpecParameters are only consumed in API and no need to keep them or keep their state. - TODO rebind tests -

[jira] [Commented] (BROOKLYN-519) Persisting yaml blueprint with $brooklyn:entitySpec stores all configs

[ https://issues.apache.org/jira/browse/BROOKLYN-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077892#comment-16077892 ] ASF GitHub Bot commented on BROOKLYN-519: - GitHub user bostko opened a pull request:

[GitHub] brooklyn-server issue #756: Support recursive option and limits when getting...

Github user ahgittin commented on the issue: https://github.com/apache/brooklyn-server/pull/756 another unrelated failure `org.apache.brooklyn.util.pool.BasicPoolTest.testConcurrentCallsNeverHaveSameVal` retest this please --- If your project is set up for it, you can reply