brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Corbett <sam.corb...@cloudsoftcorp.com>
Subject Re: GET /v1/server/version
Date Thu, 07 May 2015 12:52:56 GMT
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
>>>
>>
>


Mime
View raw message