Justin Deoliveira ha scritto:
> Hi all,
>
> So I just moved the nightly build stuff from a cron job on the build box
> to a proper hudson jobs:
>
> http://hudson.opengeo.org/hudson/job/geoserver-1.7.x-nightly/
> http://hudson.opengeo.org/hudson/job/geoserver-trunk-nightly/
>
> The artifacts end
Luis Amorim ha scritto:
> Hi,
>
> I'm trying to build GeoServer 1.7.x with maven (2.0.9) at ubuntu 9.04,
> but I get the build error below when I use "mvn install"
>
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
> ---
Hi,
I'm trying to build GeoServer 1.7.x with maven (2.0.9) at ubuntu 9.04, but I
get the build error below when I use "mvn install"
[INFO]
[ERROR] BUILD ERROR
[INFO]
--
Justin Deoliveira wrote:
> Hi all,
>
> Sorry this is coming out late this week. For future reference those that
> have a better memory than I do please don't hesitate to send this email.
> I would like to keep this a weekly habit... unless others think that
> this is a futile exercise?
>
> * 1
Justin Deoliveira wrote:
> Anyways, another thing to note is that hudson will not bug us on the
> list when a nightly fails. So hopefully we won't run into the situation
> where nightly builds failing for days goes unnoticed.
Justin, I did not understand this. Did you mean it will bug us on the
Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> As promised updated docs:
>>
>> http://docs.geoserver.org/trunk/developer/cite-test-guide/index.html
>
> Tried this out, got an error while building the app:
>
> aa...@phoenix:~/devel/gstrunk/src/community/cite$ mvn install
> [INFO] Scanning f
I found them relatively useful in confluence... especially the ability
to aggregate all of them into a single list on the page. Which sphinx
supports as well.
Mike Pumphrey wrote:
> Ahh good point. How do people feel about the .. todo:: ? I've been going
> back and forth on it. I don't belie
Hide "WFSDataStoreFactory" string when creating a new datastore from an
external WFS
Key: GEOS-3286
URL: http://jira.codehaus.org/browse/GEOS-3286
Project: GeoServer
Hi guys, may be some of you could bring some light to this problem
that's killing me.
I got a 3-band, 16-bit unsigned raster, whose sample range is 0..255 and
the nodata value is 256. I need to get geoserver interpreting it as an
RGB image and it does, only that since the sample range is so st
While trying to save a feature-type from a PostGIS datastore, GeoServer throws
a nasty error.
--
Key: GEOS-3285
URL: http://jira.codehaus.org/browse/GEOS-3285
BTW, I did a bit of a refresh on the docguide yesterday, adding in some new
suggestions posed over the past month or two and filling out most of the empty
sections (although if someone (Jody? Alyssa?) would like to populate the
section on how to install Sphinx on OS X, that would be nice).
http
the default rest page show give the status of the installed rest modules.
--
Key: GEOS-3284
URL: http://jira.codehaus.org/browse/GEOS-3284
Project: GeoServer
Issue Type
When native and declared CRS match, a coverage's SRS hanlding strategy is set
to "reproject" instead of "keep native"
-
Key: GEOS-3283
URL: http://
Ahh good point. How do people feel about the .. todo:: ? I've been going back
and forth on it. I don't believe it's implemented on any of the projects,
currently, unless I just can't find it.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
Justin Deoliveira wrote:
> Good question. I woul
Justin Deoliveira ha scritto:
> As promised updated docs:
>
> http://docs.geoserver.org/trunk/developer/cite-test-guide/index.html
Tried this out, got an error while building the app:
aa...@phoenix:~/devel/gstrunk/src/community/cite$ mvn install
[INFO] Scanning for projects...
[INFO]
--
Map shifted when using metatling and the current tile is very far away from the
tile origin
---
Key: GEOS-3282
URL: http://jira.codehaus.org/browse/GEOS-3282
Proj
Hi all,
So I just moved the nightly build stuff from a cron job on the build box
to a proper hudson jobs:
http://hudson.opengeo.org/hudson/job/geoserver-1.7.x-nightly/
http://hudson.opengeo.org/hudson/job/geoserver-trunk-nightly/
The artifacts end up in the same place as they did before.
One a
>
> * 2.0-RC1 issues
>
> The following high priority issues are still open:
> ,
> - http://jira.codehaus.org/browse/GEOS-2887, jdeolive
> Porting restconfig to trunk
Done, but required some other patches to the core that need discussion.
Regardless will be resolved soon.
>
> - http://j
Hi all,
Sorry this is coming out late this week. For future reference those that
have a better memory than I do please don't hesitate to send this email.
I would like to keep this a weekly habit... unless others think that
this is a futile exercise?
* 1.7.6 release date
So we more or less agr
Andrea Aime wrote:
> Ben Caradoc-Davies ha scritto:
>> Deployment scripts and "patch -p0" are your friend.
>
> Yeah. The topic is interesting. Do you have any sample script to
> share?
I am rewriting one at the moment. I will publish it when it is done.
--
Ben Caradoc-Davies
Software Engineer,
Ben, you are not forced to put the geoserver config data into the j2ee
directory tree. Geoserver can create its own initial context for its data on
startup.
I did this actually using an ldap server, getting my own initial Context and
handling user profiles within J2EE (Websphere). Forget abou
If I understand you right, you want a node in the jndi directory structure
acting as the root node for the application.
See the followoing examples, the initial root node is passed with
"java.naming.provider.url".
# java -Djava.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory \
-
See http://hudson.opengeo.org/hudson/job/geoserver-trunk/1464/
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/lis
Andrea Aime wrote:
> One thing that is not clear to me is whether it's possible to declare
> access to a root in JNDI and then be able to access by it all resources
> under it, or if any resource has to be declared separately.
> The former would be oh so much nicer ;)
> Ben, Christian, any clue?
I
Ben Caradoc-Davies ha scritto:
> Andrea Aime wrote:
>> It would seem that people find fiddling with JNDI entries preferrable
>> than editing files. It's probably easier to do that with bigger
>> containers or just the way webapp admins are used to, who knows
>
> Exactly. Just set up your options
Just a race condition (GS build kicked off, required GT build to pass).
Build passes on our buildbot, which forces a GT build before GS.
http://geobuilder.arrc.csiro.au/geoserver/builders/GeoT-java15/builds/1649
Hudson wrote:
> See http://hudson.opengeo.org/hudson/job/geoserver-trunk/1463/change
Justin Deoliveira ha scritto:
> Andrea Aime wrote:
>> Justin Deoliveira ha scritto:
>>> What would be the benefit over how it is configured now via the
>>> context parameter? Unless there is some benefit I would generally be
>>> against it since it would yet another way to do the same thing. And
Mike Pumphrey ha scritto:
> I don't think I was trying to suggest that all docs _have_ to go through
> me, only that I am making myself available should people wish to have
> someone review.
Don't get me wrong, I wasn't trying to put words in your mails, just
wanted to make sure everybody is on
Andrea Aime wrote:
> It would seem that people find fiddling with JNDI entries preferrable
> than editing files. It's probably easier to do that with bigger
> containers or just the way webapp admins are used to, who knows
Exactly. Just set up your options and resources in Tomcat, configure
ever
See http://hudson.opengeo.org/hudson/job/geoserver-trunk/1463/changes
Changes:
[RiniAngreani] Test filtering features that are encoded as xlink:href
--
[...truncated 15976 lines...]
http://example.com"; xmlns:gml="http://www.opengis.net/gml";
xmlns:gsm
Thanks very much, Justin.
Justin Deoliveira wrote:
> The recent move of the web module had svn out of wak. Fixed, a fresh
> nightly build should be up shortly.
>
> Ben Caradoc-Davies wrote:
>> Sorry, wrong list. Please ignore.
>>
>> Ben Caradoc-Davies wrote:
>>> The latest nightly build for trun
Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> What would be the benefit over how it is configured now via the
>> context parameter? Unless there is some benefit I would generally be
>> against it since it would yet another way to do the same thing. And
>> unless you are a perl programmer
Justin Deoliveira ha scritto:
> What would be the benefit over how it is configured now via the context
> parameter? Unless there is some benefit I would generally be against it
> since it would yet another way to do the same thing. And unless you are
> a perl programmer multiple ways to do the
33 matches
Mail list logo
