Re: [Geoserver-devel] windows build server
My employer GeoCat is hosing some azure build services (which is how we have windows build downloads presently). Can azure supplier a macOS build environment? -- Jody Garnett On Tue, Dec 26, 2023 at 1:18 PM sechelé delaruse wrote: > howdy > < (We do still lack a macOS build server.) > > i skimmed the docs but the only real mention of macos was here > https://github.com/geoserver/geoserver/blob/main/build/mac_installer.sh > > the product of mac_installer.sh is a .dmg as per > # upload dmg to final location > upload_installer $tag geoserver-$tag.dmg > > assuming > >- no signing of the distribution with an apple developer certificate >-> if signing required details are required on how this is currently >accomplished >- mac_installer.sh is the workflow entrypoint for building a macos >distribution >- no macos build server required > > > if the above assumptions are true builds can be accomplished at will in > azure devops as follows > >- ensure an organization in azure devops >- ensure a public project to host the build, ensuring open source sla >which is unlimited builds >- create a pipeline that can clone the required assets from github >- ensure a linux build agent >- add a script task to the pipeline initialized to the location >required by mac_installer.sh >- ensure pipeline auth to the upload location >- ensure pipeline artifact versioning >- ensure permissions and pipeline triggers > > > if no personpower is available to accomplish these tasks certainly i can > make those things happen > > these are some pipelines i currently operate in azure devops - the target > environment is kubernetes, the artifacts are npm and nuget packages and > python whatevers and docker images, with an expectation that the customer > may want to operate a geoserver instance in the cluster, hence my interest > >- >https://dev.azure.com/electricrucible/the%20horseless%20newspaper/_build > >- https://dev.azure.com/electricrucible/metoffice/_build > > > on the matter of task 'ownership' i would suggest that if there is a > corporate entity associated with producing geoserver builds, that entity > should own the azure 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:* sechelé delaruse > *Cc:* geoserver-devel@lists.sourceforge.net < > 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 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://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 this, > please contact the developer list) > > > if this is no longer true please disregard > > if build server still required > >- i happen to know that as an open source project the geoserver >project can run unlimited builds in azure devops. so can anyone else who >clones the repo in a public azure devops project >- after investigating the geoserver github actions i saw nothing >incompatible with triggering builds in azure devops in collaboration with >specific github actions >- the primary showstopper risk seems to revolve around headless >installation of nsis itself and its dependencies on azure build servers as >per > - extract the .DLL files (AccessControl.dll) and copy it to the > NSIS plugins directory usually > C:\Program Files\NSIS\Plugins\x86-ansi > > > if build server still required and mitigations exist for installing nsis > and dependencies on cloud build agents, i offer to > >- evaluate the full build process for the windows geoserver >- deliver a proof of concept of a suitable pipeline that runs in azure >devops > > > please advice > ___ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server
howdy < (We do still lack a macOS build server.) i skimmed the docs but the only real mention of macos was here https://github.com/geoserver/geoserver/blob/main/build/mac_installer.sh the product of mac_installer.sh is a .dmg as per # upload dmg to final location upload_installer $tag geoserver-$tag.dmg assuming * no signing of the distribution with an apple developer certificate -> if signing required details are required on how this is currently accomplished * mac_installer.sh is the workflow entrypoint for building a macos distribution * no macos build server required if the above assumptions are true builds can be accomplished at will in azure devops as follows * ensure an organization in azure devops * ensure a public project to host the build, ensuring open source sla which is unlimited builds * create a pipeline that can clone the required assets from github * ensure a linux build agent * add a script task to the pipeline initialized to the location required by mac_installer.sh * ensure pipeline auth to the upload location * ensure pipeline artifact versioning * ensure permissions and pipeline triggers if no personpower is available to accomplish these tasks certainly i can make those things happen these are some pipelines i currently operate in azure devops - the target environment is kubernetes, the artifacts are npm and nuget packages and python whatevers and docker images, with an expectation that the customer may want to operate a geoserver instance in the cluster, hence my interest * https://dev.azure.com/electricrucible/the%20horseless%20newspaper/_build * https://dev.azure.com/electricrucible/metoffice/_build on the matter of task 'ownership' i would suggest that if there is a corporate entity associated with producing geoserver builds, that entity should own the azure 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: 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 page. (We do still lack a macOS build server.) -- Jody Garnett On Dec 23, 2023 at 7:46:34 PM, sechelé delaruse mailto:sech...@ataxlab.com>> wrote: 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 this, please contact the developer list) if this is no longer true please disregard if build server still required * i happen to know that as an open source project the geoserver project can run unlimited builds in azure devops. so can anyone else who clones the repo in a public azure devops project * after investigating the geoserver github actions i saw nothing incompatible with triggering builds in azure devops in collaboration with specific github actions * the primary showstopper risk seems to revolve around headless installation of nsis itself and its dependencies on azure build servers as per * extract the .DLL files (AccessControl.dll) and copy it to the NSIS plugins directory usually C:\Program Files\NSIS\Plugins\x86-ansi if build server still required and mitigations exist for installing nsis and dependencies on cloud build agents, i offer to * evaluate the full build process for the windows geoserver * deliver a proof of concept of a suitable pipeline that runs in azure devops please advice ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net<mailto:Geoserver-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/geoserver-devel ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server
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 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://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 this, >> please contact the developer list) >> >> >> if this is no longer true please disregard >> >> if build server still required >> >>- i happen to know that as an open source project the geoserver >>project can run unlimited builds in azure devops. so can anyone else who >>clones the repo in a public azure devops project >>- after investigating the geoserver github actions i saw nothing >>incompatible with triggering builds in azure devops in collaboration with >>specific github actions >>- the primary showstopper risk seems to revolve around headless >>installation of nsis itself and its dependencies on azure build servers as >>per >> - extract the .DLL files (AccessControl.dll) and copy it to the >> NSIS plugins directory usually >> C:\Program Files\NSIS\Plugins\x86-ansi >> >> >> if build server still required and mitigations exist for installing nsis >> and dependencies on cloud build agents, i offer to >> >>- evaluate the full build process for the windows geoserver >>- deliver a proof of concept of a suitable pipeline that runs in >>azure devops >> >> >> please advice >> ___ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
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 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://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 this, > please contact the developer list) > > > if this is no longer true please disregard > > if build server still required > >- i happen to know that as an open source project the geoserver >project can run unlimited builds in azure devops. so can anyone else who >clones the repo in a public azure devops project >- after investigating the geoserver github actions i saw nothing >incompatible with triggering builds in azure devops in collaboration with >specific github actions >- the primary showstopper risk seems to revolve around headless >installation of nsis itself and its dependencies on azure build servers as >per > - extract the .DLL files (AccessControl.dll) and copy it to the > NSIS plugins directory usually > C:\Program Files\NSIS\Plugins\x86-ansi > > > if build server still required and mitigations exist for installing nsis > and dependencies on cloud build agents, i offer to > >- evaluate the full build process for the windows geoserver >- deliver a proof of concept of a suitable pipeline that runs in azure >devops > > > please advice > ___ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] windows build server
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 this, please contact the developer list) if this is no longer true please disregard if build server still required * i happen to know that as an open source project the geoserver project can run unlimited builds in azure devops. so can anyone else who clones the repo in a public azure devops project * after investigating the geoserver github actions i saw nothing incompatible with triggering builds in azure devops in collaboration with specific github actions * the primary showstopper risk seems to revolve around headless installation of nsis itself and its dependencies on azure build servers as per * extract the .DLL files (AccessControl.dll) and copy it to the NSIS plugins directory usually C:\Program Files\NSIS\Plugins\x86-ansi if build server still required and mitigations exist for installing nsis and dependencies on cloud build agents, i offer to * evaluate the full build process for the windows geoserver * deliver a proof of concept of a suitable pipeline that runs in azure devops please advice ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Windows build server notifications off
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 -- == Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit http://goo.gl/WHKDXT for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Windows build server, almost there
+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://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 0584 1660272 mob: +39 333 8128928 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. On Fri, Apr 24, 2015 at 8:26 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: 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-Master/org.geoserver$gs-main/1422/testReport/junit/org.geoserver.security.xml/XMLRoleServiceTest/testInsert/ ) b) a rare failure that makes EPSG:4326 impossible to decode, with no information on how to debug it (no errors in the HSQL setup), and no way to reproduce it a) happens every 10-20 builds, b) seems to happen every 20-50 builds I was thinking to make the build server start sending hate mails in case of build failures once we fix a), given than b) seems to be un-crackable and relatively rare. What do you think? Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except
Re: [Geoserver-devel] Windows build server, almost there
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 during a test run several LockFile instances are getting created, and eventually garbage collected... when that happens, finalize() is called, which deletes the file, on a Windows server, if the deletion happens while another LockFile instance tries to write the file, we are bound to see the error in question... and this would also explain the intermittence of the error, it's driven by GC cycles. Can the code be modified to avoid this randomness? I'd think LockFile should be treated as a resource like datastore and friends, and closed explicitly once not used anymore. Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Windows build server, almost there
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. Any idea where to call releaseLock to avoid this problem. Not yet, I'm not familiar with that portion of the code and how the lifecycle of its objects is managed... I was hoping you would suggest the right place. Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Windows build server, almost there
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, Andrea Aime andrea.a...@geo-solutions.it wrote: 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 during a test run several LockFile instances are getting created, and eventually garbage collected... when that happens, finalize() is called, which deletes the file, on a Windows server, if the deletion happens while another LockFile instance tries to write the file, we are bound to see the error in question... and this would also explain the intermittence of the error, it's driven by GC cycles. Can the code be modified to avoid this randomness? I'd think LockFile should be treated as a resource like datastore and friends, and closed explicitly once not used anymore. Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- DI Christian Mueller MSc (GIS), MSc (IT-Security) OSS Open Source Solutions GmbH -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Windows build server, almost there
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 andrea.a...@geo-solutions.it wrote: On Mon, Apr 27, 2015 at 3:16 PM, Andrea Aime andrea.a...@geo-solutions.it 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.geoserver.security.file.LockFile.finalize() is a safeguard. Any idea where to call releaseLock to avoid this problem. Not yet, I'm not familiar with that portion of the code and how the lifecycle of its objects is managed... I was hoping you would suggest the right place. Wondering, as an alternative... should we just remove the finalize as a quick fix? Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- DI Christian Mueller MSc (GIS), MSc (IT-Security) OSS Open Source Solutions GmbH -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Windows build server, almost there
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-Master/org.geoserver$gs-main/1422/testReport/junit/org.geoserver.security.xml/XMLRoleServiceTest/testInsert/ ) b) a rare failure that makes EPSG:4326 impossible to decode, with no information on how to debug it (no errors in the HSQL setup), and no way to reproduce it a) happens every 10-20 builds, b) seems to happen every 20-50 builds I was thinking to make the build server start sending hate mails in case of build failures once we fix a), given than b) seems to be un-crackable and relatively rare. What do you think? Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Windows build server, almost there
+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 0584 1660272 mob: +39 333 8128928 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. On Fri, Apr 24, 2015 at 8:26 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: 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-Master/org.geoserver$gs-main/1422/testReport/junit/org.geoserver.security.xml/XMLRoleServiceTest/testInsert/) b) a rare failure that makes EPSG:4326 impossible to decode, with no information on how to debug it (no errors in the HSQL setup), and no way to reproduce it a) happens every 10-20 builds, b) seems to happen every 20-50 builds I was thinking to make the build server start sending hate mails in case of build failures once we fix a), given than b) seems to be un-crackable and relatively rare. What do you think? Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content,
Re: [Geoserver-devel] windows build server failures on master
Thanks for the discussion Olle, the fix has been merged. -- Jody Garnett On 3 February 2015 at 14:45, Olle Markljung marklj...@gmail.com 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 platforms. On Windows file://images/poi.png will be converted into \\images\poi.png. An absolute path to the host images. On other platforms the same url will be converted into images/poi.png. A relative path. So, by running existing code and se if we find a file at that location the backwards compatibility will not be broken. And by assuming relative path if no file exist you get the same result as for other platforms. Since the Paths.VALID does not allow for backslashes backslash (sorry windows users we are following linux conventions here) conversion code is needed when converting URLs to resource in GeoServerDataDirectory.java. If I add that the build is successful with mvn clean install. I'll try to formulate a suiting JIRA and send a PR for the change. /Olle On Tue, Feb 3, 2015 at 2:26 AM, Jody Garnett jody.garn...@gmail.com wrote: 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). Correct me if I am wrong, and absolute path on windows will end up using the C:\ notation or the \\host\share\ notation - in both cases these are pretty specific and not confusable as a relative path? -- Jody Garnett On 2 February 2015 at 14:52, Olle Markljung marklj...@gmail.com wrote: 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 result that you get on other platforms. But yes, if your intention is to use an absolute path to something that does not exist yet it will fail. So, by swapping the order you would get the absoulte file path as the default on windows as before for files that do not exist yet. But if there is a file there for the relative case that will be used instead. However that seems a bit unlikely. Should I update the PR to do that? Still not sure how the Java Path API would help here. /Olle On Sun, Feb 1, 2015 at 11:26 PM, Jody Garnett jody.garn...@gmail.com wrote: 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, Olle Markljung marklj...@gmail.com wrote: 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 Jody. If I have gotten this right the problem is to know if the user provide an absolute or relative path. How would the path API help in knowing the intentions of the user? /Olle On Wed, Jan 21, 2015 at 12:33 AM, Jody Garnett jody.garn...@gmail.com wrote: 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, Olle Markljung marklj...@gmail.com wrote: 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. That is to check if the file exists. If it doesn't we remove the extra slashes and makes the URI relative. I extended the tests and added such code to the Windows specific case and it works as expected. Should I create a ticket and send a PR with these changes for your review? /Olle On Mon, Jan 19, 2015 at 11:42 PM, Olle Markljung marklj...@gmail.com wrote: 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 // by urlToFile and this means it's not relative. You'll get the same behavior
Re: [Geoserver-devel] windows build server failures on master
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 result that you get on other platforms. But yes, if your intention is to use an absolute path to something that does not exist yet it will fail. So, by swapping the order you would get the absoulte file path as the default on windows as before for files that do not exist yet. But if there is a file there for the relative case that will be used instead. However that seems a bit unlikely. Should I update the PR to do that? Still not sure how the Java Path API would help here. /Olle On Sun, Feb 1, 2015 at 11:26 PM, Jody Garnett jody.garn...@gmail.com wrote: 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, Olle Markljung marklj...@gmail.com wrote: 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 Jody. If I have gotten this right the problem is to know if the user provide an absolute or relative path. How would the path API help in knowing the intentions of the user? /Olle On Wed, Jan 21, 2015 at 12:33 AM, Jody Garnett jody.garn...@gmail.com wrote: 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, Olle Markljung marklj...@gmail.com wrote: 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. That is to check if the file exists. If it doesn't we remove the extra slashes and makes the URI relative. I extended the tests and added such code to the Windows specific case and it works as expected. Should I create a ticket and send a PR with these changes for your review? /Olle On Mon, Jan 19, 2015 at 11:42 PM, Olle Markljung marklj...@gmail.com wrote: 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 // by urlToFile and this means it's not relative. You'll get the same behavior if you use file:/ instead. Therefore locateResource will leave the URI as is and not make it relative to the styles folder. So, on Windows the urls will be interpreted as absolute but on other platforms it will be relative. Atleast the file:// case. Should file://host/share/dest.png be supported on Windows but not elsewhere? Would \\host\share\dest.png work an be a acceptable replacement? Is it intentional that file:/ will be an absolute path and file:// not? Something that does work is removing the forward slashes. So, file:dest.png will give you the correct behavior. As https://jira.codehaus.org/browse/GEOT-4311 says. I'm merely trying to understand the requirements so go easy on me :) /Olle On Mon, Jan 19, 2015 at 9:40 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com 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 get back to you with some exemples and maybe we can document the requirements and expected behavior. The test is checking for behavior that was working up to 2.5.x. Both worked: file://dest.png file.//./dest.png Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in
Re: [Geoserver-devel] windows build server failures on master
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). Correct me if I am wrong, and absolute path on windows will end up using the C:\ notation or the \\host\share\ notation - in both cases these are pretty specific and not confusable as a relative path? -- Jody Garnett On 2 February 2015 at 14:52, Olle Markljung marklj...@gmail.com wrote: 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 result that you get on other platforms. But yes, if your intention is to use an absolute path to something that does not exist yet it will fail. So, by swapping the order you would get the absoulte file path as the default on windows as before for files that do not exist yet. But if there is a file there for the relative case that will be used instead. However that seems a bit unlikely. Should I update the PR to do that? Still not sure how the Java Path API would help here. /Olle On Sun, Feb 1, 2015 at 11:26 PM, Jody Garnett jody.garn...@gmail.com wrote: 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, Olle Markljung marklj...@gmail.com wrote: 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 Jody. If I have gotten this right the problem is to know if the user provide an absolute or relative path. How would the path API help in knowing the intentions of the user? /Olle On Wed, Jan 21, 2015 at 12:33 AM, Jody Garnett jody.garn...@gmail.com wrote: 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, Olle Markljung marklj...@gmail.com wrote: 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. That is to check if the file exists. If it doesn't we remove the extra slashes and makes the URI relative. I extended the tests and added such code to the Windows specific case and it works as expected. Should I create a ticket and send a PR with these changes for your review? /Olle On Mon, Jan 19, 2015 at 11:42 PM, Olle Markljung marklj...@gmail.com wrote: 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 // by urlToFile and this means it's not relative. You'll get the same behavior if you use file:/ instead. Therefore locateResource will leave the URI as is and not make it relative to the styles folder. So, on Windows the urls will be interpreted as absolute but on other platforms it will be relative. Atleast the file:// case. Should file://host/share/dest.png be supported on Windows but not elsewhere? Would \\host\share\dest.png work an be a acceptable replacement? Is it intentional that file:/ will be an absolute path and file:// not? Something that does work is removing the forward slashes. So, file:dest.png will give you the correct behavior. As https://jira.codehaus.org/browse/GEOT-4311 says. I'm merely trying to understand the requirements so go easy on me :) /Olle On Mon, Jan 19, 2015 at 9:40 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com 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 get back to you with some exemples and maybe we can document the
Re: [Geoserver-devel] windows build server failures on master
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 Jody. If I have gotten this right the problem is to know if the user provide an absolute or relative path. How would the path API help in knowing the intentions of the user? /Olle On Wed, Jan 21, 2015 at 12:33 AM, Jody Garnett jody.garn...@gmail.com wrote: 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, Olle Markljung marklj...@gmail.com wrote: 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. That is to check if the file exists. If it doesn't we remove the extra slashes and makes the URI relative. I extended the tests and added such code to the Windows specific case and it works as expected. Should I create a ticket and send a PR with these changes for your review? /Olle On Mon, Jan 19, 2015 at 11:42 PM, Olle Markljung marklj...@gmail.com wrote: 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 // by urlToFile and this means it's not relative. You'll get the same behavior if you use file:/ instead. Therefore locateResource will leave the URI as is and not make it relative to the styles folder. So, on Windows the urls will be interpreted as absolute but on other platforms it will be relative. Atleast the file:// case. Should file://host/share/dest.png be supported on Windows but not elsewhere? Would \\host\share\dest.png work an be a acceptable replacement? Is it intentional that file:/ will be an absolute path and file:// not? Something that does work is removing the forward slashes. So, file:dest.png will give you the correct behavior. As https://jira.codehaus.org/browse/GEOT-4311 says. I'm merely trying to understand the requirements so go easy on me :) /Olle On Mon, Jan 19, 2015 at 9:40 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com 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 get back to you with some exemples and maybe we can document the requirements and expected behavior. The test is checking for behavior that was working up to 2.5.x. Both worked: file://dest.png file.//./dest.png Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the
Re: [Geoserver-devel] windows build server failures on master
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, Olle Markljung marklj...@gmail.com wrote: 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 Jody. If I have gotten this right the problem is to know if the user provide an absolute or relative path. How would the path API help in knowing the intentions of the user? /Olle On Wed, Jan 21, 2015 at 12:33 AM, Jody Garnett jody.garn...@gmail.com wrote: 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, Olle Markljung marklj...@gmail.com wrote: 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. That is to check if the file exists. If it doesn't we remove the extra slashes and makes the URI relative. I extended the tests and added such code to the Windows specific case and it works as expected. Should I create a ticket and send a PR with these changes for your review? /Olle On Mon, Jan 19, 2015 at 11:42 PM, Olle Markljung marklj...@gmail.com wrote: 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 // by urlToFile and this means it's not relative. You'll get the same behavior if you use file:/ instead. Therefore locateResource will leave the URI as is and not make it relative to the styles folder. So, on Windows the urls will be interpreted as absolute but on other platforms it will be relative. Atleast the file:// case. Should file://host/share/dest.png be supported on Windows but not elsewhere? Would \\host\share\dest.png work an be a acceptable replacement? Is it intentional that file:/ will be an absolute path and file:// not? Something that does work is removing the forward slashes. So, file:dest.png will give you the correct behavior. As https://jira.codehaus.org/browse/GEOT-4311 says. I'm merely trying to understand the requirements so go easy on me :) /Olle On Mon, Jan 19, 2015 at 9:40 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com 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 get back to you with some exemples and maybe we can document the requirements and expected behavior. The test is checking for behavior that was working up to 2.5.x. Both worked: file://dest.png file.//./dest.png Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the
Re: [Geoserver-devel] windows build server failures on master
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, Olle Markljung marklj...@gmail.com wrote: 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. That is to check if the file exists. If it doesn't we remove the extra slashes and makes the URI relative. I extended the tests and added such code to the Windows specific case and it works as expected. Should I create a ticket and send a PR with these changes for your review? /Olle On Mon, Jan 19, 2015 at 11:42 PM, Olle Markljung marklj...@gmail.com wrote: 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 // by urlToFile and this means it's not relative. You'll get the same behavior if you use file:/ instead. Therefore locateResource will leave the URI as is and not make it relative to the styles folder. So, on Windows the urls will be interpreted as absolute but on other platforms it will be relative. Atleast the file:// case. Should file://host/share/dest.png be supported on Windows but not elsewhere? Would \\host\share\dest.png work an be a acceptable replacement? Is it intentional that file:/ will be an absolute path and file:// not? Something that does work is removing the forward slashes. So, file:dest.png will give you the correct behavior. As https://jira.codehaus.org/browse/GEOT-4311 says. I'm merely trying to understand the requirements so go easy on me :) /Olle On Mon, Jan 19, 2015 at 9:40 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com 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 get back to you with some exemples and maybe we can document the requirements and expected behavior. The test is checking for behavior that was working up to 2.5.x. Both worked: file://dest.png file.//./dest.png Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- --
Re: [Geoserver-devel] windows build server failures on master
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. That is to check if the file exists. If it doesn't we remove the extra slashes and makes the URI relative. I extended the tests and added such code to the Windows specific case and it works as expected. Should I create a ticket and send a PR with these changes for your review? /Olle On Mon, Jan 19, 2015 at 11:42 PM, Olle Markljung marklj...@gmail.com wrote: 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 // by urlToFile and this means it's not relative. You'll get the same behavior if you use file:/ instead. Therefore locateResource will leave the URI as is and not make it relative to the styles folder. So, on Windows the urls will be interpreted as absolute but on other platforms it will be relative. Atleast the file:// case. Should file://host/share/dest.png be supported on Windows but not elsewhere? Would \\host\share\dest.png work an be a acceptable replacement? Is it intentional that file:/ will be an absolute path and file:// not? Something that does work is removing the forward slashes. So, file:dest.png will give you the correct behavior. As https://jira.codehaus.org/browse/GEOT-4311 says. I'm merely trying to understand the requirements so go easy on me :) /Olle On Mon, Jan 19, 2015 at 9:40 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com 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 get back to you with some exemples and maybe we can document the requirements and expected behavior. The test is checking for behavior that was working up to 2.5.x. Both worked: file://dest.png file.//./dest.png Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant.
Re: [Geoserver-devel] windows build server failures on master
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 // by urlToFile and this means it's not relative. You'll get the same behavior if you use file:/ instead. Therefore locateResource will leave the URI as is and not make it relative to the styles folder. So, on Windows the urls will be interpreted as absolute but on other platforms it will be relative. Atleast the file:// case. Should file://host/share/dest.png be supported on Windows but not elsewhere? Would \\host\share\dest.png work an be a acceptable replacement? Is it intentional that file:/ will be an absolute path and file:// not? Something that does work is removing the forward slashes. So, file:dest.png will give you the correct behavior. As https://jira.codehaus.org/browse/GEOT-4311 says. I'm merely trying to understand the requirements so go easy on me :) /Olle On Mon, Jan 19, 2015 at 9:40 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com 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 get back to you with some exemples and maybe we can document the requirements and expected behavior. The test is checking for behavior that was working up to 2.5.x. Both worked: file://dest.png file.//./dest.png Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server failures on master
On Mon, Jan 19, 2015 at 9:29 AM, Olle Markljung marklj...@gmail.com 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 get back to you with some exemples and maybe we can document the requirements and expected behavior. The test is checking for behavior that was working up to 2.5.x. Both worked: file://dest.png file.//./dest.png Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server failures on master
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 requirements and expected behavior. /Olle måndag 19 januari 2015 skrev Andrea Aime andrea.a...@geo-solutions.it: On Mon, Jan 19, 2015 at 12:58 AM, Olle Markljung marklj...@gmail.com javascript:_e(%7B%7D,'cvml','marklj...@gmail.com'); 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 cannot use the file protocol with relative paths. So, perhaps this case shouldn't be supported and the test should fail. This approach has been working for years, people depend on it, so we are definitely not going to stop supporting it. You'll find that any suggestion intentionally breaking backwards compatibility will get a solid and immediate -1 around here ;-) Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server failures on master
Ok!
I'll look into it.
/Olle
måndag 19 januari 2015 skrev Jody Garnett jody.garn...@gmail.com:
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 static File urlToFile(URL url) {
if (!file.equals(url.getProtocol())) {
return null; // not a File URL
}
String string = url.toExternalForm();
if (string.contains(+)) {
// this represents an invalid URL created using either
// file.toURL(); or
// file.toURI().toURL() on a specific version of Java 5 on Mac
string = string.replace(+, %2B);
}
try {
string = URLDecoder.decode(string, UTF-8);
} catch (UnsupportedEncodingException e) {
throw new RuntimeException(Could not decode the URL to UTF-8
format, e);
}
String path3;
String simplePrefix = file:/;
String standardPrefix = file://;
if (IS_WINDOWS_OS string.startsWith(standardPrefix)) {
// win32: host/share reference
path3 = string.substring(standardPrefix.length() - 2);
} else if (string.startsWith(standardPrefix)) {
path3 = string.substring(standardPrefix.length());
} else if (string.startsWith(simplePrefix)) {
path3 = string.substring(simplePrefix.length() - 1);
} else {
String auth = url.getAuthority();
String path2 = url.getPath().replace(%20, );
if (auth != null !auth.equals()) {
path3 = // + auth + path2;
} else {
path3 = path2;
}
}
return new File(path3);
}
As you can see we have one windows specific control path which we are not
testing anywhere else! I think I may refactor this code to *just* be string
based and take that windows flag as a parameter so we can test this on all
platforms ...
Note these methods were introduced when Java was doing a terrible job of
File to/from URL conversion. They have correcting things a bit with
file.toURI().toURL() ...
If you could grab the geotools codebase and set up a test case that passes
in the same strings that are failing in GeoServer it would be a great
help...
--
Jody
--
Jody Garnett
On 18 January 2015 at 15:58, Olle Markljung marklj...@gmail.com
javascript:_e(%7B%7D,'cvml','marklj...@gmail.com'); wrote:
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
\\images\rockFillSymbol.png
SLD attribute
./images/rockFillSymbol.png
Linkage
file:/C:/GitHub/geoserver/src/main/./target/default3970162196491181932data/styles/images/rockFillSymbol.png
Converted to
C:\GitHub\geoserver\src\main\target\default896598906399223139data\styles\images\rockFillSymbol.png
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 cannot use the file protocol with relative paths.
So, perhaps this case shouldn't be supported and the test should fail.
/Olle
On Sun, Jan 18, 2015 at 9:05 PM, Jody Garnett jody.garn...@gmail.com
javascript:_e(%7B%7D,'cvml','jody.garn...@gmail.com'); wrote:
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
andrea.a...@geo-solutions.it
javascript:_e(%7B%7D,'cvml','andrea.a...@geo-solutions.it'); wrote:
On Sun, Jan 18, 2015 at 8:06 PM, Jody Garnett jody.garn...@gmail.com
javascript:_e(%7B%7D,'cvml','jody.garn...@gmail.com'); 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.
I was able to restore the build for geotools-devel, but it looks like
we have some failures for the geoserver master build target.
Failed tests:
testSEStyleWithRelativePathProtocol(org.geoserver.catalog.ResourcePoolTest):
expected:C:\.jenkins\jobs\GeoServer-Master\workspace\src\main\target\default4702095627624841408data\styles\images\rockFillSymbol.png
but was:\\images\rockFillSymbol.png
A general call out on this one, I would like to ensure we build
cleanly on windows (and take advantage of this machine that has been
provided).
Hi Jody,
the GeoServer windows build server has never been
Re: [Geoserver-devel] windows build server failures on master
On Mon, Jan 19, 2015 at 12:58 AM, Olle Markljung marklj...@gmail.com 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 cannot use the file protocol with relative paths. So, perhaps this case shouldn't be supported and the test should fail. This approach has been working for years, people depend on it, so we are definitely not going to stop supporting it. You'll find that any suggestion intentionally breaking backwards compatibility will get a solid and immediate -1 around here ;-) Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server failures on master
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 static File urlToFile(URL url) {
if (!file.equals(url.getProtocol())) {
return null; // not a File URL
}
String string = url.toExternalForm();
if (string.contains(+)) {
// this represents an invalid URL created using either
// file.toURL(); or
// file.toURI().toURL() on a specific version of Java 5 on Mac
string = string.replace(+, %2B);
}
try {
string = URLDecoder.decode(string, UTF-8);
} catch (UnsupportedEncodingException e) {
throw new RuntimeException(Could not decode the URL to UTF-8
format, e);
}
String path3;
String simplePrefix = file:/;
String standardPrefix = file://;
if (IS_WINDOWS_OS string.startsWith(standardPrefix)) {
// win32: host/share reference
path3 = string.substring(standardPrefix.length() - 2);
} else if (string.startsWith(standardPrefix)) {
path3 = string.substring(standardPrefix.length());
} else if (string.startsWith(simplePrefix)) {
path3 = string.substring(simplePrefix.length() - 1);
} else {
String auth = url.getAuthority();
String path2 = url.getPath().replace(%20, );
if (auth != null !auth.equals()) {
path3 = // + auth + path2;
} else {
path3 = path2;
}
}
return new File(path3);
}
As you can see we have one windows specific control path which we are not
testing anywhere else! I think I may refactor this code to *just* be string
based and take that windows flag as a parameter so we can test this on all
platforms ...
Note these methods were introduced when Java was doing a terrible job of
File to/from URL conversion. They have correcting things a bit with
file.toURI().toURL() ...
If you could grab the geotools codebase and set up a test case that passes
in the same strings that are failing in GeoServer it would be a great
help...
--
Jody
--
Jody Garnett
On 18 January 2015 at 15:58, Olle Markljung marklj...@gmail.com wrote:
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
\\images\rockFillSymbol.png
SLD attribute
./images/rockFillSymbol.png
Linkage
file:/C:/GitHub/geoserver/src/main/./target/default3970162196491181932data/styles/images/rockFillSymbol.png
Converted to
C:\GitHub\geoserver\src\main\target\default896598906399223139data\styles\images\rockFillSymbol.png
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 cannot use the file protocol with relative paths.
So, perhaps this case shouldn't be supported and the test should fail.
/Olle
On Sun, Jan 18, 2015 at 9:05 PM, Jody Garnett jody.garn...@gmail.com
wrote:
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
andrea.a...@geo-solutions.it wrote:
On Sun, Jan 18, 2015 at 8:06 PM, Jody Garnett jody.garn...@gmail.com
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.
I was able to restore the build for geotools-devel, but it looks like
we have some failures for the geoserver master build target.
Failed tests:
testSEStyleWithRelativePathProtocol(org.geoserver.catalog.ResourcePoolTest):
expected:C:\.jenkins\jobs\GeoServer-Master\workspace\src\main\target\default4702095627624841408data\styles\images\rockFillSymbol.png
but was:\\images\rockFillSymbol.png
A general call out on this one, I would like to ensure we build cleanly
on windows (and take advantage of this machine that has been provided).
Hi Jody,
the GeoServer windows build server has never been made official because
I did not manage to get the build working on Windows in a stable way
(and got no help doing so either).
I have a windows laptop now that I can use to do some bits on Windows,
but
honestly I despise the platform, so it's more call of duty than
something I want
to do in my spare time, it would need some champion that really
pushes for it.
Last time I
[Geoserver-devel] windows build server failures on master
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 like we have some failures for the geoserver master build target. Failed tests: testSEStyleWithRelativePathProtocol(org.geoserver.catalog.ResourcePoolTest): expected:C:\.jenkins\jobs\GeoServer-Master\workspace\src\main\target\default4702095627624841408data\styles\images\rockFillSymbol.png but was:\\images\rockFillSymbol.png A general call out on this one, I would like to ensure we build cleanly on windows (and take advantage of this machine that has been provided). -- Jody Garnett -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server failures on master
On Sun, Jan 18, 2015 at 8:06 PM, Jody Garnett jody.garn...@gmail.com 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. I was able to restore the build for geotools-devel, but it looks like we have some failures for the geoserver master build target. Failed tests: testSEStyleWithRelativePathProtocol(org.geoserver.catalog.ResourcePoolTest): expected:C:\.jenkins\jobs\GeoServer-Master\workspace\src\main\target\default4702095627624841408data\styles\images\rockFillSymbol.png but was:\\images\rockFillSymbol.png A general call out on this one, I would like to ensure we build cleanly on windows (and take advantage of this machine that has been provided). Hi Jody, the GeoServer windows build server has never been made official because I did not manage to get the build working on Windows in a stable way (and got no help doing so either). I have a windows laptop now that I can use to do some bits on Windows, but honestly I despise the platform, so it's more call of duty than something I want to do in my spare time, it would need some champion that really pushes for it. Last time I checked there were some random failures in the WCS modules, failure to delete some files in the temp data dirs, I guess we are still keeping some reader/file handle open, but could not locate where. I guess it got worse from there. Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] windows build server failures on master
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 \\images\rockFillSymbol.png SLD attribute ./images/rockFillSymbol.png Linkage file:/C:/GitHub/geoserver/src/main/./target/default3970162196491181932data/styles/images/rockFillSymbol.png Converted to C:\GitHub\geoserver\src\main\target\default896598906399223139data\styles\images\rockFillSymbol.png 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 cannot use the file protocol with relative paths. So, perhaps this case shouldn't be supported and the test should fail. /Olle On Sun, Jan 18, 2015 at 9:05 PM, Jody Garnett jody.garn...@gmail.com wrote: 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 andrea.a...@geo-solutions.it wrote: On Sun, Jan 18, 2015 at 8:06 PM, Jody Garnett jody.garn...@gmail.com 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. I was able to restore the build for geotools-devel, but it looks like we have some failures for the geoserver master build target. Failed tests: testSEStyleWithRelativePathProtocol(org.geoserver.catalog.ResourcePoolTest): expected:C:\.jenkins\jobs\GeoServer-Master\workspace\src\main\target\default4702095627624841408data\styles\images\rockFillSymbol.png but was:\\images\rockFillSymbol.png A general call out on this one, I would like to ensure we build cleanly on windows (and take advantage of this machine that has been provided). Hi Jody, the GeoServer windows build server has never been made official because I did not manage to get the build working on Windows in a stable way (and got no help doing so either). I have a windows laptop now that I can use to do some bits on Windows, but honestly I despise the platform, so it's more call of duty than something I want to do in my spare time, it would need some champion that really pushes for it. Last time I checked there were some random failures in the WCS modules, failure to delete some files in the temp data dirs, I guess we are still keeping some reader/file handle open, but could not locate where. I guess it got worse from there. Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. ---
Re: [Geoserver-devel] windows build server failures on master
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 andrea.a...@geo-solutions.it wrote: On Sun, Jan 18, 2015 at 8:06 PM, Jody Garnett jody.garn...@gmail.com 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. I was able to restore the build for geotools-devel, but it looks like we have some failures for the geoserver master build target. Failed tests: testSEStyleWithRelativePathProtocol(org.geoserver.catalog.ResourcePoolTest): expected:C:\.jenkins\jobs\GeoServer-Master\workspace\src\main\target\default4702095627624841408data\styles\images\rockFillSymbol.png but was:\\images\rockFillSymbol.png A general call out on this one, I would like to ensure we build cleanly on windows (and take advantage of this machine that has been provided). Hi Jody, the GeoServer windows build server has never been made official because I did not manage to get the build working on Windows in a stable way (and got no help doing so either). I have a windows laptop now that I can use to do some bits on Windows, but honestly I despise the platform, so it's more call of duty than something I want to do in my spare time, it would need some champion that really pushes for it. Last time I checked there were some random failures in the WCS modules, failure to delete some files in the temp data dirs, I guess we are still keeping some reader/file handle open, but could not locate where. I guess it got worse from there. Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Windows Build Server (almost) ready
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 here: http://winbuild.geo-solutions.it/jenkins/ The uid and pwd are the same one as the opengeo hudson server. So if you have them you can play with this server as well. I have not instructed the builds to send emails I will do that once I will be sure the failures are consistent. Regards, Simone Giannecchini == Our support, Your Success! Visit http://opensdi.geo-solutions.it 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 0584 1660272 mob: +39 333 8128928 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Windows build server ready
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 build is now fine, the GeoTools one is not but the main build server is reporting the same problem (process name refactoring caused a failure in the documentation module). About making them work: geotools was relatively easy, just shapefile-ng was not building properly, GeoServer required a lot of changes in tests to avoid having the code keeping a finger on some files that were impossible to delete under the teardown phase (and a few changes in the actual code too to make sure GridCoverage objects are getting disposed of). These changes have been committed on master only, I guess I can backport them if/when we also do the backport of the fast test proposal (in GeoServer land at least, GeoTools wise things are easier). As we previously discussed we should setup some new mailing list for these extra builds. How about two new google groups, geotools-builds and geoserver-builds? Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
