After quite a good long run of being able to keep geotools and geoserver tunks compiling and in sync, suddenly a whole bunch of things seem to have gone pear-shaped...
is anyone else having build problems at the moment?
Some issues reported to me - someone with a clean machine trying to build geoserver trunk, and some myself with state of geoserver trunk.
The reported issue was missing org.geotools.util.Version, af it appeared that the gt2-main-SNAPSHOT.jar in the refractions repository was not up to date.
for me,
geoserver trunk wms module currently fails to compile, using mvn -U clean install:
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
c:\src\geoserver\trunk\geoserver\wms\src\main\java\org\vfny\geoserver\wms\respon
ses\map\kml\KMLGeometryTransformer.java:[23,50] numDecimals has private access i
n org.geotools.gml.producer.GeometryTransformer
c:\src\geoserver\trunk\geoserver\wms\src\main\java\org\vfny\geoserver\wms\respon
ses\map\kml\KMLGeometryTransformer.java:[23,63] useDummyZ has private access in
org.geotools.gml.producer.GeometryTransformer
wfsv also fails:
Downloading: http://lists.refractions.net/m2//org/geoserver/net.opengis.wfsv/1.6
-SNAPSHOT/net.opengis.wfsv-1.6-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
is anyone else having build problems at the moment?
It work fine for me (Linux, Java 1.4, Maven 2.0.6). Just tried a fresh "mvn
clean", "mvn install" with revision 25647.
Some issues reported to me - someone with a clean machine trying to
build geoserver trunk, and some myself with state of geoserver trunk.
I have build Geoserver trunk last week with success (revision 6590). But I do
not relies on the JAR deployed on Maven. I build Geotools first (so latest
Geotools JAR are installed in my local Maven repository), then Geoserver.
Maybe we just need a volunter for deploying Geotools 2.4-SNAPSHOT jars on the
Refractions repository? It should just be a matter of running "mvn deploy" on
Geotools trunk - nothing else to do on a properly configured system. I can do
that, but do we have a policy on the frequency of 2.4-SNAPSHOT deployment, and
about who should do them?
is anyone else having build problems at the moment?
It work fine for me (Linux, Java 1.4, Maven 2.0.6). Just tried a fresh "mvn
clean", "mvn install" with revision 25647.
Some issues reported to me - someone with a clean machine trying to
build geoserver trunk, and some myself with state of geoserver trunk.
I have build Geoserver trunk last week with success (revision 6590). But I do
not relies on the JAR deployed on Maven. I build Geotools first (so latest
Geotools JAR are installed in my local Maven repository), then Geoserver.
me too, which is why the report came from someone who tried just geoserver - i never saw that problem.
Maybe we just need a volunter for deploying Geotools 2.4-SNAPSHOT jars on the
Refractions repository? It should just be a matter of running "mvn deploy" on
Geotools trunk - nothing else to do on a properly configured system. I can do
that, but do we have a policy on the frequency of 2.4-SNAPSHOT deployment, and
about who should do them?
Yep - at the very least, we should decide if we are allowed to commit to geoserver trunk things that rely on updates to geotools? either way is workable - if you work on geoserver trunk then working on geotools trunk may not be such a burden. But not being clear is an issue.
Pros and cons..
Stable branches obviously need the geotools libraries deployed. Sticking with a sinlge mechanism is easier.
On the other hand, everyone with commit rights to geoserver and getotools needs to be able to deploy geotools,unless it is automatically built and deployed as a snapshot.
is anyone else having build problems at the moment?
It work fine for me (Linux, Java 1.4, Maven 2.0.6). Just tried a fresh "mvn
clean", "mvn install" with revision 25647.
Well, the basic build issues on both geotools and geoserver have gone away with whatever was updated between then and now, however IMHO the issue remains - what level of stability do we expect, and how do we do better if we dont expect the build to be broken without warning?
apprarently the maven repository jar files still dont match the geoserver trunk code
is anyone else having build problems at the moment?
It work fine for me (Linux, Java 1.4, Maven 2.0.6). Just tried a fresh "mvn
clean", "mvn install" with revision 25647.
Well, the basic build issues on both geotools and geoserver have gone away with whatever was updated between then and now, however IMHO the issue remains - what level of stability do we expect, and how do we do better if we dont expect the build to be broken without warning?
All Geoserver branches do need the latest and greatest version of
the associated Geotools branch, this is because we do rely on
changes and bug fixes that we develop in parallel on the two
projects.
So yeah, we would need build servers to perform deploy too for
at least gt2 2.3.x and gt2 trunk. I guess we need the OpenPlans
ones to do this work, since afaik the Refractions ones are building
jars with java5 (btw, are those build server still operating, I think
I've never seen a mail about a build broken from those).
On the other hand, everyone with commit rights to geoserver and
getotools needs to be able to deploy geotools,unless it is automatically
built and deployed as a snapshot.
I believe that everyone with write access on Geotools SVN has write access on
Refraction repository, since it uses the same user/password database if I
understand right. What you need it to create a ~/.m2/settings.xml file with a
content similar to the attached file. Once it is done, just running
mvn deploy
from the Geotools root directory should work. The question is: who should run
"mvn deploy", at which frequency? A possible answer may be: any Geoserver
developper who introduced a dependency to a recent Geotools API.
So yeah, we would need build servers to perform deploy too for
at least gt2 2.3.x and gt2 trunk. I guess we need the OpenPlans
ones to do this work, since afaik the Refractions ones are building
jars with java5 (btw, are those build server still operating, I think
I've never seen a mail about a build broken from those).
Yes -- the Refractions build box is still going (but with java 5). E-mails are sent to the uDig team, but the build box is only accessible inside the refractions LAN. Tasks that still need to be done:
- get online tests to pass and run nightly
- poke a hole in the refractions firewall to expose the build box
- test against multiple local postgres/postgis versions
Unfortunately, I haven't been able to get permission to work on these tasks.
Well, the basic build issues on both geotools and geoserver have gone away with whatever was updated between then and now, however IMHO the issue remains - what level of stability do we expect, and how do we do better if we dont expect the build to be broken without warning?
apprarently the maven repository jar files still dont match the geoserver trunk code
We can run mvn deploy on the geotools side when ever it is needed. I thought we had one of the nightly builds set up to do this ...
Jody
Well, the basic build issues on both geotools and geoserver have gone away with whatever was updated between then and now, however IMHO the issue remains - what level of stability do we expect, and how do we do better if we dont expect the build to be broken without warning?
apprarently the maven repository jar files still dont match the geoserver trunk code
We can run mvn deploy on the geotools side when ever it is needed. I thought we had one of the nightly builds set up to do this ...
Hmm... having just a nightly gives little confidence of having
geoserver trunk buildable, mostly because the two are modified in
parallel. To have other people be able and build Geoserver without
Geotools, we need the continuous build to deploy, which is quite
expensive.
Given the development model, we may be forced to tell people that
Geoserver and Geotools are one, and as such they need to download
and build both...
Given the development model, we may be forced to tell people that
Geoserver and Geotools are one, and as such they need to download
and build both...
This is reasonable, for trunk, but probably not for stable branches?
And we must actually _tell_ people. Probably the best way would be to somehow force maven to tell you - i.e. instead of downloading an old version of the jars hopefully from the repository....
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Given the development model, we may be forced to tell people that
Geoserver and Geotools are one, and as such they need to download
and build both...
This is reasonable, for trunk, but probably not for stable branches?
Hum, yeah, for stable branches a nightly should be enough, at least
for now. Let me elaborate: on trunk we have initial unit testing.
Imagine a situation where current trunk has become stable, and
we have unit tests. We spot a bug, add a unit test for it.
The fix requires some changes in geotools. Boom, now your
build will again require the latest and the greatest of geotools,
because without it, unit tests will fail.
And we must actually _tell_ people. Probably the best way would be to somehow force maven to tell you - i.e. instead of downloading an old version of the jars hopefully from the repository....
There is no way that maven will tell you. The best we can do
is to upgrade the user guide afaik.
