[Geoserver-devel] [Hudson] Build failed in Hudson: cite-wms-1.3 #508

2012-07-12 Thread Hudson 
See 

--
[...truncated 1884 lines...]
 [exec]Assertion: For style "Forests", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_7)...
 [exec]Assertion: For style "Lakes", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_8)...
 [exec]Assertion: For style "polygon", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_9)...
 [exec]Assertion: For style "MapNeatline", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_10)...
 [exec]Assertion: For style "NamedPlaces", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_11)...
 [exec]Assertion: For style "Ponds", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_12)...
 [exec]Assertion: For style "RoadSegments", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_13)...
 [exec]Assertion: For style "Streams", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec]  Test getmap:styles Passed
 [exec]  Testing getmap:transparent 
(wms-1.3.0/d3717e372_1/d1097e56_1)...
 [exec] Assertion: The TRANSPARENT parameter behaves properly.
 [exec] Testing getmap:transparent-default 
(wms-1.3.0/d3717e372_1/d1097e56_1/d1097e339_1)...
 [exec]Assertion: When a GetMap request is made with no 
TRANSPARENT parameter and a FORMAT that supports transparency over a layer that 
is not opaque, then the response contains no transparent pixels.
 [exec] Test getmap:transparent-default Passed
 [exec] Testing getmap:transparent-false 
(wms-1.3.0/d3717e372_1/d1097e56_1/d1097e341_1)...
 [exec]Assertion: When a GetMap request is made with 
TRANSPARENT=FALSE and a FORMAT that supports transparency over a layer that is 
not opaque, then the response contains no transparent pixels.
 [exec] Test getmap:transparent-false Passed
 [exec] Testing getmap:transparent-true 
(wms-1.3.0/d3717e372_1/d1097e56_1/d1097e345_1)...
 [exec]Assertion: When a GetMap request is made with 
TRANSPARENT=TRUE and a FORMAT that supports transparency over a BBOX that is 
not completely covered, then the response contains transparent pixels.
 [exec] Test getmap:transparent-true Passed
 [exec] Testing getmap:transparent-opaque-layer 
(wms-1.3.0/d3717e372_1/d1097e56_1/d1097e348_1)...
 [exec]Assertion: Clients may request TRANSPARENT=TRUE on a 
layer that is opaque.
 [exec]No named opaque layers.
 [exec] Test getmap:transparent-opaque-layer Passed
 [exec]  Test getmap:transparent Passed
 [exec]  Testing getmap:width-and-height 
(wms-1.3.0/d3717e372_1/d1097e61_1)...
 [exec] Assertion: The WIDTH and HEIGHT parameters behaves 
properly.
 [exec] Testing getmap:large-size 
(wms-1.3.0/d3717e372_1/d1097e61_1/d1097e362_1)...
 [exec]Assertion: When a request is made for a large map 
(1024x768 or largest map supported), the image returned is exactly the size 
requested.
 [exec] Test getmap:large-size Passed
 [exec] Testing getmap:small-size 
(wms-1.3.0/d3717e372_1/d1097e61_1/d1097e364_1)...
 [exec]Assertion: When a request is made with WIDTH=8 and 
HEIGHT=5, the image returned is exact

[Geoserver-devel] [jira] (GEOS-5223) WFS reprojection of 3D point and 3D Linestring

2012-07-12 Thread Niels Charlier (JIRA) 














































Niels Charlier
 created  GEOS-5223


WFS reprojection of 3D point and 3D Linestring















Issue Type:


New Feature



Assignee:


Andrea Aime



Created:


12/Jul/12 5:09 PM



Description:


Create a functionality where a user should be able to request data via WFS in a different 3D CRS and have the data reprojected to that CRS, including correct adjustment of the third dimension. 




Project:


GeoServer



Priority:


Major



Reporter:


Niels Charlier




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Wicket UI bugs

2012-07-12 Thread David Winslow 
Hey Rollie,

You can't just copy and paste a link to the JIRA search results - there's a
permalink button just under the navigation bar though.  I guess you meant
to link to a search for open tickets against the Wicket UI component,
right?

https://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+resolution+%3D+Unresolved+AND+component+%3D+%22Wicket+UI%22

Anyway, I think that a lot of these issues (especially just labelling
consistency issues) would be pretty good in terms of bang-to-buck ratio,
but I'm not sure how we can push forward on them.  Maybe a sprint can be
arranged?

--
David Winslow
OpenGeo - http://opengeo.org/

On Thu, Jul 12, 2012 at 4:32 PM, Rolando Peñate  wrote:

> Hey folks,
>
> I've found and ticketed some very low hanging fruit I found while poking
> around in the Wicket UI and noticed there were a lot of other similar
> issues already:
> https://jira.codehaus.org/secure/IssueNavigator.jspa?pager/start=0
>
> I was wondering if there were any thoughts or plans about how best to
> report or address things related to the GeoServer UI.
>
> Cheers,
> Rolando
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Wicket UI bugs

2012-07-12 Thread Rolando Peñate 
Hey folks,

I've found and ticketed some very low hanging fruit I found while poking
around in the Wicket UI and noticed there were a lot of other similar
issues already:
https://jira.codehaus.org/secure/IssueNavigator.jspa?pager/start=0

I was wondering if there were any thoughts or plans about how best to
report or address things related to the GeoServer UI.

Cheers,
Rolando
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] (GEOS-5222) "Save and continue editing" for SLD editor

2012-07-12 Thread David Winslow (JIRA) 














































David Winslow
 created  GEOS-5222


"Save and continue editing" for SLD editor















Issue Type:


Improvement



Assignee:


David Winslow



Components:


Wicket UI



Created:


12/Jul/12 1:04 PM



Description:


It would be nice to have the option to update a style without navigating away from the style editor - in conjunction with a preview map open in another browser tab that would make possible an iterative styling process.




Project:


GeoServer



Priority:


Major



Reporter:


David Winslow




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] (GEOS-5221) The 'enter contact information' lacks a web URL & the 'This GeoServer belongs to' text on welcome page has no hyperlink

2012-07-12 Thread Stephen Hallett (JIRA) 














































Stephen Hallett
 created  GEOS-5221


The 'enter contact information' lacks a web URL & the 'This GeoServer belongs to' text on welcome page has no hyperlink















Issue Type:


Bug



Affects Versions:


2.1.4



Assignee:


Justin Deoliveira



Components:


Configuration



Created:


12/Jul/12 11:05 AM



Description:


The 2.1.4 welcomepage link to 'Global settings' updates file 'data_dir\global.xml'. There is no field to enter an organisational URL in these contact details.

The 2.1.4 welcomepage displays 'This GeoServer belongs to ', and displays . However it forms an html  anchor with no href.

I suggest a new XML tag  be created, added to the contact information and then used (if present) to form the url link on the welcome page.

See FAO page 'http://www.fao.org/figis/geoserver/web/' for an example of this




Environment:


Win server 2008




Project:


GeoServer



Priority:


Trivial



Reporter:


Stephen Hallett




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] (GEOS-5220) Oops, something went wrong... on vanilla deployment of 2.2 RC1

2012-07-12 Thread Marcus Sen (JIRA) 














































Marcus Sen
 created  GEOS-5220


Oops, something went wrong... on vanilla deployment of 2.2 RC1















Issue Type:


Bug



Affects Versions:


2.2-RC1



Assignee:


Andrea Aime



Attachments:


stacktrace.txt



Components:


Wicket UI



Created:


12/Jul/12 10:50 AM



Description:


Deployed the war for 2.2-RC1 including extra libraries from app-schema plugin without any personal modifications. On visiting the webapp URL I got the "Oops, something went wrong" message and logging in as admin got the stack trace attached.




Environment:


Windows Server 2003, Apache Tomcat 6.0.29




Project:


GeoServer



Labels:


exception




Priority:


Blocker



Reporter:


Marcus Sen




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Pull requests

2012-07-12 Thread David Winslow 
On Thu, Jul 12, 2012 at 10:38 AM, Justin Deoliveira wrote:

>
>
> On Thu, Jul 12, 2012 at 8:18 AM, David Winslow wrote:
>
>> Actually I rarely use the through-the-web merge tool on Github - for me
>> the nice thing about pull requests is the ability to comment on the patch
>> line-by-line, see new additions to the patch in the same comment thread,
>> etc.  Here's a GeoNode pull request that used all that kind of stuff:
>> https://github.com/GeoNode/geonode/pull/248
>
>
> Interesting. So how do you merge in pull requests? Add the developers repo
> as a remote and pull down the changes that way?
>
Yes.  Github will automatically close the pull request if a merge is pushed
to the repository.  I should clarify that it's not that I don't trust the
online merge tool, I just prefer to merge locally and run the tests if code
is affected.


> As far as applying changes to older branches, I think the easiest workflow
>> in Git is to develop the changes against the oldest branch and then merge
>> forward.  But since the GeoTools repo is produced from git-svn this won't
>> work well, so cherry-picking or rebasing is the way to go.  If you don't
>> want to add a remote for my repository you can just write:
>>
>
> Even if the branches did have a shared history a merge would be tricky as
> the branches do diverge. But then again cherry-picking also often results
> in conflicts so maybe it would be easier.
>

I think fully going with the flow here would require making the release
branch (8.x) fully behind master - that is, most of the time, merging 8.x
onto master should be a no-op.  See
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html ;
particularly the sections labelled 'Graduation' and 'Merging upwards.'  If
you don't work that way then you will end up having to rebase/cherry-pick
to duplicate changes across branches.


>
>> git fetch 
>> git://github.com/dwins/geotools.gitexception-swallowing-in-ImageMosaic
>>
>> After that my branch will appear as a local one for you named FETCH_HEAD.
>>
>
> Nice! Will have to remember this.
>
>>
>> --
>> David Winslow
>> OpenGeo - http://opengeo.org/
>>
>> On Wed, Jul 11, 2012 at 9:58 PM, Jody Garnett wrote:
>>
>>>  Morning David:
>>>
>>> I got a question that keeps me from just hitting the "merge" option on
>>> github (which is the magic of pull requests).
>>>
>>> Do we have an easy way to apply the "fix" to the older branches? Or is
>>> the author expecting the change to be applied to the older branches.
>>>
>>> take 1:
>>>
>>> Hit accept merge, and then cherry pick the resulting commit into the
>>> stable branch. This ignores doing a full build and so on …
>>>
>>> take 2:
>>>
>>> Accept the pull request manually; add you as a remote repository; grab
>>> the change onto my local machine; build and apply to master. And then
>>> repeat to build and apply on stable.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On Thursday, 12 July 2012 at 12:28 AM, David Winslow wrote:
>>>
>>> Given that the pull request was not summarily merged, I guess this
>>> counts as "more significant."  I have created a JIRA issue:
>>> http://jira.codehaus.org/browse/GEOT-4199
>>>
>>> --
>>> David Winslow
>>> OpenGeo - http://opengeo.org/
>>>
>>> On Wed, Jul 11, 2012 at 2:50 AM, Jody Garnett wrote:
>>>
>>>  I also am getting pull requests. I think for many casual uses
>>> (documentation fixes and so on) that a pull request is fine. It amounts to
>>> a light code review by another set of eyes.
>>>
>>> For anything more significant (fixes, new features, etc…) JIRA is really
>>> useful; and we can consider mentioning a pull request in Jira (as a nicer
>>> alternative to a patch)
>>>
>>> (This is consistent with how uDig is using Jira and GitHub; I note
>>> however that we often leave pull requests to die on the vine if any issues
>>> are not promptly sorted out)
>>> --
>>> Jody Garnett
>>>
>>> On Wednesday, 11 July 2012 at 11:58 AM, Justin Deoliveira wrote:
>>>
>>> Ha, you beat me to it Ben. Was just going to mention that our current
>>> policy for pull requests is to file a jira alongside a pull request so devs
>>> get the notification. However, I think i found the reason why we are not
>>> getting notified and its described here:
>>>
>>>   http://alexking.org/blog/2011/11/28/not-getting-github-notifications
>>>
>>> Myself, yourself, Andrea, and Jody were in the owners group and not the
>>> individual team groups. I figured one encompassed the other but i guess not
>>> when it comes to notifications. I confirmed with Gabriel that he does
>>> indeed get the pull request notifications.
>>>
>>> So I wonder... do we still need a jira to accompany a pull request? I am
>>> tempted to say no since it would seem to be needless overhead but there is
>>> the downside of the changelog not containing such patches. Tough call.
>>> Interested in hearing what other folks think.
>>>
>>> On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <
>>> ben.caradoc-dav...@csiro.au> wrote:
>>>
>>> Pull requests are a separate issu

Re: [Geoserver-devel] Pull requests

2012-07-12 Thread Justin Deoliveira 
On Thu, Jul 12, 2012 at 8:18 AM, David Winslow  wrote:

> Actually I rarely use the through-the-web merge tool on Github - for me
> the nice thing about pull requests is the ability to comment on the patch
> line-by-line, see new additions to the patch in the same comment thread,
> etc.  Here's a GeoNode pull request that used all that kind of stuff:
> https://github.com/GeoNode/geonode/pull/248


Interesting. So how do you merge in pull requests? Add the developers repo
as a remote and pull down the changes that way?

>
> As far as applying changes to older branches, I think the easiest workflow
> in Git is to develop the changes against the oldest branch and then merge
> forward.  But since the GeoTools repo is produced from git-svn this won't
> work well, so cherry-picking or rebasing is the way to go.  If you don't
> want to add a remote for my repository you can just write:
>

Even if the branches did have a shared history a merge would be tricky as
the branches do diverge. But then again cherry-picking also often results
in conflicts so maybe it would be easier.

>
> git fetch 
> git://github.com/dwins/geotools.gitexception-swallowing-in-ImageMosaic
>
> After that my branch will appear as a local one for you named FETCH_HEAD.
>

Nice! Will have to remember this.

>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Wed, Jul 11, 2012 at 9:58 PM, Jody Garnett wrote:
>
>>  Morning David:
>>
>> I got a question that keeps me from just hitting the "merge" option on
>> github (which is the magic of pull requests).
>>
>> Do we have an easy way to apply the "fix" to the older branches? Or is
>> the author expecting the change to be applied to the older branches.
>>
>> take 1:
>>
>> Hit accept merge, and then cherry pick the resulting commit into the
>> stable branch. This ignores doing a full build and so on …
>>
>> take 2:
>>
>> Accept the pull request manually; add you as a remote repository; grab
>> the change onto my local machine; build and apply to master. And then
>> repeat to build and apply on stable.
>>
>> --
>> Jody Garnett
>>
>> On Thursday, 12 July 2012 at 12:28 AM, David Winslow wrote:
>>
>> Given that the pull request was not summarily merged, I guess this counts
>> as "more significant."  I have created a JIRA issue:
>> http://jira.codehaus.org/browse/GEOT-4199
>>
>> --
>> David Winslow
>> OpenGeo - http://opengeo.org/
>>
>> On Wed, Jul 11, 2012 at 2:50 AM, Jody Garnett wrote:
>>
>>  I also am getting pull requests. I think for many casual uses
>> (documentation fixes and so on) that a pull request is fine. It amounts to
>> a light code review by another set of eyes.
>>
>> For anything more significant (fixes, new features, etc…) JIRA is really
>> useful; and we can consider mentioning a pull request in Jira (as a nicer
>> alternative to a patch)
>>
>> (This is consistent with how uDig is using Jira and GitHub; I note
>> however that we often leave pull requests to die on the vine if any issues
>> are not promptly sorted out)
>> --
>> Jody Garnett
>>
>> On Wednesday, 11 July 2012 at 11:58 AM, Justin Deoliveira wrote:
>>
>> Ha, you beat me to it Ben. Was just going to mention that our current
>> policy for pull requests is to file a jira alongside a pull request so devs
>> get the notification. However, I think i found the reason why we are not
>> getting notified and its described here:
>>
>>   http://alexking.org/blog/2011/11/28/not-getting-github-notifications
>>
>> Myself, yourself, Andrea, and Jody were in the owners group and not the
>> individual team groups. I figured one encompassed the other but i guess not
>> when it comes to notifications. I confirmed with Gabriel that he does
>> indeed get the pull request notifications.
>>
>> So I wonder... do we still need a jira to accompany a pull request? I am
>> tempted to say no since it would seem to be needless overhead but there is
>> the downside of the changelog not containing such patches. Tough call.
>> Interested in hearing what other folks think.
>>
>> On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <
>> ben.caradoc-dav...@csiro.au> wrote:
>>
>> Pull requests are a separate issue (mentioned at Monday's meeting).
>> Possibly because GeoServer is a GitHib organisation, nobody gets
>> notified about pull requests (I have heard mixed reports between GT and
>> GS).
>>
>> Have you created a GEOS Jira issue for the pull request? This might be
>> the most robust and traceable process.
>>
>> Anyone have a best-practice to recommend?
>>
>> On 11/07/12 08:32, David Winslow wrote:
>> > Anyway, I ended up more time than seems necessary because of some
>> > exceptions being silently swallowed in GeoTools code.  I issued a pull
>> > request against the new Github repo:
>> > https://github.com/geotools/geotools/pull/3
>> > I also made a patch against GeoServer.  Even though it wasn't causing my
>> > failure, it seems like there are some places in GeoServer where we rely
>> > on a directory containing a single image being used as a sin

Re: [Geoserver-devel] Pull requests

2012-07-12 Thread David Winslow 
Actually I rarely use the through-the-web merge tool on Github - for me the
nice thing about pull requests is the ability to comment on the patch
line-by-line, see new additions to the patch in the same comment thread,
etc.  Here's a GeoNode pull request that used all that kind of stuff:
https://github.com/GeoNode/geonode/pull/248

As far as applying changes to older branches, I think the easiest workflow
in Git is to develop the changes against the oldest branch and then merge
forward.  But since the GeoTools repo is produced from git-svn this won't
work well, so cherry-picking or rebasing is the way to go.  If you don't
want to add a remote for my repository you can just write:

git fetch git://github.com/dwins/geotools.gitexception-swallowing-in-ImageMosaic

After that my branch will appear as a local one for you named FETCH_HEAD.

--
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jul 11, 2012 at 9:58 PM, Jody Garnett wrote:

>  Morning David:
>
> I got a question that keeps me from just hitting the "merge" option on
> github (which is the magic of pull requests).
>
> Do we have an easy way to apply the "fix" to the older branches? Or is the
> author expecting the change to be applied to the older branches.
>
> take 1:
>
> Hit accept merge, and then cherry pick the resulting commit into the
> stable branch. This ignores doing a full build and so on …
>
> take 2:
>
> Accept the pull request manually; add you as a remote repository; grab the
> change onto my local machine; build and apply to master. And then repeat to
> build and apply on stable.
>
> --
> Jody Garnett
>
> On Thursday, 12 July 2012 at 12:28 AM, David Winslow wrote:
>
> Given that the pull request was not summarily merged, I guess this counts
> as "more significant."  I have created a JIRA issue:
> http://jira.codehaus.org/browse/GEOT-4199
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Wed, Jul 11, 2012 at 2:50 AM, Jody Garnett wrote:
>
>  I also am getting pull requests. I think for many casual uses
> (documentation fixes and so on) that a pull request is fine. It amounts to
> a light code review by another set of eyes.
>
> For anything more significant (fixes, new features, etc…) JIRA is really
> useful; and we can consider mentioning a pull request in Jira (as a nicer
> alternative to a patch)
>
> (This is consistent with how uDig is using Jira and GitHub; I note however
> that we often leave pull requests to die on the vine if any issues are not
> promptly sorted out)
> --
> Jody Garnett
>
> On Wednesday, 11 July 2012 at 11:58 AM, Justin Deoliveira wrote:
>
> Ha, you beat me to it Ben. Was just going to mention that our current
> policy for pull requests is to file a jira alongside a pull request so devs
> get the notification. However, I think i found the reason why we are not
> getting notified and its described here:
>
>   http://alexking.org/blog/2011/11/28/not-getting-github-notifications
>
> Myself, yourself, Andrea, and Jody were in the owners group and not the
> individual team groups. I figured one encompassed the other but i guess not
> when it comes to notifications. I confirmed with Gabriel that he does
> indeed get the pull request notifications.
>
> So I wonder... do we still need a jira to accompany a pull request? I am
> tempted to say no since it would seem to be needless overhead but there is
> the downside of the changelog not containing such patches. Tough call.
> Interested in hearing what other folks think.
>
> On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <
> ben.caradoc-dav...@csiro.au> wrote:
>
> Pull requests are a separate issue (mentioned at Monday's meeting).
> Possibly because GeoServer is a GitHib organisation, nobody gets
> notified about pull requests (I have heard mixed reports between GT and
> GS).
>
> Have you created a GEOS Jira issue for the pull request? This might be
> the most robust and traceable process.
>
> Anyone have a best-practice to recommend?
>
> On 11/07/12 08:32, David Winslow wrote:
> > Anyway, I ended up more time than seems necessary because of some
> > exceptions being silently swallowed in GeoTools code.  I issued a pull
> > request against the new Github repo:
> > https://github.com/geotools/geotools/pull/3
> > I also made a patch against GeoServer.  Even though it wasn't causing my
> > failure, it seems like there are some places in GeoServer where we rely
> > on a directory containing a single image being used as a single-tile
> > imagemosaic instead of using a more specific coveragestore.  I think it
> > makes things a bit cleaner to use the more specific type where it's
> > known: https://github.com/geoserver/geoserver/pull/4
>
> --
> Ben Caradoc-Davies 
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
>

[Geoserver-devel] [jira] (GEOS-5167) Metadata URL in WMS 1.3.0 capabilities is wrong host is localhost

2012-07-12 Thread Justin Deoliveira (JIRA) 














































Justin Deoliveira
 reopened  GEOS-5167


Metadata URL in WMS 1.3.0 capabilities is wrong host is localhost
















Change By:


Justin Deoliveira
(12/Jul/12 9:07 AM)




Status:


Resolved
Reopened





Resolution:


Fixed



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [Hudson] Build failed in Hudson: geoserver-2.1.x-deploy #655

2012-07-12 Thread Hudson 
See 

--
Started by upstream project "geoserver-2.1.x" build number 740
[src] $ /opt/apache-maven-2.2.1/bin/mvn -U -Djava.awt.headless=true -DskipTests 
-DconfigDirectory=../../../data -P allExtensions,monitoring,proxy,printing,ftp 
deploy
[INFO] Scanning for projects...
[INFO] Reactor build order: 
[INFO]   GeoServer
[INFO]   GeoServer Maven Plugins
[INFO]   Configuration Deployment PlugIn
[INFO]   GeoServer Maven Archetypes
[INFO]   GeoServer Web Plugin Archetype
[INFO]   GeoServer WFS Output Format Archetype
[INFO]   Core Platform Module
[INFO]   Open Web Service Module
[INFO]   Main Module
[INFO]   Web Coverage Service Module
[INFO]   Web Coverage Service 1.0 Module
[INFO]   Web Coverage Service 1.1 Module
[INFO]   Web Feature Service Module
[INFO]   Web Map Service Module
[INFO]   GeoWebCache (GWC) Module
[INFO]   REST Support Module
[INFO]   REST Configuration Service Module
[INFO]   GeoServer Web Modules
[INFO]   Core UI Module
[INFO]   WMS UI Module
[INFO]   GWC UI Module
[INFO]   WFS UI Module
[INFO]   Demoes Module
[INFO]   WCS UI Module
[INFO]   Security UI Module
[INFO]   Community Space
[INFO]   Printing Module
[INFO]   HTTP Proxy Extension
[INFO]   GeoServer Embedded FTP server
[INFO]   GeoServer Monitoring Extension
[INFO]   GeoServer Web Application
[INFO]   GeoServer Extensions
[INFO]   Application Schema Support
[INFO]   Application Schema Integration Test
[INFO]   Sample DataAccess Integration Test
[INFO]   ArcSDE DataStore Extension
[INFO]   GeoSearch Index Module
[INFO]   H2 DataStore Extension
[INFO]   SQL Server DataStore Extension
[INFO]   Oracle DataStore Extension
[INFO]   MySQL DataStore Extension
[INFO]   DB2 DataStore Extension
[INFO]   ImageMap Output Format
[INFO]   JP2K Coverage Extension
[INFO]   ogr2ogr Output Format
[INFO]   Excel Output Format
[INFO]   Validation Module
[INFO]   Chart external graphics support
[INFO]   Feature Generalization Extension
[INFO]   Image Mosaic JDBC Extension
[INFO]   OWS request flow controller
[INFO]   Web Processing Service parent
[INFO]   Web Processing Service Module
[INFO]   Web Processing Service GUI
[INFO]   GeoServer Layer Querying filter functions
[INFO]   Teradata DataStore Extension
[INFO] 
[INFO] Building GeoServer
[INFO]task-segment: [deploy]
[INFO] 
[INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
[INFO] snapshot org.geotools:gt-api:2.7-SNAPSHOT: checking for updates from 
opengeo
[WARNING] repository metadata for: 'snapshot org.geotools:gt-api:2.7-SNAPSHOT' 
could not be retrieved from repository: opengeo due to an error: Error 
transferring file: repo.opengeo.org
[INFO] Repository 'opengeo' will be blacklisted
[INFO] snapshot org.geotools:gt-api:2.7-SNAPSHOT: checking for updates from 
osgeo
[INFO] snapshot org.geotools:library:2.7-SNAPSHOT: checking for updates from 
osgeo
[INFO] snapshot org.geotools:modules:2.7-SNAPSHOT: checking for updates from 
osgeo
[INFO] snapshot org.geotools:geotools:2.7-SNAPSHOT: checking for updates from 
osgeo
[INFO] snapshot org.geotools:gt-referencing:2.7-SNAPSHOT: checking for updates 
from osgeo
[INFO] snapshot org.geotools:gt-referencing:2.7-SNAPSHOT: checking for updates 
from maven2-repository.dev.java.net
[INFO] snapshot org.geotools:gt-referencing:2.7-SNAPSHOT: checking for updates 
from geosolutions
[INFO] snapshot org.geotools:gt-metadata:2.7-SNAPSHOT: checking for updates 
from osgeo
[INFO] snapshot org.geotools:gt-metadata:2.7-SNAPSHOT: checking for updates 
from maven2-repository.dev.java.net
[INFO] snapshot org.geotools:gt-metadata:2.7-SNAPSHOT: checking for updates 
from geosolutions
[INFO] snapshot org.geotools:gt-opengis:2.7-SNAPSHOT: checking for updates from 
osgeo
[INFO] snapshot org.geotools:gt-opengis:2.7-SNAPSHOT: checking for updates from 
maven2-repository.dev.java.net
[INFO] snapshot org.geotools:gt-opengis:2.7-SNAPSHOT: checking for updates from 
geosolutions
[INFO] snapshot org.geotools:gt-main:2.7-SNAPSHOT: checking for updates from 
osgeo
[INFO] [jar:test-jar {execution: default}]
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Preparing source:test-jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[WARNING] Removing: test-jar from forked lifecycle, to prevent recursive 
invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:test-jar {execution: attach-sources}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing 
 to 
/usr/share/

[Geoserver-devel] [jira] (GEOS-5219) WMS 1.3 cite tests fail on metadata mime type

2012-07-12 Thread Andrea Aime (JIRA) 














































Andrea Aime
 created  GEOS-5219


WMS 1.3 cite tests fail on metadata mime type















Issue Type:


Bug



Assignee:


Andrea Aime



Components:


WMS



Created:


12/Jul/12 2:40 AM



Description:


 Testing getcapabilities:resource-format (wms-1.3.0/d3717e364_1/d627e30_1/d627e157_1/d627e1444_3)...
 [exec]   Assertion: The MIME-type returned for the MetadataURL for Layer cite:Bridges is application/xml.
 [exec]   Error: The actual MIME-type for 'http://localhost:11010/www/Bridges.xml' is 'text/html; charset=iso-8859-1'




Fix Versions:


2.2-RC2



Project:


GeoServer



Priority:


Critical



Reporter:


Andrea Aime




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [Hudson] Build failed in Hudson: cite-wms-1.3-master #408

2012-07-12 Thread Hudson 
See 

--
[...truncated 1884 lines...]
 [exec]Assertion: For style "Forests", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_7)...
 [exec]Assertion: For style "Lakes", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_8)...
 [exec]Assertion: For style "polygon", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_9)...
 [exec]Assertion: For style "MapNeatline", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_10)...
 [exec]Assertion: For style "NamedPlaces", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_11)...
 [exec]Assertion: For style "Ponds", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_12)...
 [exec]Assertion: For style "RoadSegments", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec] Testing getmap:each-style 
(wms-1.3.0/d3717e372_1/d1097e54_1/d1097e317_13)...
 [exec]Assertion: For style "Streams", when the STYLES 
parameter is set to that style name, the MIME type of the response is valid.
 [exec] Test getmap:each-style Passed
 [exec]  Test getmap:styles Passed
 [exec]  Testing getmap:transparent 
(wms-1.3.0/d3717e372_1/d1097e56_1)...
 [exec] Assertion: The TRANSPARENT parameter behaves properly.
 [exec] Testing getmap:transparent-default 
(wms-1.3.0/d3717e372_1/d1097e56_1/d1097e339_1)...
 [exec]Assertion: When a GetMap request is made with no 
TRANSPARENT parameter and a FORMAT that supports transparency over a layer that 
is not opaque, then the response contains no transparent pixels.
 [exec] Test getmap:transparent-default Passed
 [exec] Testing getmap:transparent-false 
(wms-1.3.0/d3717e372_1/d1097e56_1/d1097e341_1)...
 [exec]Assertion: When a GetMap request is made with 
TRANSPARENT=FALSE and a FORMAT that supports transparency over a layer that is 
not opaque, then the response contains no transparent pixels.
 [exec] Test getmap:transparent-false Passed
 [exec] Testing getmap:transparent-true 
(wms-1.3.0/d3717e372_1/d1097e56_1/d1097e345_1)...
 [exec]Assertion: When a GetMap request is made with 
TRANSPARENT=TRUE and a FORMAT that supports transparency over a BBOX that is 
not completely covered, then the response contains transparent pixels.
 [exec] Test getmap:transparent-true Passed
 [exec] Testing getmap:transparent-opaque-layer 
(wms-1.3.0/d3717e372_1/d1097e56_1/d1097e348_1)...
 [exec]Assertion: Clients may request TRANSPARENT=TRUE on a 
layer that is opaque.
 [exec]No named opaque layers.
 [exec] Test getmap:transparent-opaque-layer Passed
 [exec]  Test getmap:transparent Passed
 [exec]  Testing getmap:width-and-height 
(wms-1.3.0/d3717e372_1/d1097e61_1)...
 [exec] Assertion: The WIDTH and HEIGHT parameters behaves 
properly.
 [exec] Testing getmap:large-size 
(wms-1.3.0/d3717e372_1/d1097e61_1/d1097e362_1)...
 [exec]Assertion: When a request is made for a large map 
(1024x768 or largest map supported), the image returned is exactly the size 
requested.
 [exec] Test getmap:large-size Passed
 [exec] Testing getmap:small-size 
(wms-1.3.0/d3717e372_1/d1097e61_1/d1097e364_1)...
 [exec]Assertion: When a request is made with WIDTH=8 and 
HEIGHT=5, the image returned i