[Geoserver-devel] request for svn repository for the nightly builds?

I have been intermittently downloading and installing the nightly builds
(windows binaries) for testing. I am using the Windows service wrapper and
ArcSDE plugin which I need to combine with the nightly built files, so
updating to a new nightly is a multi-step process.

Here is what I currently do...
1. Download the nightly windows binary zip file
2. Expand it to a new directory (so I can go back to the prior version, if
needed)
3. Copy over the files needed for the Windows service and ArcSDE plugin
4. Update the Windows service configuration file
5. Start the service and look in the wrapper log

I'm wondering if there is a better way... (suggestions are appreciated)

It seem like a subversion repository of the built nightly files (individual
files, not the zip) would be very useful for keeping up with the nightlies.
With access to such a repository:
- I could simply do an svn update to get the latest nightly
- The download would take less time
- I wouldn't have to worry about keeping the prior version files around,
because I could update to a prior version
- Overall, it would reduce the amount of effort needed keep testing

- Tyler

--
View this message in context: http://www.nabble.com/request-for-svn-repository-for-the-nightly-builds--tf4256387.html#a12113331
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

Tyler Erickson ha scritto:

I have been intermittently downloading and installing the nightly builds
(windows binaries) for testing. I am using the Windows service wrapper and
ArcSDE plugin which I need to combine with the nightly built files, so
updating to a new nightly is a multi-step process.

Here is what I currently do...
1. Download the nightly windows binary zip file
2. Expand it to a new directory (so I can go back to the prior version, if
needed)
3. Copy over the files needed for the Windows service and ArcSDE plugin
4. Update the Windows service configuration file
5. Start the service and look in the wrapper log

I'm wondering if there is a better way... (suggestions are appreciated)

It seem like a subversion repository of the built nightly files (individual
files, not the zip) would be very useful for keeping up with the nightlies.
With access to such a repository:
- I could simply do an svn update to get the latest nightly
- The download would take less time
- I wouldn't have to worry about keeping the prior version files around,
because I could update to a prior version
- Overall, it would reduce the amount of effort needed keep testing

Maybe yes, maybe not. GeoServer depends on GeoTools, so you have to
check out both of them to build from sources. A GeoTools build
takes 7-10 minutes on a (very) fast PC, a GeoServer build takes
4 minutes on the same PC.
Anyways, if you want to try, you need to checkout:
https://svn.codehaus.org/geoserver/trunk
http://svn.geotools.org/geotools/branches/2.4.x/
(oh, the very first build of it will take a lot longer, since
many jars will have to be downloaded from the Maven repositories).

and then:
* cd into GeoTools, run a "mvn clean install" in GeoTools
* cd into GeoServer, geoserver subdirectory , run a "mnv clean
   install".
(for a longer explanation, see the GeoServer and GeoTools
developer guides, especially if you're not familiar with Maven).

You can also try to checkout only GeoServer and go from there,
but expect occasional hiccups since GeoTools jars are updated
only once a day.

Cheers
Andrea

Andrea,

I haven't tried using Maven, primarily since I am not a java developer and
don't seem myself making changes to the source and rebuilding (at least not
in the near future). Because I am typically just testing out functionality
and reporting issues (rather than tracking down bugs in the source) working
files that are updated once a day has been fine.

I guess what I am looking for is an easier way to update to the nightly
builds (without building them myself). The latest nightly build (i.e.
geoserver-1.5.x-811107-bin.zip) contained 1034 files and totaled about 40MB.
I would imagine that very few of those files change from day to day. A
subversion repository containing all of the files that are contained within
the nightly build seems like it would make updating much more efficient.

Better yet, having subversion access to both the nightly and stable builds
(both bin and war formats) could potentially make it easier for testers to
flip between different builds. I know it is kind against the idea of only
storing source code in subversion, and it would require more storage, but it
could be useful.

I am curious about Justin's thoughts as the build master...

- Tyler

aaime wrote:

Tyler Erickson ha scritto:

I have been intermittently downloading and installing the nightly builds
(windows binaries) for testing. I am using the Windows service wrapper
and
ArcSDE plugin which I need to combine with the nightly built files, so
updating to a new nightly is a multi-step process.

Here is what I currently do...
1. Download the nightly windows binary zip file
2. Expand it to a new directory (so I can go back to the prior version,
if
needed)
3. Copy over the files needed for the Windows service and ArcSDE plugin
4. Update the Windows service configuration file
5. Start the service and look in the wrapper log

I'm wondering if there is a better way... (suggestions are appreciated)

It seem like a subversion repository of the built nightly files
(individual
files, not the zip) would be very useful for keeping up with the
nightlies.
With access to such a repository:
- I could simply do an svn update to get the latest nightly
- The download would take less time
- I wouldn't have to worry about keeping the prior version files around,
because I could update to a prior version
- Overall, it would reduce the amount of effort needed keep testing

Maybe yes, maybe not. GeoServer depends on GeoTools, so you have to
check out both of them to build from sources. A GeoTools build
takes 7-10 minutes on a (very) fast PC, a GeoServer build takes
4 minutes on the same PC.
Anyways, if you want to try, you need to checkout:
https://svn.codehaus.org/geoserver/trunk
http://svn.geotools.org/geotools/branches/2.4.x/
(oh, the very first build of it will take a lot longer, since
many jars will have to be downloaded from the Maven repositories).

and then:
* cd into GeoTools, run a "mvn clean install" in GeoTools
* cd into GeoServer, geoserver subdirectory , run a "mnv clean
   install".
(for a longer explanation, see the GeoServer and GeoTools
developer guides, especially if you're not familiar with Maven).

You can also try to checkout only GeoServer and go from there,
but expect occasional hiccups since GeoTools jars are updated
only once a day.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
View this message in context: http://www.nabble.com/request-for-svn-repository-for-the-nightly-builds--tf4256387.html#a12115513
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

Hi Tyler,

I am not sure that storing this in a subversion repository will be a big
win over downloading because subversion cannot diff binary files very
well... so doing an svn up would pretty much be downloading the entire
40M anyways. Also the repository would become quite large. Even removing
old binaries really doesn't remove them from subversion, and again diffs
are huge so the space requirement would be substantial.

The only thing I can think of to make this somewhat easier is this. We
could configure the nightly builds to create timestamped builds like
they do now as well as creating a build tagged "latest", which naturally
would be the most recent build.

So then what you could do is setup a little batch script or cron job
that could download the "latest" build automatically every day or
something. What are your thoughts on that Tyler?

-Justin

Tyler Erickson wrote:

Andrea,

I haven't tried using Maven, primarily since I am not a java developer and
don't seem myself making changes to the source and rebuilding (at least not
in the near future). Because I am typically just testing out functionality
and reporting issues (rather than tracking down bugs in the source) working
files that are updated once a day has been fine.

I guess what I am looking for is an easier way to update to the nightly
builds (without building them myself). The latest nightly build (i.e.
geoserver-1.5.x-811107-bin.zip) contained 1034 files and totaled about 40MB.
I would imagine that very few of those files change from day to day. A
subversion repository containing all of the files that are contained within
the nightly build seems like it would make updating much more efficient.

Better yet, having subversion access to both the nightly and stable builds
(both bin and war formats) could potentially make it easier for testers to
flip between different builds. I know it is kind against the idea of only
storing source code in subversion, and it would require more storage, but it
could be useful.

I am curious about Justin's thoughts as the build master...

- Tyler

aaime wrote:

Tyler Erickson ha scritto:

I have been intermittently downloading and installing the nightly builds
(windows binaries) for testing. I am using the Windows service wrapper
and
ArcSDE plugin which I need to combine with the nightly built files, so
updating to a new nightly is a multi-step process.

Here is what I currently do...
1. Download the nightly windows binary zip file
2. Expand it to a new directory (so I can go back to the prior version,
if
needed)
3. Copy over the files needed for the Windows service and ArcSDE plugin
4. Update the Windows service configuration file
5. Start the service and look in the wrapper log

I'm wondering if there is a better way... (suggestions are appreciated)

It seem like a subversion repository of the built nightly files
(individual
files, not the zip) would be very useful for keeping up with the
nightlies.
With access to such a repository:
- I could simply do an svn update to get the latest nightly
- The download would take less time
- I wouldn't have to worry about keeping the prior version files around,
because I could update to a prior version
- Overall, it would reduce the amount of effort needed keep testing

Maybe yes, maybe not. GeoServer depends on GeoTools, so you have to
check out both of them to build from sources. A GeoTools build
takes 7-10 minutes on a (very) fast PC, a GeoServer build takes
4 minutes on the same PC.
Anyways, if you want to try, you need to checkout:
https://svn.codehaus.org/geoserver/trunk
http://svn.geotools.org/geotools/branches/2.4.x/
(oh, the very first build of it will take a lot longer, since
many jars will have to be downloaded from the Maven repositories).

and then:
* cd into GeoTools, run a "mvn clean install" in GeoTools
* cd into GeoServer, geoserver subdirectory , run a "mnv clean
   install".
(for a longer explanation, see the GeoServer and GeoTools
developer guides, especially if you're not familiar with Maven).

You can also try to checkout only GeoServer and go from there,
but expect occasional hiccups since GeoTools jars are updated
only once a day.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin,

I didn't think about the problem with subversion diff'ing binary files.
That is unfortunate, since it would cause the repository to become large
with duplicate copies of the same files, and it would cause the update step
to download all the binaries every time. Doesn't sound like a good
option...

Given that, I would be interested in automating whatever parts of my current
manual process that I can. Because I am using windows, I don't have access
to cron. What would you suggest in regards to the batch script?

- Tyler

Justin Deoliveira-4 wrote:

Hi Tyler,

I am not sure that storing this in a subversion repository will be a big
win over downloading because subversion cannot diff binary files very
well... so doing an svn up would pretty much be downloading the entire
40M anyways. Also the repository would become quite large. Even removing
old binaries really doesn't remove them from subversion, and again diffs
are huge so the space requirement would be substantial.

The only thing I can think of to make this somewhat easier is this. We
could configure the nightly builds to create timestamped builds like
they do now as well as creating a build tagged "latest", which naturally
would be the most recent build.

So then what you could do is setup a little batch script or cron job
that could download the "latest" build automatically every day or
something. What are your thoughts on that Tyler?

-Justin

Tyler Erickson wrote:

Andrea,

I haven't tried using Maven, primarily since I am not a java developer
and
don't seem myself making changes to the source and rebuilding (at least
not
in the near future). Because I am typically just testing out
functionality
and reporting issues (rather than tracking down bugs in the source)
working
files that are updated once a day has been fine.

I guess what I am looking for is an easier way to update to the nightly
builds (without building them myself). The latest nightly build (i.e.
geoserver-1.5.x-811107-bin.zip) contained 1034 files and totaled about
40MB.
I would imagine that very few of those files change from day to day. A
subversion repository containing all of the files that are contained
within
the nightly build seems like it would make updating much more efficient.

Better yet, having subversion access to both the nightly and stable
builds
(both bin and war formats) could potentially make it easier for testers
to
flip between different builds. I know it is kind against the idea of
only
storing source code in subversion, and it would require more storage, but
it
could be useful.

I am curious about Justin's thoughts as the build master...

- Tyler

aaime wrote:

Tyler Erickson ha scritto:

I have been intermittently downloading and installing the nightly
builds
(windows binaries) for testing. I am using the Windows service wrapper
and
ArcSDE plugin which I need to combine with the nightly built files, so
updating to a new nightly is a multi-step process.

Here is what I currently do...
1. Download the nightly windows binary zip file
2. Expand it to a new directory (so I can go back to the prior version,
if
needed)
3. Copy over the files needed for the Windows service and ArcSDE plugin
4. Update the Windows service configuration file
5. Start the service and look in the wrapper log

I'm wondering if there is a better way... (suggestions are
appreciated)

It seem like a subversion repository of the built nightly files
(individual
files, not the zip) would be very useful for keeping up with the
nightlies.
With access to such a repository:
- I could simply do an svn update to get the latest nightly
- The download would take less time
- I wouldn't have to worry about keeping the prior version files
around,
because I could update to a prior version
- Overall, it would reduce the amount of effort needed keep testing

Maybe yes, maybe not. GeoServer depends on GeoTools, so you have to
check out both of them to build from sources. A GeoTools build
takes 7-10 minutes on a (very) fast PC, a GeoServer build takes
4 minutes on the same PC.
Anyways, if you want to try, you need to checkout:
https://svn.codehaus.org/geoserver/trunk
http://svn.geotools.org/geotools/branches/2.4.x/
(oh, the very first build of it will take a lot longer, since
many jars will have to be downloaded from the Maven repositories).

and then:
* cd into GeoTools, run a "mvn clean install" in GeoTools
* cd into GeoServer, geoserver subdirectory , run a "mnv clean
   install".
(for a longer explanation, see the GeoServer and GeoTools
developer guides, especially if you're not familiar with Maven).

You can also try to checkout only GeoServer and go from there,
but expect occasional hiccups since GeoTools jars are updated
only once a day.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
View this message in context: http://www.nabble.com/request-for-svn-repository-for-the-nightly-builds--tf4256387.html#a12118097
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

Tyler Erickson wrote:

Justin,

I didn't think about the problem with subversion diff'ing binary files.
That is unfortunate, since it would cause the repository to become large
with duplicate copies of the same files, and it would cause the update step
to download all the binaries every time. Doesn't sound like a good
option...

Given that, I would be interested in automating whatever parts of my current
manual process that I can. Because I am using windows, I don't have access
to cron. What would you suggest in regards to the batch script?

Hmmm... I am not sure what there is available for windows in terms of
job scheduling... but this looks somewhat promising:

http://cronw.sourceforge.net/

Or I guess you could always install cygwin.

Regardless... I think some sort of nightly script in conjunction with us
tagging the most recent nightly build with "latest" so the file name
remains the same will probably be the best solution.

- Tyler

Justin Deoliveira-4 wrote:

Hi Tyler,

I am not sure that storing this in a subversion repository will be a big
win over downloading because subversion cannot diff binary files very
well... so doing an svn up would pretty much be downloading the entire
40M anyways. Also the repository would become quite large. Even removing
old binaries really doesn't remove them from subversion, and again diffs
are huge so the space requirement would be substantial.

The only thing I can think of to make this somewhat easier is this. We
could configure the nightly builds to create timestamped builds like
they do now as well as creating a build tagged "latest", which naturally
would be the most recent build.

So then what you could do is setup a little batch script or cron job
that could download the "latest" build automatically every day or
something. What are your thoughts on that Tyler?

-Justin

Tyler Erickson wrote:

Andrea,

I haven't tried using Maven, primarily since I am not a java developer
and
don't seem myself making changes to the source and rebuilding (at least
not
in the near future). Because I am typically just testing out
functionality
and reporting issues (rather than tracking down bugs in the source)
working
files that are updated once a day has been fine.

I guess what I am looking for is an easier way to update to the nightly
builds (without building them myself). The latest nightly build (i.e.
geoserver-1.5.x-811107-bin.zip) contained 1034 files and totaled about
40MB.
I would imagine that very few of those files change from day to day. A
subversion repository containing all of the files that are contained
within
the nightly build seems like it would make updating much more efficient.

Better yet, having subversion access to both the nightly and stable
builds
(both bin and war formats) could potentially make it easier for testers
to
flip between different builds. I know it is kind against the idea of
only
storing source code in subversion, and it would require more storage, but
it
could be useful.

I am curious about Justin's thoughts as the build master...

- Tyler

aaime wrote:

Tyler Erickson ha scritto:

I have been intermittently downloading and installing the nightly
builds
(windows binaries) for testing. I am using the Windows service wrapper
and
ArcSDE plugin which I need to combine with the nightly built files, so
updating to a new nightly is a multi-step process.

Here is what I currently do...
1. Download the nightly windows binary zip file
2. Expand it to a new directory (so I can go back to the prior version,
if
needed)
3. Copy over the files needed for the Windows service and ArcSDE plugin
4. Update the Windows service configuration file
5. Start the service and look in the wrapper log

I'm wondering if there is a better way... (suggestions are
appreciated)

It seem like a subversion repository of the built nightly files
(individual
files, not the zip) would be very useful for keeping up with the
nightlies.
With access to such a repository:
- I could simply do an svn update to get the latest nightly
- The download would take less time
- I wouldn't have to worry about keeping the prior version files
around,
because I could update to a prior version
- Overall, it would reduce the amount of effort needed keep testing

Maybe yes, maybe not. GeoServer depends on GeoTools, so you have to
check out both of them to build from sources. A GeoTools build
takes 7-10 minutes on a (very) fast PC, a GeoServer build takes
4 minutes on the same PC.
Anyways, if you want to try, you need to checkout:
https://svn.codehaus.org/geoserver/trunk
http://svn.geotools.org/geotools/branches/2.4.x/
(oh, the very first build of it will take a lot longer, since
many jars will have to be downloaded from the Maven repositories).

and then:
* cd into GeoTools, run a "mvn clean install" in GeoTools
* cd into GeoServer, geoserver subdirectory , run a "mnv clean
   install".
(for a longer explanation, see the GeoServer and GeoTools
developer guides, especially if you're not familiar with Maven).

You can also try to checkout only GeoServer and go from there,
but expect occasional hiccups since GeoTools jars are updated
only once a day.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org