[Geoserver-devel] GWC info in VERSION.txt, About GeoServer?

Ben_Caradoc-Davies · July 27, 2012, 3:21am

GeoServer VERSION.txt contains information that is very useful in identifying the GeoServer and GeoTools snapshots contained in a build:

version = 2.3-SNAPSHOT
git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
build date = 20120727-0501
geotools version = 9-SNAPSHOT
geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b

The programmatic interface is used to populate the About GeoServer page with similar information.

Now that GeoServer master depends on GWC snapshots, should VERSION.txt and the About GeoServer page also contain GWC version info?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Justin_Deoliveira · July 27, 2012, 2:21pm

Definitely. To do this we need some way to pull that info out of the gwc artifacts. For GeoTools we include it in the manifest of all jars.

On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

GeoServer VERSION.txt contains information that is very useful in identifying the GeoServer and GeoTools snapshots contained in a build:

version = 2.3-SNAPSHOT
git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
build date = 20120727-0501
geotools version = 9-SNAPSHOT
geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b

The programmatic interface is used to populate the About GeoServer page with similar information.

Now that GeoServer master depends on GWC snapshots, should VERSION.txt and the About GeoServer page also contain GWC version info?

Kind regards,

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Gabriel_Roldan2 · July 27, 2012, 8:03pm

Guess we should do the same in GWC then.
So far GWC jar manifests has the bellow info. It should be as easy to
add git revision.

Built-By: groldan
Build-Jdk: 1.5.0_22
Implementation-Title: org.geowebcache
Implementation-Vendor: http://geowebcache.org
Implementation-Version: 2012-07-26 23:49:38
Specification-Title: org.geowebcache
Specification-Vendor: http://geowebcache.org
Specification-Version: 1.3-RC4

On Fri, Jul 27, 2012 at 11:21 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Definitely. To do this we need some way to pull that info out of the gwc
artifacts. For GeoTools we include it in the manifest of all jars.

On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

GeoServer VERSION.txt contains information that is very useful in
identifying the GeoServer and GeoTools snapshots contained in a build:

version = 2.3-SNAPSHOT
git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
build date = 20120727-0501
geotools version = 9-SNAPSHOT
geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b

The programmatic interface is used to populate the About GeoServer page
with similar information.

Now that GeoServer master depends on GWC snapshots, should VERSION.txt and
the About GeoServer page also contain GWC version info?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Gabriel_Roldan2 · July 27, 2012, 8:22pm

ok, added a Git-Revision entry to the gwc MANIFEST files just like the
GeoTools ones (e.g. Git-Revision:
152220479ae9bbf0e76ba1d2c416b3027f9f8683).

Is that all what's needed?

On Fri, Jul 27, 2012 at 5:03 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Guess we should do the same in GWC then.
So far GWC jar manifests has the bellow info. It should be as easy to
add git revision.

Built-By: groldan
Build-Jdk: 1.5.0_22
Implementation-Title: org.geowebcache
Implementation-Vendor: http://geowebcache.org
Implementation-Version: 2012-07-26 23:49:38
Specification-Title: org.geowebcache
Specification-Vendor: http://geowebcache.org
Specification-Version: 1.3-RC4

On Fri, Jul 27, 2012 at 11:21 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Definitely. To do this we need some way to pull that info out of the gwc
artifacts. For GeoTools we include it in the manifest of all jars.

On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

GeoServer VERSION.txt contains information that is very useful in
identifying the GeoServer and GeoTools snapshots contained in a build:

version = 2.3-SNAPSHOT
git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
build date = 20120727-0501
geotools version = 9-SNAPSHOT
geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b

The programmatic interface is used to populate the About GeoServer page
with similar information.

Now that GeoServer master depends on GWC snapshots, should VERSION.txt and
the About GeoServer page also contain GWC version info?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · July 28, 2012, 2:08pm

Nice, that should be it. Thanks Gabriel. I will do a build locally and try it out.

On Fri, Jul 27, 2012 at 1:22 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

ok, added a Git-Revision entry to the gwc MANIFEST files just like the
GeoTools ones (e.g. Git-Revision:
152220479ae9bbf0e76ba1d2c416b3027f9f8683).

Is that all what’s needed?

On Fri, Jul 27, 2012 at 5:03 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Guess we should do the same in GWC then.
So far GWC jar manifests has the bellow info. It should be as easy to
add git revision.

Built-By: groldan
Build-Jdk: 1.5.0_22
Implementation-Title: org.geowebcache
Implementation-Vendor: http://geowebcache.org
Implementation-Version: 2012-07-26 23:49:38
Specification-Title: org.geowebcache
Specification-Vendor: http://geowebcache.org
Specification-Version: 1.3-RC4

On Fri, Jul 27, 2012 at 11:21 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Definitely. To do this we need some way to pull that info out of the gwc
artifacts. For GeoTools we include it in the manifest of all jars.

On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies
Ben.Caradoc-Davies@anonymised.com wrote:

GeoServer VERSION.txt contains information that is very useful in
identifying the GeoServer and GeoTools snapshots contained in a build:

version = 2.3-SNAPSHOT
git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
build date = 20120727-0501
geotools version = 9-SNAPSHOT
geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b

The programmatic interface is used to populate the About GeoServer page
with similar information.

Now that GeoServer master depends on GWC snapshots, should VERSION.txt and
the About GeoServer page also contain GWC version info?

Kind regards,

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin_Deoliveira · July 28, 2012, 3:24pm

Ok, so tricker originally than I thought. One because loading the manfiest entries from both jars conflict with each other, but i think i have that one licked. The second is issue is loading the info from the web ui. Ideally we could a similar class in gwc as the GeoTools class for providing the version/revision info at runtime. Any objection to this Gabriel? I can whip up a quick patch if not.

On Sat, Jul 28, 2012 at 7:08 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Nice, that should be it. Thanks Gabriel. I will do a build locally and try it out.

On Fri, Jul 27, 2012 at 1:22 PM, Gabriel Roldan <groldan@anonymised.com1…> wrote:

ok, added a Git-Revision entry to the gwc MANIFEST files just like the
GeoTools ones (e.g. Git-Revision:
152220479ae9bbf0e76ba1d2c416b3027f9f8683).

Is that all what’s needed?

On Fri, Jul 27, 2012 at 5:03 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Guess we should do the same in GWC then.
So far GWC jar manifests has the bellow info. It should be as easy to
add git revision.

Built-By: groldan
Build-Jdk: 1.5.0_22
Implementation-Title: org.geowebcache
Implementation-Vendor: http://geowebcache.org
Implementation-Version: 2012-07-26 23:49:38
Specification-Title: org.geowebcache
Specification-Vendor: http://geowebcache.org
Specification-Version: 1.3-RC4

On Fri, Jul 27, 2012 at 11:21 AM, Justin Deoliveira
<jdeolive@…1501…> wrote:

Definitely. To do this we need some way to pull that info out of the gwc
artifacts. For GeoTools we include it in the manifest of all jars.

On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies
Ben.Caradoc-Davies@anonymised.com wrote:

GeoServer VERSION.txt contains information that is very useful in
identifying the GeoServer and GeoTools snapshots contained in a build:

version = 2.3-SNAPSHOT
git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
build date = 20120727-0501
geotools version = 9-SNAPSHOT
geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b

The programmatic interface is used to populate the About GeoServer page
with similar information.

Now that GeoServer master depends on GWC snapshots, should VERSION.txt and
the About GeoServer page also contain GWC version info?

Kind regards,

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Gabriel_Roldan2 · July 30, 2012, 1:16pm

Ok, I see how the Git-Revision entry can conflict.

This is what GWC does for the build info in the front page:
        Package versionInfo = Package.getPackage("org.geowebcache");
        String version = versionInfo.getSpecificationVersion();
        String commitId = versionInfo.getImplementationVersion();
        if (version == null) {
            version = "{NO VERSION INFO IN MANIFEST}";
        }
        if (commitId == null) {
            commitId = "{NO BUILD INFO IN MANIFEST}";
        }

I just changed getImplementationVersion() to return the git commit id
instead of the built date.
I would rather stick to that "standard" manifest entry. But can do an
utility class in the same spirit than GeoTools.getBuildRevision().
Would that work?

On Sat, Jul 28, 2012 at 12:24 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Ok, so tricker originally than I thought. One because loading the manfiest
entries from both jars conflict with each other, but i think i have that one
licked. The second is issue is loading the info from the web ui. Ideally we
could a similar class in gwc as the GeoTools class for providing the
version/revision info at runtime. Any objection to this Gabriel? I can whip
up a quick patch if not.

On Sat, Jul 28, 2012 at 7:08 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Nice, that should be it. Thanks Gabriel. I will do a build locally and try
it out.

On Fri, Jul 27, 2012 at 1:22 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:

ok, added a Git-Revision entry to the gwc MANIFEST files just like the
GeoTools ones (e.g. Git-Revision:
152220479ae9bbf0e76ba1d2c416b3027f9f8683).

Is that all what's needed?

On Fri, Jul 27, 2012 at 5:03 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:
> Guess we should do the same in GWC then.
> So far GWC jar manifests has the bellow info. It should be as easy to
> add git revision.
>
> Built-By: groldan
> Build-Jdk: 1.5.0_22
> Implementation-Title: org.geowebcache
> Implementation-Vendor: http://geowebcache.org
> Implementation-Version: 2012-07-26 23:49:38
> Specification-Title: org.geowebcache
> Specification-Vendor: http://geowebcache.org
> Specification-Version: 1.3-RC4
>
>
> On Fri, Jul 27, 2012 at 11:21 AM, Justin Deoliveira
> <jdeolive@anonymised.com> wrote:
>> Definitely. To do this we need some way to pull that info out of the
>> gwc
>> artifacts. For GeoTools we include it in the manifest of all jars.
>>
>>
>> On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies
>> <Ben.Caradoc-Davies@anonymised.com> wrote:
>>>
>>> GeoServer VERSION.txt contains information that is very useful in
>>> identifying the GeoServer and GeoTools snapshots contained in a
>>> build:
>>>
>>> version = 2.3-SNAPSHOT
>>> git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
>>> git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
>>> build date = 20120727-0501
>>> geotools version = 9-SNAPSHOT
>>> geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b
>>>
>>> The programmatic interface is used to populate the About GeoServer
>>> page
>>> with similar information.
>>>
>>> Now that GeoServer master depends on GWC snapshots, should
>>> VERSION.txt and
>>> the About GeoServer page also contain GWC version info?
>>>
>>> Kind regards,
>>>
>>> --
>>> Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
>>> Software Engineer
>>> CSIRO Earth Science and Resource Engineering
>>> Australian Resources Research Centre
>>>
>>
>>
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>
>
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · July 30, 2012, 2:01pm

Nice.

As for the conflict I can definitely work around that, so that is no problem.

If we could wrap up that code in a utility method that would be great, although i guess I could also just use the same code snippet. Let me know what you prefer.

On Mon, Jul 30, 2012 at 6:16 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

Ok, I see how the Git-Revision entry can conflict.

This is what GWC does for the build info in the front page:
Package versionInfo = Package.getPackage(“org.geowebcache”);
String version = versionInfo.getSpecificationVersion();
String commitId = versionInfo.getImplementationVersion();
if (version == null) {
version = “{NO VERSION INFO IN MANIFEST}”;
}
if (commitId == null) {
commitId = “{NO BUILD INFO IN MANIFEST}”;
}

I just changed getImplementationVersion() to return the git commit id
instead of the built date.
I would rather stick to that “standard” manifest entry. But can do an
utility class in the same spirit than GeoTools.getBuildRevision().
Would that work?

On Sat, Jul 28, 2012 at 12:24 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Ok, so tricker originally than I thought. One because loading the manfiest
entries from both jars conflict with each other, but i think i have that one
licked. The second is issue is loading the info from the web ui. Ideally we
could a similar class in gwc as the GeoTools class for providing the
version/revision info at runtime. Any objection to this Gabriel? I can whip
up a quick patch if not.

On Sat, Jul 28, 2012 at 7:08 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Nice, that should be it. Thanks Gabriel. I will do a build locally and try
it out.

On Fri, Jul 27, 2012 at 1:22 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:

ok, added a Git-Revision entry to the gwc MANIFEST files just like the
GeoTools ones (e.g. Git-Revision:
152220479ae9bbf0e76ba1d2c416b3027f9f8683).

Is that all what’s needed?

On Fri, Jul 27, 2012 at 5:03 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:

Guess we should do the same in GWC then.
So far GWC jar manifests has the bellow info. It should be as easy to
add git revision.

Built-By: groldan
Build-Jdk: 1.5.0_22
Implementation-Title: org.geowebcache
Implementation-Vendor: http://geowebcache.org
Implementation-Version: 2012-07-26 23:49:38
Specification-Title: org.geowebcache
Specification-Vendor: http://geowebcache.org
Specification-Version: 1.3-RC4

On Fri, Jul 27, 2012 at 11:21 AM, Justin Deoliveira
<jdeolive@anonymised.com01…> wrote:

Definitely. To do this we need some way to pull that info out of the
gwc
artifacts. For GeoTools we include it in the manifest of all jars.

On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies
Ben.Caradoc-Davies@anonymised.com wrote:

GeoServer VERSION.txt contains information that is very useful in
identifying the GeoServer and GeoTools snapshots contained in a
build:

version = 2.3-SNAPSHOT
git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
build date = 20120727-0501
geotools version = 9-SNAPSHOT
geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b

The programmatic interface is used to populate the About GeoServer
page
with similar information.

Now that GeoServer master depends on GWC snapshots, should
VERSION.txt and
the About GeoServer page also contain GWC version info?

Kind regards,

–
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com…>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Gabriel_Roldan2 · July 30, 2012, 3:23pm

I've the patch for the
org.geowebcache.GeoWebCache.getVersion()/getBuildRevision() methods
handy so that'd be just as easy to commit.
But: you would be able to use it on GeoServer master right away. On
2.2.x would need to wait till next release (just released 1.3-RC4 last
Friday, next one should be 1.3.0 in synch with GS 2.2.0)

On Mon, Jul 30, 2012 at 11:01 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Nice.

As for the conflict I can definitely work around that, so that is no
problem.

If we could wrap up that code in a utility method that would be great,
although i guess I could also just use the same code snippet. Let me know
what you prefer.

On Mon, Jul 30, 2012 at 6:16 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

Ok, I see how the Git-Revision entry can conflict.

This is what GWC does for the build info in the front page:
        Package versionInfo = Package.getPackage("org.geowebcache");
        String version = versionInfo.getSpecificationVersion();
        String commitId = versionInfo.getImplementationVersion();
        if (version == null) {
            version = "{NO VERSION INFO IN MANIFEST}";
        }
        if (commitId == null) {
            commitId = "{NO BUILD INFO IN MANIFEST}";
        }

I just changed getImplementationVersion() to return the git commit id
instead of the built date.
I would rather stick to that "standard" manifest entry. But can do an
utility class in the same spirit than GeoTools.getBuildRevision().
Would that work?

On Sat, Jul 28, 2012 at 12:24 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:
> Ok, so tricker originally than I thought. One because loading the
> manfiest
> entries from both jars conflict with each other, but i think i have that
> one
> licked. The second is issue is loading the info from the web ui. Ideally
> we
> could a similar class in gwc as the GeoTools class for providing the
> version/revision info at runtime. Any objection to this Gabriel? I can
> whip
> up a quick patch if not.
>
>
> On Sat, Jul 28, 2012 at 7:08 AM, Justin Deoliveira
> <jdeolive@anonymised.com>
> wrote:
>>
>> Nice, that should be it. Thanks Gabriel. I will do a build locally and
>> try
>> it out.
>>
>>
>> On Fri, Jul 27, 2012 at 1:22 PM, Gabriel Roldan <groldan@anonymised.com>
>> wrote:
>>>
>>> ok, added a Git-Revision entry to the gwc MANIFEST files just like the
>>> GeoTools ones (e.g. Git-Revision:
>>> 152220479ae9bbf0e76ba1d2c416b3027f9f8683).
>>>
>>> Is that all what's needed?
>>>
>>> On Fri, Jul 27, 2012 at 5:03 PM, Gabriel Roldan <groldan@anonymised.com>
>>> wrote:
>>> > Guess we should do the same in GWC then.
>>> > So far GWC jar manifests has the bellow info. It should be as easy
>>> > to
>>> > add git revision.
>>> >
>>> > Built-By: groldan
>>> > Build-Jdk: 1.5.0_22
>>> > Implementation-Title: org.geowebcache
>>> > Implementation-Vendor: http://geowebcache.org
>>> > Implementation-Version: 2012-07-26 23:49:38
>>> > Specification-Title: org.geowebcache
>>> > Specification-Vendor: http://geowebcache.org
>>> > Specification-Version: 1.3-RC4
>>> >
>>> >
>>> > On Fri, Jul 27, 2012 at 11:21 AM, Justin Deoliveira
>>> > <jdeolive@anonymised.com> wrote:
>>> >> Definitely. To do this we need some way to pull that info out of
>>> >> the
>>> >> gwc
>>> >> artifacts. For GeoTools we include it in the manifest of all jars.
>>> >>
>>> >>
>>> >> On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies
>>> >> <Ben.Caradoc-Davies@anonymised.com> wrote:
>>> >>>
>>> >>> GeoServer VERSION.txt contains information that is very useful in
>>> >>> identifying the GeoServer and GeoTools snapshots contained in a
>>> >>> build:
>>> >>>
>>> >>> version = 2.3-SNAPSHOT
>>> >>> git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
>>> >>> git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
>>> >>> build date = 20120727-0501
>>> >>> geotools version = 9-SNAPSHOT
>>> >>> geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b
>>> >>>
>>> >>> The programmatic interface is used to populate the About GeoServer
>>> >>> page
>>> >>> with similar information.
>>> >>>
>>> >>> Now that GeoServer master depends on GWC snapshots, should
>>> >>> VERSION.txt and
>>> >>> the About GeoServer page also contain GWC version info?
>>> >>>
>>> >>> Kind regards,
>>> >>>
>>> >>> --
>>> >>> Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
>>> >>> Software Engineer
>>> >>> CSIRO Earth Science and Resource Engineering
>>> >>> Australian Resources Research Centre
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Justin Deoliveira
>>> >> OpenGeo - http://opengeo.org
>>> >> Enterprise support for open source geospatial.
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Gabriel Roldan
>>> > OpenGeo - http://opengeo.org
>>> > Expert service straight from the developers.
>>>
>>>
>>>
>>> --
>>> Gabriel Roldan
>>> OpenGeo - http://opengeo.org
>>> Expert service straight from the developers.
>>
>>
>>
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · July 31, 2012, 12:21am

Hmmmm… right. I guess for now I can just grab the gwc package directly. Actually this will be much safer anyways since it is not uncommon to have configurations where the gwc jars have been removed. This should account for that.

On Mon, Jul 30, 2012 at 8:23 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

I’ve the patch for the
org.geowebcache.GeoWebCache.getVersion()/getBuildRevision() methods
handy so that’d be just as easy to commit.
But: you would be able to use it on GeoServer master right away. On
2.2.x would need to wait till next release (just released 1.3-RC4 last
Friday, next one should be 1.3.0 in synch with GS 2.2.0)

On Mon, Jul 30, 2012 at 11:01 AM, Justin Deoliveira

<jdeolive@anonymised.com> wrote:

Nice.

As for the conflict I can definitely work around that, so that is no
problem.

If we could wrap up that code in a utility method that would be great,
although i guess I could also just use the same code snippet. Let me know
what you prefer.

On Mon, Jul 30, 2012 at 6:16 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

Ok, I see how the Git-Revision entry can conflict.

This is what GWC does for the build info in the front page:
Package versionInfo = Package.getPackage(“org.geowebcache”);
String version = versionInfo.getSpecificationVersion();
String commitId = versionInfo.getImplementationVersion();
if (version == null) {
version = “{NO VERSION INFO IN MANIFEST}”;
}
if (commitId == null) {
commitId = “{NO BUILD INFO IN MANIFEST}”;
}

I just changed getImplementationVersion() to return the git commit id
instead of the built date.
I would rather stick to that “standard” manifest entry. But can do an
utility class in the same spirit than GeoTools.getBuildRevision().
Would that work?

On Sat, Jul 28, 2012 at 12:24 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Ok, so tricker originally than I thought. One because loading the
manfiest
entries from both jars conflict with each other, but i think i have that
one
licked. The second is issue is loading the info from the web ui. Ideally
we
could a similar class in gwc as the GeoTools class for providing the
version/revision info at runtime. Any objection to this Gabriel? I can
whip
up a quick patch if not.

On Sat, Jul 28, 2012 at 7:08 AM, Justin Deoliveira
<jdeolive@anonymised.com.>
wrote:

Nice, that should be it. Thanks Gabriel. I will do a build locally and
try
it out.

On Fri, Jul 27, 2012 at 1:22 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:

ok, added a Git-Revision entry to the gwc MANIFEST files just like the
GeoTools ones (e.g. Git-Revision:
152220479ae9bbf0e76ba1d2c416b3027f9f8683).

Is that all what’s needed?

On Fri, Jul 27, 2012 at 5:03 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:

Guess we should do the same in GWC then.
So far GWC jar manifests has the bellow info. It should be as easy
to
add git revision.

Built-By: groldan
Build-Jdk: 1.5.0_22
Implementation-Title: org.geowebcache
Implementation-Vendor: http://geowebcache.org
Implementation-Version: 2012-07-26 23:49:38
Specification-Title: org.geowebcache
Specification-Vendor: http://geowebcache.org
Specification-Version: 1.3-RC4

On Fri, Jul 27, 2012 at 11:21 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Definitely. To do this we need some way to pull that info out of
the
gwc
artifacts. For GeoTools we include it in the manifest of all jars.

On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies
Ben.Caradoc-Davies@anonymised.com wrote:

GeoServer VERSION.txt contains information that is very useful in
identifying the GeoServer and GeoTools snapshots contained in a
build:

version = 2.3-SNAPSHOT
git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
build date = 20120727-0501
geotools version = 9-SNAPSHOT
geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b

The programmatic interface is used to populate the About GeoServer
page
with similar information.

Now that GeoServer master depends on GWC snapshots, should
VERSION.txt and
the About GeoServer page also contain GWC version info?

Kind regards,

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin_Deoliveira · July 31, 2012, 1:46am

https://github.com/geoserver/geoserver/pull/11

On Mon, Jul 30, 2012 at 5:21 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hmmmm… right. I guess for now I can just grab the gwc package directly. Actually this will be much safer anyways since it is not uncommon to have configurations where the gwc jars have been removed. This should account for that.

On Mon, Jul 30, 2012 at 8:23 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

I’ve the patch for the
org.geowebcache.GeoWebCache.getVersion()/getBuildRevision() methods
handy so that’d be just as easy to commit.
But: you would be able to use it on GeoServer master right away. On
2.2.x would need to wait till next release (just released 1.3-RC4 last
Friday, next one should be 1.3.0 in synch with GS 2.2.0)

On Mon, Jul 30, 2012 at 11:01 AM, Justin Deoliveira

<jdeolive@anonymised.com> wrote:

Nice.

As for the conflict I can definitely work around that, so that is no
problem.

If we could wrap up that code in a utility method that would be great,
although i guess I could also just use the same code snippet. Let me know
what you prefer.

On Mon, Jul 30, 2012 at 6:16 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

Ok, I see how the Git-Revision entry can conflict.

This is what GWC does for the build info in the front page:
Package versionInfo = Package.getPackage(“org.geowebcache”);
String version = versionInfo.getSpecificationVersion();
String commitId = versionInfo.getImplementationVersion();
if (version == null) {
version = “{NO VERSION INFO IN MANIFEST}”;
}
if (commitId == null) {
commitId = “{NO BUILD INFO IN MANIFEST}”;
}

I just changed getImplementationVersion() to return the git commit id
instead of the built date.
I would rather stick to that “standard” manifest entry. But can do an
utility class in the same spirit than GeoTools.getBuildRevision().
Would that work?

On Sat, Jul 28, 2012 at 12:24 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Ok, so tricker originally than I thought. One because loading the
manfiest
entries from both jars conflict with each other, but i think i have that
one
licked. The second is issue is loading the info from the web ui. Ideally
we
could a similar class in gwc as the GeoTools class for providing the
version/revision info at runtime. Any objection to this Gabriel? I can
whip
up a quick patch if not.

On Sat, Jul 28, 2012 at 7:08 AM, Justin Deoliveira
<jdeolive@anonymised.com>
wrote:

Nice, that should be it. Thanks Gabriel. I will do a build locally and
try
it out.

On Fri, Jul 27, 2012 at 1:22 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:

ok, added a Git-Revision entry to the gwc MANIFEST files just like the
GeoTools ones (e.g. Git-Revision:
152220479ae9bbf0e76ba1d2c416b3027f9f8683).

Is that all what’s needed?

On Fri, Jul 27, 2012 at 5:03 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:

Guess we should do the same in GWC then.
So far GWC jar manifests has the bellow info. It should be as easy
to
add git revision.

Built-By: groldan
Build-Jdk: 1.5.0_22
Implementation-Title: org.geowebcache
Implementation-Vendor: http://geowebcache.org
Implementation-Version: 2012-07-26 23:49:38
Specification-Title: org.geowebcache
Specification-Vendor: http://geowebcache.org
Specification-Version: 1.3-RC4

On Fri, Jul 27, 2012 at 11:21 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Definitely. To do this we need some way to pull that info out of
the
gwc
artifacts. For GeoTools we include it in the manifest of all jars.

On Thu, Jul 26, 2012 at 8:21 PM, Ben Caradoc-Davies
Ben.Caradoc-Davies@anonymised.com wrote:

GeoServer VERSION.txt contains information that is very useful in
identifying the GeoServer and GeoTools snapshots contained in a
build:

version = 2.3-SNAPSHOT
git revision = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
git branch = f4823f9d60ec66ba64bde591ccd6b096fb0bc7ce
build date = 20120727-0501
geotools version = 9-SNAPSHOT
geotools revision = 9b2133c0fdab0dc03800831d7e9ca759ef1f388b

The programmatic interface is used to populate the About GeoServer
page
with similar information.

Now that GeoServer master depends on GWC snapshots, should
VERSION.txt and
the About GeoServer page also contain GWC version info?

Kind regards,

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Ben_Caradoc-Davies · August 1, 2012, 2:04am

I am now seeing an uninterpolated ${gwc.Git-Revision} in target/VERSION.txt.

And should that git branch be "master"?

See:
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/VERSION.txt

version = 2.3-SNAPSHOT
git revision = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
git branch = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
build date = 20120801-0057
geotools version = 9-SNAPSHOT
geotools revision = e88fea56db8a4d50ccfca27fae9d72004938712b
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = ${gwc.Git-Revision}
hudson build = -1

That one is built on Jenkins:
https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/

Kin regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Ben_Caradoc-Davies · August 1, 2012, 3:06am

And confirmed in a local build.

On 01/08/12 10:04, Ben Caradoc-Davies wrote:

I am now seeing an uninterpolated ${gwc.Git-Revision} in
target/VERSION.txt.

And should that git branch be "master"?

See:
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/VERSION.txt

version = 2.3-SNAPSHOT
git revision = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
git branch = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
build date = 20120801-0057
geotools version = 9-SNAPSHOT
geotools revision = e88fea56db8a4d50ccfca27fae9d72004938712b
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = ${gwc.Git-Revision}
hudson build = -1

That one is built on Jenkins:
https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/

Kin regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Justin_Deoliveira · August 1, 2012, 2:25pm

For the gwc revision issue it looks like the jar doesn’t have Git-Revision in the manifest, but does have Implementation-Version.

@Gabriel: Can you confirm Implementation-Version is what we should be using?

As for the git branch being equal to the revision not sure, i don’t see that locally. My guess is that the build is being run from a detached head?

On Tue, Jul 31, 2012 at 8:06 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com…> wrote:

And confirmed in a local build.

On 01/08/12 10:04, Ben Caradoc-Davies wrote:

I am now seeing an uninterpolated ${gwc.Git-Revision} in
target/VERSION.txt.

And should that git branch be “master”?

See:
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/VERSION.txt

version = 2.3-SNAPSHOT
git revision = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
git branch = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
build date = 20120801-0057
geotools version = 9-SNAPSHOT
geotools revision = e88fea56db8a4d50ccfca27fae9d72004938712b
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = ${gwc.Git-Revision}
hudson build = -1

That one is built on Jenkins:
https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/

Kin regards,

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Gabriel_Roldan2 · August 1, 2012, 4:42pm

On Wed, Aug 1, 2012 at 11:25 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

For the gwc revision issue it looks like the jar doesn't have Git-Revision
in the manifest, but does have Implementation-Version.

@Gabriel: Can you confirm Implementation-Version is what we should be using?

As for the git branch being equal to the revision not sure, i don't see that
locally. My guess is that the build is being run from a detached head?

Sorry, I thought we've agreed that Imlementation-Version was to hold
the git commit id, so I removed Git-Revision in favor of that one so
that there's no conflict with the geotools entry.
There's no entry for the originating branch name, although I could add
it. For instance, it is the 'stable' branch.

Let me know how you want to proceed. My preference is to keep on using
Implementation-Version for the commit id, but can make it otherwise.
And can also add the branch name and any other needed info.

Cheers,
Gabriel

On Tue, Jul 31, 2012 at 8:06 PM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

And confirmed in a local build.

On 01/08/12 10:04, Ben Caradoc-Davies wrote:

I am now seeing an uninterpolated ${gwc.Git-Revision} in
target/VERSION.txt.

And should that git branch be "master"?

See:
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/VERSION.txt

version = 2.3-SNAPSHOT
git revision = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
git branch = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
build date = 20120801-0057
geotools version = 9-SNAPSHOT
geotools revision = e88fea56db8a4d50ccfca27fae9d72004938712b
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = ${gwc.Git-Revision}
hudson build = -1

That one is built on Jenkins:
https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/

Kin regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · August 1, 2012, 7:33pm

Cool, Implementation-Version is fine, change pushed.

On Wed, Aug 1, 2012 at 10:42 AM, Gabriel Roldan <groldan@anonymised.com.1501…> wrote:

On Wed, Aug 1, 2012 at 11:25 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

For the gwc revision issue it looks like the jar doesn’t have Git-Revision
in the manifest, but does have Implementation-Version.

@Gabriel: Can you confirm Implementation-Version is what we should be using?

As for the git branch being equal to the revision not sure, i don’t see that
locally. My guess is that the build is being run from a detached head?

Sorry, I thought we’ve agreed that Imlementation-Version was to hold
the git commit id, so I removed Git-Revision in favor of that one so
that there’s no conflict with the geotools entry.
There’s no entry for the originating branch name, although I could add
it. For instance, it is the ‘stable’ branch.

Let me know how you want to proceed. My preference is to keep on using
Implementation-Version for the commit id, but can make it otherwise.
And can also add the branch name and any other needed info.

Cheers,
Gabriel

On Tue, Jul 31, 2012 at 8:06 PM, Ben Caradoc-Davies
Ben.Caradoc-Davies@anonymised.com wrote:

And confirmed in a local build.

On 01/08/12 10:04, Ben Caradoc-Davies wrote:

I am now seeing an uninterpolated ${gwc.Git-Revision} in
target/VERSION.txt.

And should that git branch be “master”?

See:
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/
http://files.ivec.org/geoserver/geoserver-master/2012-08-01/VERSION.txt

version = 2.3-SNAPSHOT
git revision = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
git branch = d0d7f740e47dc4f84efc7f194bc8ef71fcd9e8d5
build date = 20120801-0057
geotools version = 9-SNAPSHOT
geotools revision = e88fea56db8a4d50ccfca27fae9d72004938712b
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = ${gwc.Git-Revision}
hudson build = -1

That one is built on Jenkins:
https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/

Kin regards,

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Ben_Caradoc-Davies · August 2, 2012, 5:27am

On 02/08/12 03:33, Justin Deoliveira wrote:

Cool, Implementation-Version is fine, change pushed.

Thanks, Justin. Almost done. There is still something a bit odd; see the trailing "/b92c3" at the end of geowebcache revision, which looks like start of the revision:

version = 2.3-SNAPSHOT
git revision = b63f7b604ca3685601c8ec05fe914233b533800b
git branch = b63f7b604ca3685601c8ec05fe914233b533800b
build date = 20120802-1047
geotools version = 9-SNAPSHOT
geotools revision = dfe47bb664b0093a13060f165235442210b4ffa3
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = b92c3e0fb28e1c8f7e55c2e55a90c187b00b50c0/b92c3
hudson build = -1

Is this intended?

Kind regards,
Ben.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Justin_Deoliveira · August 2, 2012, 1:44pm

Hey Ben,

I believe it is and again i think the issue is that gwc is being built from a detached head. The syntax for the Implementation-Version property gwc is using is /. For instance, here is what my VERSION.txt looks like:

version = 2.3-SNAPSHOT
git revision = 3d5285c71017347de6a5111e1a623b98b40c7b09
git branch = master
build date = 02-Aug-2012 07:42
geotools version = 9-SNAPSHOT
geotools revision = 4165fe266183c66220f88377be52de7eee09e8d0
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = stable/b92c3e0fb28e1c8f7e55c2e55a90c187b00b50c0
hudson build = -1

On Wed, Aug 1, 2012 at 11:27 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

On 02/08/12 03:33, Justin Deoliveira wrote:

Cool, Implementation-Version is fine, change pushed.

Thanks, Justin. Almost done. There is still something a bit odd; see the trailing “/b92c3” at the end of geowebcache revision, which looks like start of the revision:

version = 2.3-SNAPSHOT
git revision = b63f7b604ca3685601c8ec05fe914233b533800b
git branch = b63f7b604ca3685601c8ec05fe914233b533800b
build date = 20120802-1047
geotools version = 9-SNAPSHOT
geotools revision = dfe47bb664b0093a13060f165235442210b4ffa3
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = b92c3e0fb28e1c8f7e55c2e55a90c187b00b50c0/b92c3
hudson build = -1

Is this intended?

Kind regards,
Ben.

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Ben_Caradoc-Davies · August 3, 2012, 2:26am

Ah, that explains everything. I had a look in my Jenkins slave and the workspaces are indeed on a detached head. This is likely a Jenkins git oddity or configuration problem.

Thanks for the diagnosis!

Kind regards,
Ben.

On 02/08/12 21:44, Justin Deoliveira wrote:

Hey Ben,

I believe it is and again i think the issue is that gwc is being built
from a detached head. The syntax for the Implementation-Version property
gwc is using is <branch>/<revision>. For instance, here is what my
VERSION.txt looks like:

version = 2.3-SNAPSHOT
git revision = 3d5285c71017347de6a5111e1a623b98b40c7b09
git branch = master
build date = 02-Aug-2012 07:42
geotools version = 9-SNAPSHOT
geotools revision = 4165fe266183c66220f88377be52de7eee09e8d0
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = stable/b92c3e0fb28e1c8f7e55c2e55a90c187b00b50c0
hudson build = -1

On Wed, Aug 1, 2012 at 11:27 PM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com <mailto:Ben.Caradoc-Davies@anonymised.com>> wrote:

    On 02/08/12 03:33, Justin Deoliveira wrote:

        Cool, Implementation-Version is fine, change pushed.

    Thanks, Justin. Almost done. There is still something a bit odd; see
    the trailing "/b92c3" at the end of geowebcache revision, which
    looks like start of the revision:

    version = 2.3-SNAPSHOT
    git revision = b63f7b604ca3685601c8ec05fe9142__33b533800b
    git branch = b63f7b604ca3685601c8ec05fe9142__33b533800b
    build date = 20120802-1047
    geotools version = 9-SNAPSHOT
    geotools revision = dfe47bb664b0093a13060f16523544__2210b4ffa3
    geowebcache version = 1.3-SNAPSHOT
    geowebcache revision = b92c3e0fb28e1c8f7e55c2e55a90c1__87b00b50c0/b92c3
    hudson build = -1

    Is this intended?

    Kind regards,
    Ben.

    --
    Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
    Software Engineer
    CSIRO Earth Science and Resource Engineering
    Australian Resources Research Centre

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Ben_Caradoc-Davies · August 3, 2012, 3:59am

Looks like it is fixed. The magic Jenkins configuration option is "Checkout/merge to local branch (optional)" which I have now set to the branch. Without this option Jenkins defaults to working on a detached head.

Kind regards,
Ben.

On 03/08/12 10:26, Ben Caradoc-Davies wrote:

Ah, that explains everything. I had a look in my Jenkins slave and the
workspaces are indeed on a detached head. This is likely a Jenkins git
oddity or configuration problem.

Thanks for the diagnosis!

Kind regards,
Ben.

On 02/08/12 21:44, Justin Deoliveira wrote:

Hey Ben,

I believe it is and again i think the issue is that gwc is being built
from a detached head. The syntax for the Implementation-Version property
gwc is using is <branch>/<revision>. For instance, here is what my
VERSION.txt looks like:

version = 2.3-SNAPSHOT
git revision = 3d5285c71017347de6a5111e1a623b98b40c7b09
git branch = master
build date = 02-Aug-2012 07:42
geotools version = 9-SNAPSHOT
geotools revision = 4165fe266183c66220f88377be52de7eee09e8d0
geowebcache version = 1.3-SNAPSHOT
geowebcache revision = stable/b92c3e0fb28e1c8f7e55c2e55a90c187b00b50c0
hudson build = -1

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre