Hi,
the other pull requests that leaves me some doubt is this one, about updating the README file
with recent instructions for developers:
https://github.com/geoserver/geoserver/pull/32/files
The Linux instructions suggest to install “default-jdk”, which on modern distributions will
result in OpenJDK7 being installed.
Now, we do have the OpenJDK build server (whose build is still quite unstable due to
the test method run order being almost randomized on that JDK)… but it’s not a officially
supported JDK for the builds.
So, what should we tell people?
Provide instructions on how to setup Oracle JDK on Linux, or just warn them that OpenJDK
“sort of works” on trunk but it’s not really supported?
Cheers
Andrea
–
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
On Sun, Nov 25, 2012 at 9:51 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
Hi,
the other pull requests that leaves me some doubt is this one, about
updating the README file
with recent instructions for developers:
https://github.com/geoserver/geoserver/pull/32/files
The Linux instructions suggest to install "default-jdk", which on modern
distributions will
result in OpenJDK7 being installed.
Now, we do have the OpenJDK build server (whose build is still quite
unstable due to
the test method run order being almost randomized on that JDK)... but it's
not a officially
supported JDK for the builds.
So, what should we tell people?
Provide instructions on how to setup Oracle JDK on Linux, or just warn
them that OpenJDK
"sort of works" on trunk but it's not really supported?
Yeah, I would say in the linux section we should specify the truly
supported method is to install the oracle jdk. But that default-jdk /
openjdk is still a work in progress on master.
Cheers
Andrea
--
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
-------------------------------------------------------
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Dont know if this helps, but the new junit 4.11 version offers the possibility to control the execution order of tests.
http://www.hascode.com/2012/11/new-features-in-junit-4-11/#Test_Execution_Order
2012/11/25 Justin Deoliveira <jdeolive@anonymised.com.1501…>
···
On Sun, Nov 25, 2012 at 9:51 AM, Andrea Aime <andrea.aime@anonymised.com.1268…> wrote:
Hi,
the other pull requests that leaves me some doubt is this one, about updating the README file
with recent instructions for developers:
https://github.com/geoserver/geoserver/pull/32/files
The Linux instructions suggest to install “default-jdk”, which on modern distributions will
result in OpenJDK7 being installed.
Now, we do have the OpenJDK build server (whose build is still quite unstable due to
the test method run order being almost randomized on that JDK)… but it’s not a officially
supported JDK for the builds.
So, what should we tell people?
Provide instructions on how to setup Oracle JDK on Linux, or just warn them that OpenJDK
“sort of works” on trunk but it’s not really supported?
Yeah, I would say in the linux section we should specify the truly supported method is to install the oracle jdk. But that default-jdk / openjdk is still a work in progress on master.
Cheers
Andrea
–
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
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Tue, Nov 27, 2012 at 10:46 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
Dont know if this helps, but the new junit 4.11 version offers the possibility to control the execution order of tests.
http://www.hascode.com/2012/11/new-features-in-junit-4-11/#Test_Execution_Order
I’m very tempted, at the same time this natural tendency to randomize execution order
makes for better tests to be written in the long run.
The lingering question is, do we want to spend time hardening our tests?
(and more importantly, do we have such time?)
Cheers
Andrea
–
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
On Tue, Nov 27, 2012 at 3:50 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
On Tue, Nov 27, 2012 at 10:46 AM, Christian Mueller <mcrmcr21@anonymised.com>wrote:
Dont know if this helps, but the new junit 4.11 version offers the
possibility to control the execution order of tests.
http://www.hascode.com/2012/11/new-features-in-junit-4-11/#Test_Execution_Order
I'm very tempted, at the same time this natural tendency to randomize
execution order
makes for better tests to be written in the long run.
The lingering question is, do we want to spend time hardening our tests?
(and more importantly, do we have such time?)
Good question 
Ideally we wouldn't assume any ordering for the reasons
you state. But if the effort is so that it won't be feasible to harden the
tests then i am not against this if it means a stable build on openjdk.
Sorry if you covered this already but do we have a good idea of the
problematic test cases?
Cheers
Andrea
--
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
-------------------------------------------------------
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
They tend to popup semi-randomly, and normally are related to tests not getting state changes
rolled back.
Basically what I believe most people did during the test update sprint was to fix was we saw was broken, as
opposed to go method by method and see if there was anything to roll back.
Which means we have changes that are not rolled back, but are not harmful in the usual Java 6 execution
order.
Cheers
Andrea
···
Good question Ideally we wouldn’t assume any ordering for the reasons you state. But if the effort is so that it won’t be feasible to harden the tests then i am not against this if it means a stable build on openjdk.
Sorry if you covered this already but do we have a good idea of the problematic test cases?
Right makes sense. Well if enough people are interested we could start tackling the modules one by one like we did for the code sprint. THis might be a problem for me since i am on osx and afaik the only openjdk build available is openjdk 7.
···
On Tue, Nov 27, 2012 at 8:17 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Tue, Nov 27, 2012 at 2:31 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
They tend to popup semi-randomly, and normally are related to tests not getting state changes
rolled back.
Basically what I believe most people did during the test update sprint was to fix was we saw was broken, as
opposed to go method by method and see if there was anything to roll back.
Which means we have changes that are not rolled back, but are not harmful in the usual Java 6 execution
order.
Cheers
Andrea
–
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
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Good question Ideally we wouldn’t assume any ordering for the reasons you state. But if the effort is so that it won’t be feasible to harden the tests then i am not against this if it means a stable build on openjdk.
Sorry if you covered this already but do we have a good idea of the problematic test cases?
On Wed, Nov 28, 2012 at 5:07 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Right makes sense. Well if enough people are interested we could start tackling the modules one by one like we did for the code sprint. THis might be a problem for me since i am on osx and afaik the only openjdk build available is openjdk 7.
Ah, the randomized test order happens exactly on OpenJDK 7.
Another possible approach would be that we just have a look at the build server failures, and from time
to time look into one and fix it… eventually we’ll reduce them to zero without having to
put hart and soul on a project wide search?
Cheers
Andrea
–
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