e devops organization to accrue the benefits of the open
> source azure devops sla, and delegate permissions to whoever is going to
> accomplish the above tasks
>
> regards
>
> --
> *From:* Jody Garnett
> *Sent:* Sunday, December 24, 2023 2:26 AM
> *To:*
_
From: Jody Garnett
Sent: Sunday, December 24, 2023 2:26 AM
To: sechelé delaruse
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] windows build server
That is interesting; my employer GeoCat has setup Jenkins on an azure build
server. So we should update that pag
Here is a PR with a clarification:
https://github.com/geoserver/geoserver/pull/7330
Please review.
--
Jody Garnett
On Dec 23, 2023 at 11:26:54 PM, Jody Garnett wrote:
> That is interesting; my employer GeoCat has setup Jenkins on an azure
> build server. So we should update that page.
>
> (We
That is interesting; my employer GeoCat has setup Jenkins on an azure
build server. So we should update that page.
(We do still lack a macOS build server.)
--
Jody Garnett
On Dec 23, 2023 at 7:46:34 PM, sechelé delaruse wrote:
> on the first day of christmas i noticed that this url
> https://
on the first day of christmas i noticed that this url
https://docs.geoserver.org/stable/en/developer/installer/index.html contains
the following content
At the time the GeoServer project does not have financial resources and man
power to stand up a Windows build server (if you can help with t
Hi,
I've just disabled all build failure notifications from the Windows build
server,
as we are experiencing severe clock fluctuations on the machine.
We'll be looking into it in the next weeks, and enable the notifications
back
once we have brought the server back to sanity
Cheers
Andrea
--
==
Hi Andrea
Yep, please remove/comment the finalize method and lets have a look at the
results.
Cheers
Christian
On Mon, Apr 27, 2015 at 7:14 PM, Andrea Aime
wrote:
> On Mon, Apr 27, 2015 at 3:16 PM, Andrea Aime > wrote:
>
>> On Mon, Apr 27, 2015 at 3:14 PM, Christian Mueller <
>> christian.mue
On Mon, Apr 27, 2015 at 3:16 PM, Andrea Aime
wrote:
> On Mon, Apr 27, 2015 at 3:14 PM, Christian Mueller <
> christian.muel...@os-solutions.at> wrote:
>
>> Hi Andrea
>>
>> XMLUserGroupStore and XMLRoleStore have a method releaseLock which should
>> do the job.
>>
>> As far as I can remember, org.
On Mon, Apr 27, 2015 at 3:14 PM, Christian Mueller <
christian.muel...@os-solutions.at> wrote:
> Hi Andrea
>
> XMLUserGroupStore and XMLRoleStore have a method releaseLock which should
> do the job.
>
> As far as I can remember, org.geoserver.security.file.LockFile.finalize()
> is a safeguard.
>
Hi Andrea
XMLUserGroupStore and XMLRoleStore have a method releaseLock which should
do the job.
As far as I can remember, org.geoserver.security.file.LockFile.finalize()
is a safeguard.
Any idea where to call releaseLock to avoid this problem.
Cheers
Christian
On Mon, Apr 27, 2015 at 2:47 PM
On Mon, Apr 27, 2015 at 2:41 PM, Christian Mueller <
christian.muel...@os-solutions.at> wrote:
> +1
> Unfortunately there is no Windows around me for investigations.
>
Hi Christian,
the issue is difficult to reproduce but I have a hunch. The lock file is
always the same, however
I can see that du
+1
Unfortunately there is no Windows around me for investigations.
Cheers
Christian
On Fri, Apr 24, 2015 at 9:30 AM, Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:
> +1
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts! Visit
> http://
+1
Regards,
Simone Giannecchini
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Ing. Simone Giannecchini
@simogeo
Founder/Director
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39
Hi,
the windows build keeps on running once per hour to locate spurious
failures,
as far as I could see during the last week we are down to two common
failures:
a) XML security tests leaving files open, which cannot be cleaned up after
(, e.g.
http://winbuild.geo-solutions.it/jenkins/job/GeoServer-
Thanks for the discussion Olle, the fix has been merged.
--
Jody Garnett
On 3 February 2015 at 14:45, Olle Markljung wrote:
> Yes it will.
> But the problem here is that we do not know the intention of the user.
> Existing code has a different handling of file:// urls on windows than on
> other
Yes it will.
But the problem here is that we do not know the intention of the user.
Existing code has a different handling of file:// urls on windows than on
other platforms.
On Windows file://images/poi.png will be converted into \\images\poi.png.
An absolute path to the host images.
On other plat
Since (in GeoServer) we try to discourage the use of absolute paths I guess
I am fine with the way things stand.
If we were just focused on manipulating the file path in a safe manner the
Java Paths API would help (since we actually want to check a file on disk I
expect the Files API is fine).
Co
Yes, it checks if the file at the absolute path exists and if not assumes
the path is relative.
You could swap the order making the relative path default.
Fail? The tests use paths to files that does not exist.
The result will be that the path to the file will be relative. And that's
the same resu
One of the lines in your pull request uses the test if (!f.exists())
This only works if the DataUtilities.urlToFile method is referring to a
file that has been created yet. If we try the same logic on a file that
does not exist yet it will fail...
--
Jody Garnett
On 1 February 2015 at 06:36, Oll
Sorry for the delay.
Ticket: http://jira.codehaus.org/browse/GEOT-4990
PR: https://github.com/geotools/geotools/pull/717
This builds clean using "mvn clean install" on my machine (building
geotools).
Should I communicate this on the geotools list as well?
Not sure that I understand what you mean
Sounds like a good approach - we may also be able to use Java 7 Path API.
I should also point out that we may be using this to figure out a the
location of a *new* file (like one that does not exist yet). Perhaps the
Java 7 path api can help.
--
Jody
--
Jody Garnett
On 20 January 2015 at 15:28,
Ok,
Perhaps it is not easy to say in what ways it all should work. Someone
ought to be depending on the code doing this specific thing on Windows
since the code exists.
So, I got a proposition.
What if we in DataUtilities.urlToFile do the same as
DefaultResourceLocator.locateResource already does.
Ok.
Looking at the history I can't find anything that changed. Version of Java
did change to 7.
These urls also fail in GeoTools.
It's not the usage of urlToFile in the test that's the problem but the
usage of urlToFile in the DefaultResourceLocator.locateResource.
The file:// is converted to // b
On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung wrote:
> Yes, I see now that I was a bit unclear with my intentions of the last
> paragraph.
>
> However, I believe that the usage of the file protocol makes it unclear as
> when the file path will be interpreted as relative over absolute.
>
> I can
Yes, I see now that I was a bit unclear with my intentions of the last
paragraph.
However, I believe that the usage of the file protocol makes it unclear as
when the file path will be interpreted as relative over absolute.
I can get back to you with some exemples and maybe we can document the
req
On Mon, Jan 19, 2015 at 12:58 AM, Olle Markljung
wrote:
> Should "file://images/rockFillSymbol.png" be interpreted as equal to
> "images/rockFillSymbol.png" and "./images/rockFillSymbol.png"?
> According to
> http://stackoverflow.com/questions/7857416/file-uri-scheme-and-relative-files
> you cann
Ok!
I'll look into it.
/Olle
måndag 19 januari 2015 skrev Jody Garnett :
> In this case we started with relative paths (and the base data directory)
> and turned the results into absolute paths as part of the test to make sure
> we are pointing at the right file.
>
> The GeoTools method DataUtil
In this case we started with relative paths (and the base data directory)
and turned the results into absolute paths as part of the test to make sure
we are pointing at the right file.
The GeoTools method DataUtiltieis.urlToFile is what is being tested here,
and it is letting us down!
public
Hi,
I can try to help. We use Windows and GeoServer at work.
But perhaps I need some guidance..
This is what the tests gives me. The failing one using file:// and the
successful one using ./
SLD attribute
"file://images/rockFillSymbol.png"
Linkage
file://images/rockFillSymbol.png
Converted to
\\
Okay we can consider it a goal for the year ( or a sprint activity if we
get a Windows volunteer ).
On Sun, Jan 18, 2015 at 12:01 PM Andrea Aime
wrote:
> On Sun, Jan 18, 2015 at 8:06 PM, Jody Garnett
> wrote:
>
>> From Simone's email to getools-devel:
>>
>> a while ago we agree on having a windo
On Sun, Jan 18, 2015 at 8:06 PM, Jody Garnett
wrote:
> From Simone's email to getools-devel:
>
> a while ago we agree on having a windows build server for geotools
>> which is reachable here:
>> http://winbuild.geo-solutions.it/jenkins
>> credentials are the same for the linux build server.
>
>
>
>From Simone's email to getools-devel:
a while ago we agree on having a windows build server for geotools
> which is reachable here:
> http://winbuild.geo-solutions.it/jenkins
> credentials are the same for the linux build server.
I was able to restore the build for geotools-devel, but it looks
Dear All,
I just wanted to let you know that I have almost done with setting up
the windows build server for GT and GS. There are still failure for GS
that I want to investigate as I am not sure they are
caused by running on windows or rather by the config I put together.
The server can be reached
Hi,
the Windows build server I've been working on is finally online:
http://office.geo-solutions.it/jenkins/
The machine is a Vista 64 bits one, with the build running in paths with
embedded
spaces over Java 6.
Right now the builds are running during the italian night, once a day.
The GeoServer b
34 matches
Mail list logo
