You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Sam Corbett <sa...@cloudsoftcorp.com> on 2015/05/06 21:05:15 UTC
GET /v1/server/version
Hi,
At the moment if you GET /v1/server/version the response is something like:
{
"buildBranch": "versions",
"buildSha1": "d0cbcf36cf701d9162be74a144cf1bd26741637e",
"version": "0.7.0-SNAPSHOT"
}
I'd like to extend this to include two new keys: "buildDate" and "features".
Hopefully the first of these is self-explanatory!
The second would be the result of an inspection of Brooklyn's
BrooklynClassLoadingContext (i.e. its classpath, catalogue and OSGi
bundles) for all MANIFEST.MF resources that contain attributes named
"Brooklyn-Feature-KEY", where KEY is one of Name, Branch, Sha1, Version and
Date. The result would be a dynamic list of the server's Brooklyn-aware
modules that I think corresponds to a profile of a server's capabilities.
Any thoughts or adjustments? With appropriate configuration in
brooklyn-downstream-parent's pom the scheme could be applied to downstream
projects automatically. If I did this work I would also remove the existing
build-metadata.properties file that populates the information above.
Cheers,
Sam
Re: GET /v1/server/version
Posted by Sam Corbett <sa...@cloudsoftcorp.com>.
Hi,
I've opened a pull request for this idea:
https://github.com/apache/incubator-brooklyn/pull/675
Feedback welcome.
Thanks,
Sam
On 7 May 2015 at 15:14, Alex Heneveld <al...@cloudsoftcorp.com>
wrote:
>
> Sounds great. I support collecting Brooklyn-Feature-* headers.
>
> For OSGi symbolic-name is essential.
>
> BTW - sourceUrl might be a useful one to add.
>
> Best
> Alex
>
>
>
> On 07/05/2015 13:52, Sam Corbett wrote:
>
>> I imagined that the output would be a list like:
>>
>> "features": [
>> {
>> "name": "Entities for Foo",
>> "version": "3.0.1",
>> "buildDate": "<date in ISO 8601 format>",
>> "buildBranch": "master",
>> "buildId": "<sha1/other identifier>",
>> },
>> {
>> "name": "Clocker",
>> "version": "0.8.1",
>> ...
>> }
>> ]
>>
>> I prefer a list to a map in case a server ends up in a state where two
>> bundles report the same name/version.
>>
>> I'm unsure about the keys starting build (buildId replaces the Sha1
>> attribute in my first email). Should downstream projects automatically give
>> this information away? The main Brooklyn build uses the
>> buildnumber-maven-plugin to get a SHA1, but the plugin's documentation is
>> vague about what other SCMs it supports. I think Git, SVN, Mercurial and
>> CVS.
>>
>> Alternatively we could scan for and include all attributes prefixed
>> "Brooklyn-Feature" rather than a known set of attributes. This would be
>> less efficient but more flexible.
>>
>> Sam
>>
>> On 06/05/2015 23:45, Alex Heneveld wrote:
>>
>>>
>>> Sam-
>>>
>>> Big +1. This would be very useful to identify the versions of things
>>> supplying catalog items and other snippets.
>>>
>>> How would we communicate which feature the other metadata belongs to?
>>> Extracting name / symbolic name / jar filename / all the above as keys in
>>> the map for each feature -- plus version in the case of OSGi bundles?
>>>
>>> Should features itself be a list, or could it be a map keyed off
>>> symbolic-name:version or jar-filename-url ?
>>>
>>> Aled- I think a "feature" would just be any jar or bundle which
>>> included this metadata. Our archetype should include this so all
>>> user-supplied bundles have this info, plus downstream projects could also
>>> use it.
>>>
>>> Best
>>> Alex
>>>
>>>
>>> On 06/05/2015 23:17, Aled Sage wrote:
>>>
>>>> Hi Sam,
>>>>
>>>> Nice suggestions.
>>>>
>>>> Definitely agree with adding "buildDate".
>>>>
>>>> For "features", I wonder if that justifies its own URL. For example GET
>>>> /v1/server/features.
>>>>
>>>> What kind of features are you thinking of, which would be included via
>>>> the manifest.mf approach?
>>>>
>>>> Aled
>>>>
>>>>
>>>> On 06/05/2015 20:05, Sam Corbett wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> At the moment if you GET /v1/server/version the response is something
>>>>> like:
>>>>>
>>>>> {
>>>>> "buildBranch": "versions",
>>>>> "buildSha1": "d0cbcf36cf701d9162be74a144cf1bd26741637e",
>>>>> "version": "0.7.0-SNAPSHOT"
>>>>> }
>>>>>
>>>>> I'd like to extend this to include two new keys: "buildDate" and
>>>>> "features".
>>>>>
>>>>> Hopefully the first of these is self-explanatory!
>>>>>
>>>>> The second would be the result of an inspection of Brooklyn's
>>>>> BrooklynClassLoadingContext (i.e. its classpath, catalogue and OSGi
>>>>> bundles) for all MANIFEST.MF resources that contain attributes named
>>>>> "Brooklyn-Feature-KEY", where KEY is one of Name, Branch, Sha1,
>>>>> Version and
>>>>> Date. The result would be a dynamic list of the server's Brooklyn-aware
>>>>> modules that I think corresponds to a profile of a server's
>>>>> capabilities.
>>>>>
>>>>> Any thoughts or adjustments? With appropriate configuration in
>>>>> brooklyn-downstream-parent's pom the scheme could be applied to
>>>>> downstream
>>>>> projects automatically. If I did this work I would also remove the
>>>>> existing
>>>>> build-metadata.properties file that populates the information above.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Sam
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: GET /v1/server/version
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
Sounds great. I support collecting Brooklyn-Feature-* headers.
For OSGi symbolic-name is essential.
BTW - sourceUrl might be a useful one to add.
Best
Alex
On 07/05/2015 13:52, Sam Corbett wrote:
> I imagined that the output would be a list like:
>
> "features": [
> {
> "name": "Entities for Foo",
> "version": "3.0.1",
> "buildDate": "<date in ISO 8601 format>",
> "buildBranch": "master",
> "buildId": "<sha1/other identifier>",
> },
> {
> "name": "Clocker",
> "version": "0.8.1",
> ...
> }
> ]
>
> I prefer a list to a map in case a server ends up in a state where two
> bundles report the same name/version.
>
> I'm unsure about the keys starting build (buildId replaces the Sha1
> attribute in my first email). Should downstream projects automatically
> give this information away? The main Brooklyn build uses the
> buildnumber-maven-plugin to get a SHA1, but the plugin's documentation
> is vague about what other SCMs it supports. I think Git, SVN,
> Mercurial and CVS.
>
> Alternatively we could scan for and include all attributes prefixed
> "Brooklyn-Feature" rather than a known set of attributes. This would
> be less efficient but more flexible.
>
> Sam
>
> On 06/05/2015 23:45, Alex Heneveld wrote:
>>
>> Sam-
>>
>> Big +1. This would be very useful to identify the versions of things
>> supplying catalog items and other snippets.
>>
>> How would we communicate which feature the other metadata belongs
>> to? Extracting name / symbolic name / jar filename / all the above
>> as keys in the map for each feature -- plus version in the case of
>> OSGi bundles?
>>
>> Should features itself be a list, or could it be a map keyed off
>> symbolic-name:version or jar-filename-url ?
>>
>> Aled- I think a "feature" would just be any jar or bundle which
>> included this metadata. Our archetype should include this so all
>> user-supplied bundles have this info, plus downstream projects could
>> also use it.
>>
>> Best
>> Alex
>>
>>
>> On 06/05/2015 23:17, Aled Sage wrote:
>>> Hi Sam,
>>>
>>> Nice suggestions.
>>>
>>> Definitely agree with adding "buildDate".
>>>
>>> For "features", I wonder if that justifies its own URL. For example
>>> GET /v1/server/features.
>>>
>>> What kind of features are you thinking of, which would be included
>>> via the manifest.mf approach?
>>>
>>> Aled
>>>
>>>
>>> On 06/05/2015 20:05, Sam Corbett wrote:
>>>> Hi,
>>>>
>>>> At the moment if you GET /v1/server/version the response is
>>>> something like:
>>>>
>>>> {
>>>> "buildBranch": "versions",
>>>> "buildSha1": "d0cbcf36cf701d9162be74a144cf1bd26741637e",
>>>> "version": "0.7.0-SNAPSHOT"
>>>> }
>>>>
>>>> I'd like to extend this to include two new keys: "buildDate" and
>>>> "features".
>>>>
>>>> Hopefully the first of these is self-explanatory!
>>>>
>>>> The second would be the result of an inspection of Brooklyn's
>>>> BrooklynClassLoadingContext (i.e. its classpath, catalogue and OSGi
>>>> bundles) for all MANIFEST.MF resources that contain attributes named
>>>> "Brooklyn-Feature-KEY", where KEY is one of Name, Branch, Sha1,
>>>> Version and
>>>> Date. The result would be a dynamic list of the server's
>>>> Brooklyn-aware
>>>> modules that I think corresponds to a profile of a server's
>>>> capabilities.
>>>>
>>>> Any thoughts or adjustments? With appropriate configuration in
>>>> brooklyn-downstream-parent's pom the scheme could be applied to
>>>> downstream
>>>> projects automatically. If I did this work I would also remove the
>>>> existing
>>>> build-metadata.properties file that populates the information above.
>>>>
>>>> Cheers,
>>>>
>>>> Sam
>>>>
>>>
>>
>
Re: GET /v1/server/version
Posted by Sam Corbett <sa...@cloudsoftcorp.com>.
I imagined that the output would be a list like:
"features": [
{
"name": "Entities for Foo",
"version": "3.0.1",
"buildDate": "<date in ISO 8601 format>",
"buildBranch": "master",
"buildId": "<sha1/other identifier>",
},
{
"name": "Clocker",
"version": "0.8.1",
...
}
]
I prefer a list to a map in case a server ends up in a state where two
bundles report the same name/version.
I'm unsure about the keys starting build (buildId replaces the Sha1
attribute in my first email). Should downstream projects automatically
give this information away? The main Brooklyn build uses the
buildnumber-maven-plugin to get a SHA1, but the plugin's documentation
is vague about what other SCMs it supports. I think Git, SVN, Mercurial
and CVS.
Alternatively we could scan for and include all attributes prefixed
"Brooklyn-Feature" rather than a known set of attributes. This would be
less efficient but more flexible.
Sam
On 06/05/2015 23:45, Alex Heneveld wrote:
>
> Sam-
>
> Big +1. This would be very useful to identify the versions of things
> supplying catalog items and other snippets.
>
> How would we communicate which feature the other metadata belongs to?
> Extracting name / symbolic name / jar filename / all the above as keys
> in the map for each feature -- plus version in the case of OSGi bundles?
>
> Should features itself be a list, or could it be a map keyed off
> symbolic-name:version or jar-filename-url ?
>
> Aled- I think a "feature" would just be any jar or bundle which
> included this metadata. Our archetype should include this so all
> user-supplied bundles have this info, plus downstream projects could
> also use it.
>
> Best
> Alex
>
>
> On 06/05/2015 23:17, Aled Sage wrote:
>> Hi Sam,
>>
>> Nice suggestions.
>>
>> Definitely agree with adding "buildDate".
>>
>> For "features", I wonder if that justifies its own URL. For example
>> GET /v1/server/features.
>>
>> What kind of features are you thinking of, which would be included
>> via the manifest.mf approach?
>>
>> Aled
>>
>>
>> On 06/05/2015 20:05, Sam Corbett wrote:
>>> Hi,
>>>
>>> At the moment if you GET /v1/server/version the response is
>>> something like:
>>>
>>> {
>>> "buildBranch": "versions",
>>> "buildSha1": "d0cbcf36cf701d9162be74a144cf1bd26741637e",
>>> "version": "0.7.0-SNAPSHOT"
>>> }
>>>
>>> I'd like to extend this to include two new keys: "buildDate" and
>>> "features".
>>>
>>> Hopefully the first of these is self-explanatory!
>>>
>>> The second would be the result of an inspection of Brooklyn's
>>> BrooklynClassLoadingContext (i.e. its classpath, catalogue and OSGi
>>> bundles) for all MANIFEST.MF resources that contain attributes named
>>> "Brooklyn-Feature-KEY", where KEY is one of Name, Branch, Sha1,
>>> Version and
>>> Date. The result would be a dynamic list of the server's Brooklyn-aware
>>> modules that I think corresponds to a profile of a server's
>>> capabilities.
>>>
>>> Any thoughts or adjustments? With appropriate configuration in
>>> brooklyn-downstream-parent's pom the scheme could be applied to
>>> downstream
>>> projects automatically. If I did this work I would also remove the
>>> existing
>>> build-metadata.properties file that populates the information above.
>>>
>>> Cheers,
>>>
>>> Sam
>>>
>>
>
Re: GET /v1/server/version
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
Sam-
Big +1. This would be very useful to identify the versions of things
supplying catalog items and other snippets.
How would we communicate which feature the other metadata belongs to?
Extracting name / symbolic name / jar filename / all the above as keys
in the map for each feature -- plus version in the case of OSGi bundles?
Should features itself be a list, or could it be a map keyed off
symbolic-name:version or jar-filename-url ?
Aled- I think a "feature" would just be any jar or bundle which
included this metadata. Our archetype should include this so all
user-supplied bundles have this info, plus downstream projects could
also use it.
Best
Alex
On 06/05/2015 23:17, Aled Sage wrote:
> Hi Sam,
>
> Nice suggestions.
>
> Definitely agree with adding "buildDate".
>
> For "features", I wonder if that justifies its own URL. For example
> GET /v1/server/features.
>
> What kind of features are you thinking of, which would be included via
> the manifest.mf approach?
>
> Aled
>
>
> On 06/05/2015 20:05, Sam Corbett wrote:
>> Hi,
>>
>> At the moment if you GET /v1/server/version the response is something
>> like:
>>
>> {
>> "buildBranch": "versions",
>> "buildSha1": "d0cbcf36cf701d9162be74a144cf1bd26741637e",
>> "version": "0.7.0-SNAPSHOT"
>> }
>>
>> I'd like to extend this to include two new keys: "buildDate" and
>> "features".
>>
>> Hopefully the first of these is self-explanatory!
>>
>> The second would be the result of an inspection of Brooklyn's
>> BrooklynClassLoadingContext (i.e. its classpath, catalogue and OSGi
>> bundles) for all MANIFEST.MF resources that contain attributes named
>> "Brooklyn-Feature-KEY", where KEY is one of Name, Branch, Sha1,
>> Version and
>> Date. The result would be a dynamic list of the server's Brooklyn-aware
>> modules that I think corresponds to a profile of a server's
>> capabilities.
>>
>> Any thoughts or adjustments? With appropriate configuration in
>> brooklyn-downstream-parent's pom the scheme could be applied to
>> downstream
>> projects automatically. If I did this work I would also remove the
>> existing
>> build-metadata.properties file that populates the information above.
>>
>> Cheers,
>>
>> Sam
>>
>
Re: GET /v1/server/version
Posted by Aled Sage <al...@gmail.com>.
Hi Sam,
Nice suggestions.
Definitely agree with adding "buildDate".
For "features", I wonder if that justifies its own URL. For example GET
/v1/server/features.
What kind of features are you thinking of, which would be included via
the manifest.mf approach?
Aled
On 06/05/2015 20:05, Sam Corbett wrote:
> Hi,
>
> At the moment if you GET /v1/server/version the response is something like:
>
> {
> "buildBranch": "versions",
> "buildSha1": "d0cbcf36cf701d9162be74a144cf1bd26741637e",
> "version": "0.7.0-SNAPSHOT"
> }
>
> I'd like to extend this to include two new keys: "buildDate" and "features".
>
> Hopefully the first of these is self-explanatory!
>
> The second would be the result of an inspection of Brooklyn's
> BrooklynClassLoadingContext (i.e. its classpath, catalogue and OSGi
> bundles) for all MANIFEST.MF resources that contain attributes named
> "Brooklyn-Feature-KEY", where KEY is one of Name, Branch, Sha1, Version and
> Date. The result would be a dynamic list of the server's Brooklyn-aware
> modules that I think corresponds to a profile of a server's capabilities.
>
> Any thoughts or adjustments? With appropriate configuration in
> brooklyn-downstream-parent's pom the scheme could be applied to downstream
> projects automatically. If I did this work I would also remove the existing
> build-metadata.properties file that populates the information above.
>
> Cheers,
>
> Sam
>