[Geoserver-devel] download size of GeoServer

GeoServer GeoServer Developer
1

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for
those of us with unlimited bandwidth in the first world, but for many
people this is a huge issue. I just met a user trying out GeoServer in
India, and one of his top two requests was to cut down the size of
GeoServer.

The source of the problem is easy to fix, our docs download is 15 megs,
which is obviously way more than should be in docs. 2 minutes of
investigation point to an 8 meg zipped file of data. And a few 500kb
pdf files, of which the validation guide is the only one that hasn't
been completely ported (and it's included at least twice). There are
probably more.

I think the best course of action would be to put all the big files into
the GEOS space as attachments there. But more than that, could release
managers start to actually pay attention to the size of the release?
From the last release I cut down the size of the source download, which
had blown up to 50 megs, due to a 17 meg shapefile and all the jars
being needlessly duplicated in the server/ directory. But it only
ended up as 10 megs less than the previous, due to the extra docs.

I just added a section to the release guide on checking the size, but I
just wanted to email the list to emphasize that this is important.
Indeed it was one of the goals of firefox, to make a nice small
download. It seems like a minor thing, but I know that for many users
it's very important for first impressions, they'll think the software
is needless bloated and move on to another package.

best regards,

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

2

Chris -- just a thought..but if you move to a maven style build, then
maybe you don't have to distribute most of the jars, but can let maven
download them?

On 12/21/05, Chris Holmes <cholmes@anonymised.com> wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for

3

Hi Chris,

Sounds good, next release we can leave the docs out and have them be a seperate download. Thanks for throwing this in the release guide, as you say us people with unlimited bandwidth can be ignorant of file sizes.

Your pet peeve feeds nicley into mine, which is storing binary data in the subversion repository. It makes checking out geoserver painful as well and storing binary data in subversion isn't the best idea to start with. Two recommendations:

1. Move to maven instead of ant, this way we dont have to store any jars in the repository. As a side note the ant build file has become very hard to maintain. Maven assumes reasonable defaults for things that the ant script sets up manually.

2. Move all the data (configurations) to a web server or web dav folder and download as needed. We could even set up these as maven dependencies to be automagically downloaded.

Just some thoughts, I dont want so see these changes right away as we are pushing toward 1.3.0, however I would like to see them brought into th 1.4.x stream.

-Justin

Chris Holmes wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for
those of us with unlimited bandwidth in the first world, but for many
people this is a huge issue. I just met a user trying out GeoServer in
India, and one of his top two requests was to cut down the size of
GeoServer.

The source of the problem is easy to fix, our docs download is 15 megs,
which is obviously way more than should be in docs. 2 minutes of
investigation point to an 8 meg zipped file of data. And a few 500kb
pdf files, of which the validation guide is the only one that hasn't
been completely ported (and it's included at least twice). There are
probably more.

I think the best course of action would be to put all the big files into
the GEOS space as attachments there. But more than that, could release
managers start to actually pay attention to the size of the release? From the last release I cut down the size of the source download, which
had blown up to 50 megs, due to a 17 meg shapefile and all the jars
being needlessly duplicated in the server/ directory. But it only
ended up as 10 megs less than the previous, due to the extra docs.

I just added a section to the release guide on checking the size, but I
just wanted to email the list to emphasize that this is important. Indeed it was one of the goals of firefox, to make a nice small
download. It seems like a minor thing, but I know that for many users
it's very important for first impressions, they'll think the software
is needless bloated and move on to another package.

best regards,

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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

4

The two largs parts of the download are the java docs and the wiki exported docs. If we cut them both out, and just put them in the separate docs download, it should be a tiny download.

I'm up for doing it.

Brent Owens
TOPP

Chris Holmes wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for
those of us with unlimited bandwidth in the first world, but for many
people this is a huge issue. I just met a user trying out GeoServer in
India, and one of his top two requests was to cut down the size of
GeoServer.

The source of the problem is easy to fix, our docs download is 15 megs,
which is obviously way more than should be in docs. 2 minutes of
investigation point to an 8 meg zipped file of data. And a few 500kb
pdf files, of which the validation guide is the only one that hasn't
been completely ported (and it's included at least twice). There are
probably more.

I think the best course of action would be to put all the big files into
the GEOS space as attachments there. But more than that, could release
managers start to actually pay attention to the size of the release?

From the last release I cut down the size of the source download, which

had blown up to 50 megs, due to a 17 meg shapefile and all the jars
being needlessly duplicated in the server/ directory. But it only
ended up as 10 megs less than the previous, due to the extra docs.

I just added a section to the release guide on checking the size, but I
just wanted to email the list to emphasize that this is important. Indeed it was one of the goals of firefox, to make a nice small
download. It seems like a minor thing, but I know that for many users
it's very important for first impressions, they'll think the software
is needless bloated and move on to another package.

best regards,

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

Maven is a good idea, but for a release I dont think users really want to run a maven build as part of downloading geoservers. However I would love to see maven used for geoserver build and release management though.

-Justin

Davis Ford wrote:

Chris -- just a thought..but if you move to a maven style build, then
maybe you don't have to distribute most of the jars, but can let maven
download them?

On 12/21/05, Chris Holmes <cholmes@anonymised.com> wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
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

6

Justin and I were thinking about that. Maven would also solve some other problems, such as knowing what version of the jars we are using (Struts for example). We might slowley introduce it and see what people think, but also leave the ant script there.

Any comments from the community?

Brent Owens
TOPP

Davis Ford wrote:

Chris -- just a thought..but if you move to a maven style build, then
maybe you don't have to distribute most of the jars, but can let maven
download them?

On 12/21/05, Chris Holmes <cholmes@anonymised.com> wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for
   
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

maven also has the ability to generate the ant script if you want to
keep it there. it might be an option. if you set up maven properly,
you can auto-generate the ant script if people want to continue to use
that. i had never used maven before, but started with it after using
geotools, and have started setting up my own projects with it. i
think it has a lot of advantages. i haven't moved to maven 2, yet.

one thing i found is that www.ibiblio.org/maven doesn't house all the
jars that are always needed and jar maintainers don't seem to always
provide a way to get them (e.g. oracle JDBC driver). one way around
this is to distribute the small number of jars that can't be d/l, and
write the maven dependency to a lib directory for only those. that
would still reduce the d/l size.

On 12/21/05, Brent Owens <brentowens@anonymised.com> wrote:

Justin and I were thinking about that. Maven would also solve some other
problems, such as knowing what version of the jars we are using (Struts
for example). We might slowley introduce it and see what people think,
but also leave the ant script there.

Any comments from the community?

Brent Owens
TOPP

Davis Ford wrote:

>Chris -- just a thought..but if you move to a maven style build, then
>maybe you don't have to distribute most of the jars, but can let maven
>download them?
>
>On 12/21/05, Chris Holmes <cholmes@anonymised.com> wrote:
>
>
>>Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
>>the size of the download. I know that this is a trivial issue for
>>
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>_______________________________________________
>Geoserver-devel mailing list
>Geoserver-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>

8

Davis Ford wrote:

maven also has the ability to generate the ant script if you want to
keep it there. it might be an option. if you set up maven properly,
you can auto-generate the ant script if people want to continue to use
that. i had never used maven before, but started with it after using
geotools, and have started setting up my own projects with it. i
think it has a lot of advantages. i haven't moved to maven 2, yet.

Hmm, i didn't know maven could generate ant scripts, that is interesting. I tried out maven 2, I was a little disapointed. There is a lack of documentation compared to maven 1, and though they boast full feature coverage of maven 1, i have found instances where this is not so. That being said, there are some things that are quite nice like transitive dependencies.

one thing i found is that www.ibiblio.org/maven doesn't house all the
jars that are always needed and jar maintainers don't seem to always
provide a way to get them (e.g. oracle JDBC driver). one way around
this is to distribute the small number of jars that can't be d/l, and
write the maven dependency to a lib directory for only those. that
would still reduce the d/l size.

You can add any number of repositories to the list of ones maven looks for jars in. For any jars not on ibliblio I just throw them up on dist.codehaus.org/maven.

On 12/21/05, Brent Owens <brentowens@anonymised.com> wrote:

Justin and I were thinking about that. Maven would also solve some other
problems, such as knowing what version of the jars we are using (Struts
for example). We might slowley introduce it and see what people think,
but also leave the ant script there.

Any comments from the community?

Brent Owens
TOPP

Davis Ford wrote:

Chris -- just a thought..but if you move to a maven style build, then
maybe you don't have to distribute most of the jars, but can let maven
download them?

On 12/21/05, Chris Holmes <cholmes@anonymised.com> wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
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

9

I agree with you on maven 2. I wouldn't mess with it right now. I've
been using 1.0.2 pretty happily now for a bit. You might want to
check http://maven.apache.org/using/migrating.html -- it has
migration pointers away from ant.

You could also have maven point to the existing ant scripts, but they
point out that this is kind of defeating the purpose.

If you run "maven ant" it will generate build.xml. The challenge, of
course, would be creating the maven setup (i.e. dir structure and
project.xml, project.properties) so it generates build.xml that makes
sense, but probably if you get that far, you might toss ant
altogether.

On 12/21/05, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Davis Ford wrote:
> maven also has the ability to generate the ant script if you want to
> keep it there. it might be an option. if you set up maven properly,
> you can auto-generate the ant script if people want to continue to use
> that. i had never used maven before, but started with it after using
> geotools, and have started setting up my own projects with it. i
> think it has a lot of advantages. i haven't moved to maven 2, yet.
Hmm, i didn't know maven could generate ant scripts, that is
interesting. I tried out maven 2, I was a little disapointed. There is a
  lack of documentation compared to maven 1, and though they boast full
feature coverage of maven 1, i have found instances where this is not
so. That being said, there are some things that are quite nice like
transitive dependencies.
>
> one thing i found is that www.ibiblio.org/maven doesn't house all the
> jars that are always needed and jar maintainers don't seem to always
> provide a way to get them (e.g. oracle JDBC driver). one way around
> this is to distribute the small number of jars that can't be d/l, and
> write the maven dependency to a lib directory for only those. that
> would still reduce the d/l size.
You can add any number of repositories to the list of ones maven looks
for jars in. For any jars not on ibliblio I just throw them up on
dist.codehaus.org/maven.
>
> On 12/21/05, Brent Owens <brentowens@anonymised.com> wrote:
>
>>Justin and I were thinking about that. Maven would also solve some other
>>problems, such as knowing what version of the jars we are using (Struts
>>for example). We might slowley introduce it and see what people think,
>>but also leave the ant script there.
>>
>>Any comments from the community?
>>
>>Brent Owens
>>TOPP
>>
>>
>>
>>Davis Ford wrote:
>>
>>
>>>Chris -- just a thought..but if you move to a maven style build, then
>>>maybe you don't have to distribute most of the jars, but can let maven
>>>download them?
>>>
>>>On 12/21/05, Chris Holmes <cholmes@anonymised.com> wrote:
>>>
>>>
>>>
>>>>Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
>>>>the size of the download. I know that this is a trivial issue for
>>>>
>>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>for problems? Stop! Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>_______________________________________________
>>>Geoserver-devel mailing list
>>>Geoserver-devel@lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>>
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> 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

10

Quoting Brent Owens <brentowens@anonymised.com>:

The two largs parts of the download are the java docs and the wiki
exported docs. If we cut them both out, and just put them in the
separate docs download, it should be a tiny download.

Er, java docs actually don't make it into the binary releases. As for
the wiki docs, I think it's important to have them there, but the point
of my email is I believe they can be much, much smaller. Like by
getting rid of the duplicate pdfs and the 7 meg sample data that are
included now. I'd like to see how small it is without all the extra
cruft, as I think it's nice to have the docs with your initial
download. The only thing of size should be images, and honestly none
of those should really be all that big, if they are we should make
smaller versions.

As for maven, I personally have no pet peeve with jars in the
repository, I'm curious what the problem with them is? I actually like
having real versioning on them. Like you can rollback to an older
geotools jar. If we're better with actually releasing geotools I'd be
more for it, indeed I don't think the geoserver team has stepped up to
put out a geotools release since last year maybe. But as it is the
version is always 2.1.x. I know there are ways around this, as udig
handles it somehow, but I've never been convinced that it really does
the versioning that well. That said I don't really want to argue this
point, since I really care very little, and if it's someone else's pet
peeve and they want to take care of it, then go for it. I can think of
no compelling reasons against it (though I'm against putting out binary
releases without the jars, I very much think they should be there).
Keeping an ant script around would be nice though.

Chris

I'm up for doing it.

Brent Owens
TOPP

Chris Holmes wrote:

>Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to
see
>the size of the download. I know that this is a trivial issue for
>those of us with unlimited bandwidth in the first world, but for
many
>people this is a huge issue. I just met a user trying out GeoServer
in
>India, and one of his top two requests was to cut down the size of
>GeoServer.
>
>The source of the problem is easy to fix, our docs download is 15
megs,
>which is obviously way more than should be in docs. 2 minutes of
>investigation point to an 8 meg zipped file of data. And a few
500kb
>pdf files, of which the validation guide is the only one that hasn't
>been completely ported (and it's included at least twice). There
are
>probably more.
>
>I think the best course of action would be to put all the big files
into
>the GEOS space as attachments there. But more than that, could
release
>managers start to actually pay attention to the size of the release?
>>From the last release I cut down the size of the source download,
which
>had blown up to 50 megs, due to a 17 meg shapefile and all the jars
>being needlessly duplicated in the server/ directory. But it only
>ended up as 10 megs less than the previous, due to the extra docs.
>
>I just added a section to the release guide on checking the size,
but I
>just wanted to email the list to emphasize that this is important.
>Indeed it was one of the goals of firefox, to make a nice small
>download. It seems like a minor thing, but I know that for many
users
>it's very important for first impressions, they'll think the
software
>is needless bloated and move on to another package.
>
>best regards,
>
>Chris
>
>
>----------------------------------------------------------
>This mail sent through IMP: https://webmail.limegroup.com/
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Geoserver-devel mailing list
>Geoserver-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

11

Chris Holmes wrote:

Quoting Brent Owens <brentowens@anonymised.com>:

The two largs parts of the download are the java docs and the wiki
exported docs. If we cut them both out, and just put them in the
separate docs download, it should be a tiny download.

Er, java docs actually don't make it into the binary releases. As for
the wiki docs, I think it's important to have them there, but the point
of my email is I believe they can be much, much smaller. Like by
getting rid of the duplicate pdfs and the 7 meg sample data that are
included now. I'd like to see how small it is without all the extra
cruft, as I think it's nice to have the docs with your initial
download. The only thing of size should be images, and honestly none
of those should really be all that big, if they are we should make
smaller versions.

As for maven, I personally have no pet peeve with jars in the
repository, I'm curious what the problem with them is? I actually like
having real versioning on them. Like you can rollback to an older
geotools jar. If we're better with actually releasing geotools I'd be
more for it, indeed I don't think the geoserver team has stepped up to
put out a geotools release since last year maybe. But as it is the
version is always 2.1.x. I know there are ways around this, as udig
handles it somehow, but I've never been convinced that it really does
the versioning that well. That said I don't really want to argue this
point, since I really care very little, and if it's someone else's pet
peeve and they want to take care of it, then go for it. I can think of
no compelling reasons against it (though I'm against putting out binary
releases without the jars, I very much think they should be there). Keeping an ant script around would be nice though.

The jars may be "versioned" in the sense that they have revisions on them, and yes you can rollback so I like this as well. But a merge or diff of any sort will most certainly fail as subversion cant really keep diffs around on binary data. When playing on a branch that I tried to merge with geoserver trunk, subversion died in the middle of it (while trying to merge the lib directory), and I couldn't recover the locks on my workspace, so I ended up losing a bunch of work.

I guess my biggest problem was I tried to figure out which version of various software packages geoserver depends on, and couldn't. For instance finding out which version of struts we use. Maven forces you to use version numbers which I definitly like.

I guess my philosophy is "Use the right tool for the job". Subversion was built to properly version and manage source code, maven was built to manage projects which many library dependencies.

I know that not everyone likes maven as I do, so I would be interested to hear what the rest of he developers think.

I agree that we have gotten lazy with geotools releases, 2.1.x has essentially become a well maintained fork of geotools, I am hoping to make the official 2.1.1 release of geotools when we release geoserver 1.3.0. 1.3.1 can stay on 2.1.x but 1.4.x of geoserver will have to move onto geotools trunk.

-Justin

Chris

I'm up for doing it.

Brent Owens
TOPP

Chris Holmes wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to

see

the size of the download. I know that this is a trivial issue for
those of us with unlimited bandwidth in the first world, but for

many

people this is a huge issue. I just met a user trying out GeoServer

in

India, and one of his top two requests was to cut down the size of
GeoServer.

The source of the problem is easy to fix, our docs download is 15

megs,

which is obviously way more than should be in docs. 2 minutes of
investigation point to an 8 meg zipped file of data. And a few

500kb

pdf files, of which the validation guide is the only one that hasn't
been completely ported (and it's included at least twice). There

are

probably more.

I think the best course of action would be to put all the big files

into

the GEOS space as attachments there. But more than that, could

release

managers start to actually pay attention to the size of the release?

From the last release I cut down the size of the source download,

which

had blown up to 50 megs, due to a 17 meg shapefile and all the jars
being needlessly duplicated in the server/ directory. But it only
ended up as 10 megs less than the previous, due to the extra docs.

I just added a section to the release guide on checking the size,

but I

just wanted to email the list to emphasize that this is important.
Indeed it was one of the goals of firefox, to make a nice small
download. It seems like a minor thing, but I know that for many

users

it's very important for first impressions, they'll think the

software

is needless bloated and move on to another package.

best regards,

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through

log files

for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD

SPLUNK!

http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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

12

I can see the arguments for maven - logically it should reduce the amount of stuff you have to download if you have already seen these jars - but this really applies only to developers. It would still download as much, and you'd have to download and install maven itself!

Most deployers of geoserver will want a ready -to -run build. Really they want a WAR file. Maybe there is a scope for a download utility that allows them to choose plugins.

Even better - a minimal download with a wizard to connect and install the options required. Looking at the jars, probably half of them by size are for relatively esoteric functions - SVG rendering, many datasource plug-ins etc.

Even nicer, this sort modularisation would allow you to download fixes to plug-ins - say an updated Oracle datasource, or add a new dataource plugin.

So - maven for source releases and and a WAR file with component download capability for the main release IMHO

Not sure the best way to do jetty - but Tomcat deployers probably dont want to pay for downloading jetty.

Rob Atkinson

Justin Deoliveira wrote:

Maven is a good idea, but for a release I dont think users really want to run a maven build as part of downloading geoservers. However I would love to see maven used for geoserver build and release management though.

-Justin

Davis Ford wrote:

Chris -- just a thought..but if you move to a maven style build, then
maybe you don't have to distribute most of the jars, but can let maven
download them?

On 12/21/05, Chris Holmes <cholmes@anonymised.com> wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

13

Rob Atkinson wrote:

I can see the arguments for maven - logically it should reduce the amount of stuff you have to download if you have already seen these jars - but this really applies only to developers. It would still download as much, and you'd have to download and install maven itself!

Yeah, I agree maven is only a win for the devel team, it shoud really be transparent to users.

Most deployers of geoserver will want a ready -to -run build. Really they want a WAR file. Maybe there is a scope for a download utility that allows them to choose plugins.

Even better - a minimal download with a wizard to connect and install the options required. Looking at the jars, probably half of them by size are for relatively esoteric functions - SVG rendering, many datasource plug-ins etc.

Even nicer, this sort modularisation would allow you to download fixes to plug-ins - say an updated Oracle datasource, or add a new dataource plugin.

As part of transitioning over to maven and spring, It would be nice to see the codebase broken up into multiple projects/plugins. For instance breaking out wfs and wms into seperate plugins. That way if you dont use geoserver as a wms, you dont have to pay the price of downloading it or any of the libraries it depends on.

So - maven for source releases and and a WAR file with component download capability for the main release IMHO

Not sure the best way to do jetty - but Tomcat deployers probably dont want to pay for downloading jetty.

Again I would like to see jetty as a seperate plugin, optional for download.

Rob Atkinson

Justin Deoliveira wrote:

Maven is a good idea, but for a release I dont think users really want to run a maven build as part of downloading geoservers. However I would love to see maven used for geoserver build and release management though.

-Justin

Davis Ford wrote:

Chris -- just a thought..but if you move to a maven style build, then
maybe you don't have to distribute most of the jars, but can let maven
download them?

On 12/21/05, Chris Holmes <cholmes@anonymised.com> wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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

14

Have I missed something in my instalation? But now I have tried several
times to upload and then Validate both with the SLD-file that I have got
from uDig and with default_line.sld witch I have renamed.

I tried to change the schemalocation to:
http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd
but it doesn't matter.

Is this a known problem?

/ Rasmus Lindberg

<?xml version="1.0" encoding="ISO-8859-1"?>
2: <StyledLayerDescriptor version="1.0.0"
3: xsi:schemaLocation="http://www.opengis.net/sld
StyledLayerDescriptor.xsd"
4: xmlns="http://www.opengis.net/sld&quot;
5: xmlns:ogc="http://www.opengis.net/ogc&quot;
6: xmlns:xlink="http://www.w3.org/1999/xlink&quot;
7: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;&gt;
----------------------------------------------------------^
       cvc-elt.1: Cannot find the declaration of element
'StyledLayerDescriptor'.
8: <!-- a named layer is the basic building block of an sld
document -->
9:
10: <NamedLayer>
11: <Name>Default Line</Name>

15

Sorry for my really bad formulated question.
I start over and try to explain me a bit more.

I have installed RC7 and it seam to work. I have manged to store a shp-file
and it works to wiew it in uDig. Now I have tried to upload the SLD-file
that I have made for this shp-file. But I get this mess

cvc-elt.1: Cannot find the declaration of element 'StyledLayerDescriptor'.

When it is validated. I have tried to copy-rename-upload one of the
SLD-files that I found in the conf\styles folder but I get the same mess.

What was done with SLD Validation now for RC7? I supposed/hoped that SLD
validation sholud be no problem but I was probobly wrong.

/ Rasmus Lindberg

16

Hi Rasmus,

Can you include the sld document. Thanks.

-Justin

Rasmus Lindberg wrote:

Sorry for my really bad formulated question.
I start over and try to explain me a bit more.

I have installed RC7 and it seam to work. I have manged to store a shp-file
and it works to wiew it in uDig. Now I have tried to upload the SLD-file
that I have made for this shp-file. But I get this mess

cvc-elt.1: Cannot find the declaration of element 'StyledLayerDescriptor'.

When it is validated. I have tried to copy-rename-upload one of the
SLD-files that I found in the conf\styles folder but I get the same mess.

What was done with SLD Validation now for RC7? I supposed/hoped that SLD
validation sholud be no problem but I was probobly wrong.

/ Rasmus Lindberg

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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

17

I can include my SLD-file, but I don't think it matter. I just tried one
more time to Config->Data->Style->New. I set StyleID to "test" and then
tried to upload the file d:\www\SLD\default_line.sld which I copied from my
GeoServer-folder and I got the same problem. See
http://raz.dns2go.com/sld/styleEditorSubmit.htm
http://raz.dns2go.com/sld/default_line.sld

If you want to see my SLD file that I tried before it is here
http://raz.dns2go.com/sld/storaav.sld

/ Rasmus Lindberg

-----Ursprungligt meddelande-----
Från: geoserver-devel-admin@lists.sourceforge.net
[mailto:geoserver-devel-admin@lists.sourceforge.net] För Justin Deoliveira
Skickat: den 22 december 2005 17:33
Till: Rasmus Lindberg
Kopia: geoserver-devel@lists.sourceforge.net
Ämne: Re: [Geoserver-devel] SLD Validation??

Hi Rasmus,

Can you include the sld document. Thanks.

-Justin

Rasmus Lindberg wrote:

Sorry for my really bad formulated question.
I start over and try to explain me a bit more.

I have installed RC7 and it seam to work. I have manged to store a

shp-file

and it works to wiew it in uDig. Now I have tried to upload the SLD-file
that I have made for this shp-file. But I get this mess

cvc-elt.1: Cannot find the declaration of element 'StyledLayerDescriptor'.

When it is validated. I have tried to copy-rename-upload one of the
SLD-files that I found in the conf\styles folder but I get the same mess.

What was done with SLD Validation now for RC7? I supposed/hoped that SLD
validation sholud be no problem but I was probobly wrong.

/ Rasmus Lindberg

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log

files

for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

18

Hi Rasmus,

I just found a faq entry for this one.

http://docs.codehaus.org/pages/viewpage.action?pageId=40403

Hopefully that fixes your problem.

-Justin

Rasmus Lindberg wrote:

I can include my SLD-file, but I don't think it matter. I just tried one
more time to Config->Data->Style->New. I set StyleID to "test" and then
tried to upload the file d:\www\SLD\default_line.sld which I copied from my
GeoServer-folder and I got the same problem. See
http://raz.dns2go.com/sld/styleEditorSubmit.htm
http://raz.dns2go.com/sld/default_line.sld

If you want to see my SLD file that I tried before it is here
http://raz.dns2go.com/sld/storaav.sld

/ Rasmus Lindberg

-----Ursprungligt meddelande-----
Från: geoserver-devel-admin@lists.sourceforge.net
[mailto:geoserver-devel-admin@lists.sourceforge.net] För Justin Deoliveira
Skickat: den 22 december 2005 17:33
Till: Rasmus Lindberg
Kopia: geoserver-devel@lists.sourceforge.net
Ämne: Re: [Geoserver-devel] SLD Validation??

Hi Rasmus,

Can you include the sld document. Thanks.

-Justin

Rasmus Lindberg wrote:

Sorry for my really bad formulated question.
I start over and try to explain me a bit more.

I have installed RC7 and it seam to work. I have manged to store a

shp-file

and it works to wiew it in uDig. Now I have tried to upload the SLD-file
that I have made for this shp-file. But I get this mess

cvc-elt.1: Cannot find the declaration of element 'StyledLayerDescriptor'.

When it is validated. I have tried to copy-rename-upload one of the
SLD-files that I found in the conf\styles folder but I get the same mess.

What was done with SLD Validation now for RC7? I supposed/hoped that SLD
validation sholud be no problem but I was probobly wrong.

/ Rasmus Lindberg

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log

files

for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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

19

"Again I would like to see jetty as a seperate plugin, optional for download. "

I still think the one click installer is a wonderful idea (so be it, only for windows). It gives users the chance to try it out without doing too much, or knowing too much about the project. And I believe it is the most downloaded.
Maybe if it was an opt-out option.

Brent Owens
(The Open Planning Project)

Justin Deoliveira wrote:

Rob Atkinson wrote:

I can see the arguments for maven - logically it should reduce the amount of stuff you have to download if you have already seen these jars - but this really applies only to developers. It would still download as much, and you'd have to download and install maven itself!

Yeah, I agree maven is only a win for the devel team, it shoud really be transparent to users.

Most deployers of geoserver will want a ready -to -run build. Really they want a WAR file. Maybe there is a scope for a download utility that allows them to choose plugins.

Even better - a minimal download with a wizard to connect and install the options required. Looking at the jars, probably half of them by size are for relatively esoteric functions - SVG rendering, many datasource plug-ins etc.

Even nicer, this sort modularisation would allow you to download fixes to plug-ins - say an updated Oracle datasource, or add a new dataource plugin.

As part of transitioning over to maven and spring, It would be nice to see the codebase broken up into multiple projects/plugins. For instance breaking out wfs and wms into seperate plugins. That way if you dont use geoserver as a wms, you dont have to pay the price of downloading it or any of the libraries it depends on.

So - maven for source releases and and a WAR file with component download capability for the main release IMHO

Not sure the best way to do jetty - but Tomcat deployers probably dont want to pay for downloading jetty.

Again I would like to see jetty as a seperate plugin, optional for download.

Rob Atkinson

Justin Deoliveira wrote:

Maven is a good idea, but for a release I dont think users really want to run a maven build as part of downloading geoservers. However I would love to see maven used for geoserver build and release management though.

-Justin

Davis Ford wrote:

Chris -- just a thought..but if you move to a maven style build, then
maybe you don't have to distribute most of the jars, but can let maven
download them?

On 12/21/05, Chris Holmes <cholmes@anonymised.com> wrote:

Ok, so I just downloaded GeoServer RC7, and was somewhat shocked to see
the size of the download. I know that this is a trivial issue for

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

20

I still think the one click installer is a wonderful idea (so be it,
only for windows). It gives users the chance to try it out without doing
too much, or knowing too much about the project. And I believe it is the
most downloaded.
Maybe if it was an opt-out option.

It works just as well on Linux too...

Alex