[Geoserver-devel] Large commits in community area: spatialite

Hi,
tonight a large batch of native libraries was committed to the community/spatialite section:

/devel/git-gs/src/community/spatialite/lib$ du -csh *
50M native
50M total

This is unprecedented, I think we got mad at people for less than 1MB binary commits
in svn in the past.

Now, I understand Jose is new to GeoServer development so I’m going to give him some
slack, but those libraries have to go, and please avoid any large file commit to svn in
the future.
All types of libraries, pure java or should be handled by maven artifacts,
which are going to be downloaded only by who works on the module.

I think SWT can be an example, afaik the jar distributed on the maven repos contain
the native libraries for all the target OS (which in this case are small enough to stick
all of them in a single jar).

In this case 50MB of library are too much for a single jar, I guess they could be split
by OS with profiles activating based on the current operating system?

Btw, I think Jose will need rights to upload these jars either to the osgeo or opengeo
repositories.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


In an attempt to prevent this from occurring again in the future i just updated the developer guide to include some basic commit guidelines for the project:

http://docs.geoserver.org/latest/en/developer/policies/comitting.html#commit-guidelines

Please add anything you deem appropriate.

-Justin

On Fri, Jun 17, 2011 at 1:11 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
tonight a large batch of native libraries was committed to the community/spatialite section:

/devel/git-gs/src/community/spatialite/lib$ du -csh *
50M native
50M total

This is unprecedented, I think we got mad at people for less than 1MB binary commits
in svn in the past.

Now, I understand Jose is new to GeoServer development so I’m going to give him some
slack, but those libraries have to go, and please avoid any large file commit to svn in
the future.
All types of libraries, pure java or should be handled by maven artifacts,
which are going to be downloaded only by who works on the module.

I think SWT can be an example, afaik the jar distributed on the maven repos contain
the native libraries for all the target OS (which in this case are small enough to stick
all of them in a single jar).

In this case 50MB of library are too much for a single jar, I guess they could be split
by OS with profiles activating based on the current operating system?

Btw, I think Jose will need rights to upload these jars either to the osgeo or opengeo
repositories.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



EditLive Enterprise is the world’s most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev


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 Fri, Jun 17, 2011 at 3:44 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

In an attempt to prevent this from occurring again in the future i just
updated the developer guide to include some basic commit guidelines for the
project:

http://docs.geoserver.org/latest/en/developer/policies/comitting.html#commit-guidelines

Please add anything you deem appropriate.

Thank you!
It seem Jose still haven't removed those files, nor he replied this mail.

Anybody has his mail?
Shall we just go ahead and remove the files? However if Jose puts the back
the situation will get even worse for git users (as you get that commit, like
it or not, since git downloads history, not just current status).

I looked around to see if there is any way to impose a hard file size
limit on commits,
but found none... that would have been the best solution.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Maybe you already heard about pre commit hooks in SVN where you can check project relevant content or general project rules :
Have a look at this : http://wordaligned.org/articles/a-subversion-pre-commit-hook

svnbook 1.4 “Create Hooks” : http://svnbook.red-bean.com/en/1.4/svn.reposadmin.create.html#svn.reposadmin.create.hooks

Properly that could be a way, to check commit messages or size of uploaded files or even checks for tab/space within files …

Cheers,
Frank

2011/6/18 Andrea Aime <andrea.aime@anonymised.com>

On Fri, Jun 17, 2011 at 3:44 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

In an attempt to prevent this from occurring again in the future i just
updated the developer guide to include some basic commit guidelines for the
project:

http://docs.geoserver.org/latest/en/developer/policies/comitting.html#commit-guidelines

Please add anything you deem appropriate.

Thank you!
It seem Jose still haven’t removed those files, nor he replied this mail.

Anybody has his mail?
Shall we just go ahead and remove the files? However if Jose puts the back
the situation will get even worse for git users (as you get that commit, like
it or not, since git downloads history, not just current status).

I looked around to see if there is any way to impose a hard file size
limit on commits,
but found none… that would have been the best solution.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



EditLive Enterprise is the world’s most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

I tried to send him a private email but i have yet to hear back. So let’s roll back the commit for now. Or at least remove all the binary libs.

On Sat, Jun 18, 2011 at 11:14 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jun 17, 2011 at 3:44 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

In an attempt to prevent this from occurring again in the future i just
updated the developer guide to include some basic commit guidelines for the
project:

http://docs.geoserver.org/latest/en/developer/policies/comitting.html#commit-guidelines

Please add anything you deem appropriate.

Thank you!
It seem Jose still haven’t removed those files, nor he replied this mail.

Anybody has his mail?
Shall we just go ahead and remove the files? However if Jose puts the back
the situation will get even worse for git users (as you get that commit, like
it or not, since git downloads history, not just current status).

I looked around to see if there is any way to impose a hard file size
limit on commits,
but found none… that would have been the best solution.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Hi Andrea, first at all, sorry for causing this trouble.
We should ask Justin before proceeding, on how to manage compiled version of dlls/libraries.

As you know we are working on an integration with spatialite. We have worked on compiling sqlite and spatialite to work on all platforms, and main job on that task is not related to output format itself (that is simply java and couple of files). Our main concern up to now was to detect how to get libraries working correctly.
Example: windows 64 bits was not working and we found way to compile files to make them working, but…here is the question: how to do when you should work with binaries that depends on third-party libraries ? (what do you prefer ? the binary files or the sources of that libraries that allow to get binaries ?, in that case, we should upload code, but…where ? do you have some folder exclusively assigned for that third-party libraries ?)

We are agree that it’s not the best upload that binaries to a source repository. Our mistake was not to ask before proceeding, and believe me that it’s my fault not to check with your team.

Now, how do you prefer to manage that ?
Your idea of getting jars for each OS is ok, but it will be still 50 MB of “data”, so we should move that jars to a repository folder . How can we get access to those repositories ? must we ask for permissions ?.

Also, reviewing developer commit notes, i should ask you. How do you believe it should be convinient to manage files on testing ? (we are working on unit-testing on spatialite output-format, so where you should place files for that ?. As you know, we should upload “generated output artifacts” in order to do comparations when running testings…test folder sounds “good”, but files are not going to be 1 or 2, probably will me a couple and i dont know how much space it would involve).

Again…I’m very sorry, and believe us that it is not going to happen twice.
Just let us know where to place repository files and then we will place all jarfiles inside. Also please comment us where to place testing artifacts.

Regards

Jose

Andrea Aime escribió:

On Sat, Jun 18, 2011 at 8:02 PM, Frank Gasdorf
<fgdrf@anonymised.com> wrote:

Maybe you already heard about pre commit hooks in SVN where you can check
project relevant content or general project rules :
Have a look at this
: http://wordaligned.org/articles/a-subversion-pre-commit-hook
svnbook 1.4 "Create Hooks" :
http://svnbook.red-bean.com/en/1.4/svn.reposadmin.create.html#svn.reposadmin.create.hooks

Right, just heard about them. The thing is, we don't have a svn that
we'd have control
over, it's managed by codehaus.
I guess we can ask if they can install a hook for us, that would be great.

Properly that could be a way, to check commit messages or size of uploaded
files or even checks for tab/space within files ..

Ah, the tabs thing would be nice too, at least for java files.

Thanks for the suggestion

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

On Sat, Jun 18, 2011 at 9:57 PM, Jose Macchi <jmacchi@anonymised.com> wrote:

Hi Andrea, first at all, sorry for causing this trouble.
We should ask Justin before proceeding, on how to manage compiled version of
dlls/libraries.

As you know we are working on an integration with spatialite. We have worked
on compiling sqlite and spatialite to work on all platforms, and main job on
that task is not related to output format itself (that is simply java and
couple of files). Our main concern up to now was to detect how to get
libraries working correctly.
Example: windows 64 bits was not working and we found way to compile files
to make them working, but..here is the question: how to do when you should
work with binaries that depends on third-party libraries ? (what do you
prefer ? the binary files or the sources of that libraries that allow to get
binaries ?, in that case, we should upload code, but...where ? do you have
some folder exclusively assigned for that third-party libraries ?)

I think you can follow up the imageio-ext example. The project provides
binary bundles that people can download per platform, plus installation
instructions.
In order to install the extension users have to install both the jar files
in GeoServer and the native libs somewhere the JVM can pick them
up (where that is, it's platform dependent)

We are agree that it's not the best upload that binaries to a source
repository. Our mistake was not to ask before proceeding, and believe me
that it's my fault not to check with your team.

Now, how do you prefer to manage that ?

First off, remove them from svn. Anyone working from a slow connection
is going to be in a world of pain if they try to checkout GeoServer.
Unfortunately anyone using "git svn" (like most core developers do) will have to
keep those 50MB around, as git keeps full history in the checkout.

Your idea of getting jars for each OS is ok, but it will be still 50 MB of
"data", so we should move that jars to a repository folder . How can we get
access to those repositories ? must we ask for permissions ?.

I guess the easiest approach is to follow the imageio-ext lead:
you just have to find some site that would host your files.
Sourceforge could be a hosting platform for the natives for example.

Also, reviewing developer commit notes, i should ask you. How do you believe
it should be convinient to manage files on testing ? (we are working on
unit-testing on spatialite output-format, so where you should place files
for that ?. As you know, we should upload "generated output artifacts" in
order to do comparations when running testings....test folder sounds "good",
but files are not going to be 1 or 2, probably will me a couple and i dont
know how much space it would involve).

We have many output formats, and we keep pre-generated outputs only
for the image cases in which it's almost impossible to test any other way
(and even in that case we're talking files that are no larger than 10-50KB).
If you are going to generate a database the way to test it is to connect
to it and make queries checking its contents.
The databases you create for testing should also promptly be removed once
the test is done, and normally they are saved in the /target directory because
if anything goes wrong the first "mvn clean install" will wipe them out anyways.

You should also use the existing test data to avoid adding extra weight.
The normal svn/build rocess is not the place for large high
volume/high computation
time tests, those have to be performed only manually on your own machine.

E.g., many of us have datasets ranging in the hundred of GB for volume tests,
but no one would even considering committing a MB of binary data to the repo
(people have been yelled at for a anything above 100KB in the last years, and
with good reason).

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Hi people…i were out of office all friday. Just today i was able to check mails. We should remove that, but we also need to define where to place binaries (inside jars, or in a repository, or…dont know. You would determine which is your preference on that).

Jar files for specific OS on a maven repository sounds good

so…let me know and we will proceed with that.
regards

jose

Justin Deoliveira escribió:

Hi Andrea,

Andrea Aime escribió:

  
Hi Andrea, first at all, sorry for causing this trouble.
We should ask Justin before proceeding, on how to manage compiled version of
dlls/libraries.

As you know we are working on an integration with spatialite. We have worked
on compiling sqlite and spatialite to work on all platforms, and main job on
that task is not related to output format itself (that is simply java and
couple of files). Our main concern up to now was to detect how to get
libraries working correctly.
Example: windows 64 bits was not working and we found way to compile files
to make them working, but..here is the question: how to do when you should
work with binaries that depends on third-party libraries ? (what do you
prefer ? the binary files or the sources of that libraries that allow to get
binaries ?, in that case, we should upload code, but...where ? do you have
some folder exclusively assigned for that third-party libraries ?)
    

I think you can follow up the imageio-ext example. The project provides
binary bundles that people can download per platform, plus installation
instructions.
In order to install the extension users have to install both the jar files
in GeoServer and the native libs somewhere the JVM can pick them
up (where that is, it's platform dependent)

  

great ! we will follow that “model” (to keep inline with your current way to manage it)


We are agree that it's not the best upload that binaries to a source
repository. Our mistake was not to ask before proceeding, and believe me
that it's my fault not to check with your team.

Now, how do you prefer to manage that ?
    

First off, remove them from svn. Anyone working from a slow connection
is going to be in a world of pain if they try to checkout GeoServer.
Unfortunately anyone using "git svn" (like most core developers do) will have to
keep those 50MB around, as git keeps full history in the checkout.

  

Done. We have removed native libraries.


Your idea of getting jars for each OS is ok, but it will be still 50 MB of
"data", so we should move that jars to a repository folder . How can we get
access to those repositories ? must we ask for permissions ?.
    

I guess the easiest approach is to follow the  imageio-ext lead:
you just have to find some site that would host your files.
Sourceforge could be a hosting platform for the natives for example.
  

About sourceforge, i’m agree to use it as a place where to place native/compiled files. Do you have currently any other place you usually use ?
We will use the imageio-ext example in order to get a similar schema on how you manage this cases on projects.

  
Also, reviewing developer commit notes, i should ask you. How do you believe
it should be convinient to manage files on testing ? (we are working on
unit-testing on spatialite output-format, so where you should place files
for that ?. As you know, we should upload "generated output artifacts" in
order to do comparations when running testings....test folder sounds "good",
but files are not going to be 1 or 2, probably will me a couple and i dont
know how much space it would involve).
    

We have many output formats, and we keep pre-generated outputs only
for the image cases in which it's almost impossible to test any other way
(and even in that case we're talking files that are no larger than 10-50KB).
If you are going to generate a database the way to test it is to connect
to it and make queries checking its contents.
The databases you create for testing should also promptly be removed once
the test is done, and normally they are saved in the /target directory because
if anything goes wrong the first "mvn clean install" will wipe them out anyways.

You should also use the existing test data to avoid adding extra weight.
The normal svn/build rocess is not the place for large high
volume/high computation
time tests, those have to be performed only manually on your own machine.
  

About testing data, i’m agree that it’s not nice to upload big files into SVN. In that case we can manage an initialization process when executing maven tests, that would generate testing databases for comparation using data located at data folder.
My question was related to let us know how do you manage that, and if you can clarify what is the way you currently manage that
If you have some documented guide or reference that defines it under geoserver environment, it will be welcomed.

E.g., many of us  have datasets ranging in the hundred of GB for volume tests,
but no one would even considering committing a MB of binary data to the repo
  

I understand this, and i’m totally agree.
Dont worry…we are not going to upload 1GB of testing data :-).
Data folder is where we would check for example information ? (so, we can use those example files in order to generate our own databases, without need to add more testing data).

(people have been yelled at for a anything above 100KB in the last years, and
 with good reason).
  

Main reason when you use a SVN is to have a complete, replicable and versionable way to allow developers/team to access easily artifacts related to development and project (that includes documentation, tests, databases, necessary binary files, like images,excels files if used, docs, etc etc etc).

This issue it’s simply a difference on criteria about how to proceed on project. Our mistake: We should ask before uploading.
We are open to work with different rules to our usual way, cause it’s not a problem, simply it’s a different way.

For us, a very good reason for uploading those type of files is related to allow developers -with different developed skills- to access easily to all necessary files to start to develop on a new platform/project/environment (it’s a tradeoff between make it easier for people to understand development environment vs. space at repository).

Ie: if someone need those binary files, he/she will have to download them from a place anyway - sourceforge, and ftp, a link, etc.
In order to let someone know where to get files you can:

  1. to make them available easily (since we dont have restrictions when working on our svn, it’s not a major problem), or
  2. to document clearly on a well-defined way where to get files, and to indicate people where they should read instructions for that
    Each way have pros and contras, and both are valid.

Anyway…as i mentioned, it’s simply a difference on criteria, and we should asked before proceeding. Our fault.
Team is now a warned and developers known that we cannot do the usual way we do.

Regards

Jose

On Sun, Jun 19, 2011 at 2:58 AM, Jose Macchi <jmacchi@anonymised.com> wrote:

I guess the easiest approach is to follow the imageio-ext lead:
you just have to find some site that would host your files.
Sourceforge could be a hosting platform for the natives for example.

About sourceforge, i'm agree to use it as a place where to place
native/compiled files. Do you have currently any other place you usually use
?

imageio-ext is here: http://java.net/projects/imageio-ext/
The native libraries are here:
http://java.net/projects/imageio-ext/downloads/directory/Releases/Dependencies/GDAL/NativeLibraries/1.7.3

About testing data, i'm agree that it's not nice to upload big files into
SVN. In that case we can manage an initialization process when executing
maven tests, that would generate testing databases for comparation using
data located at data folder.
My question was related to let us know how do you manage that, and if you
can clarify what is the way you currently manage that
If you have some documented guide or reference that defines it under
geoserver environment, it will be welcomed.

I don't think we have documentation on this.
I also pretty much explained what we do testing wise in my previous mail.
"manage" is a very generic term, can you provide an example of what is not
clear?

I understand this, and i'm totally agree.
Dont worry....we are not going to upload 1GB of testing data :-).
Data folder is where we would check for example information ? (so, we can
use those example files in order to generate our own databases, without need
to add more testing data).

The testing data set is here:
http://svn.codehaus.org/geoserver/trunk/src/main/src/test/java/org/geoserver/data/test/

The data is already available in the catalog during tests if you
extend the GeoServerTestSupport
class. The many property files are a clone of the official OGC test
data and are already
used by many modules, when doing tests try to use them, and if you
really cannot find
a data set that suits your need, you can create a new one, possibly
again as a property file,
possibly with only 5-10 features in it.

All tests that requires specific context, such as a database, a remote server,
a specific native library first check if the context is available, if
it is they run,
otherwise they exit immediately warning that the test was not run
because of lack of some necessary component.
Have a look at the tests in the wfsv extension module for example.

Main reason when you use a SVN is to have a complete, replicable and
versionable way to allow developers/team to access easily artifacts related
to development and project (that includes documentation, tests, databases,
necessary binary files, like images,excels files if used, docs, etc etc
etc).

Yep, I've seen places doing that in the past, the svn server eventually became
slow/un-manageable and people eventually drop out of that scheme.
It also works fine just in a mostly local development setup where everybody has
access to a fast connection to the server, and people can coordinate on who
works on this or that binary file (ever had a conflict on a binary
one? not pleasant).

GeoServer is developed across also all time zones (we just miss someone in
Hawaii I guess) so that kind of coordination is not possible, and not everybody
develops from a high speed connection (even those in western countries having
good connection at work will flip trying to download those 50MB
from a UMTS dongle on a train or over a airport Wifi)

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

What we do for Geotools app-schema test data and schema bundles is to
(1) package them into maven artifacts and then
(2) deploy them to the osgeo maven repository.

The advantage of using Maven artifacts is that they are downloaded only when needed and are cached on the build platform. Builds not using the artifacts do not get them.

To create the artifacts, I made pom-only modules that use maven-antrun-plugin to download the artifacts from a third-party and bundle them into jars:
http://svn.osgeo.org/geotools/trunk/modules/extension/app-schema/app-schema-packages
(See the submodules)

These modules are only build manually, never as part of the build. The third-party content never touches source control. You can achieve the same effect building your artifacts manually.

In my view, storing binary dependencies in source control is an established anti-pattern.

On 19/06/11 07:33, Jose Macchi wrote:

Hi people....i were out of office all friday. Just today i was able to check mails. We should remove that, but we also need to define where to place binaries (inside jars, or in a repository, or..dont know. You would determine which is your preference on that).

Jar files for specific OS on a maven repository sounds good

so...let me know and we will proceed with that.
regards

jose

Justin Deoliveira escribió:
I tried to send him a private email but i have yet to hear back. So let's roll back the commit for now. Or at least remove all the binary libs.

On Sat, Jun 18, 2011 at 11:14 AM, Andrea Aime<andrea.aime@anonymised.com<mailto:andrea.aime@anonymised.com>> wrote:
On Fri, Jun 17, 2011 at 3:44 PM, Justin Deoliveira<jdeolive@anonymised.com<mailto:jdeolive@anonymised.com>> wrote:

In an attempt to prevent this from occurring again in the future i just
updated the developer guide to include some basic commit guidelines for the
project:

http://docs.geoserver.org/latest/en/developer/policies/comitting.html#commit-guidelines

Please add anything you deem appropriate.

Thank you!
It seem Jose still haven't removed those files, nor he replied this mail.

Anybody has his mail?
Shall we just go ahead and remove the files? However if Jose puts the back
the situation will get even worse for git users (as you get that commit, like
it or not, since git downloads history, not just current status).

I looked around to see if there is any way to impose a hard file size
limit on commits,
but found none... that would have been the best solution.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

________________________________

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev

________________________________

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Native lib dependencies are tricky just for this reason. Another way to solve this would be just at packaging time. As Andrea states host the native libs somewhere external and when it comes time to build the extension at release time then we download the appropriate native libs just when we package up the extension. That still is a burden for whoever is doing the release but downloading 100M of libs of better than storing them in version control.

Regardless, Jose, for now I would not worry too much about this for now as this is still a community module. So if you want to just disable the tests so they don’t break the build, and just run them locally that is fine. This is more or less what we do with the spatialite datastore.

On Sun, Jun 19, 2011 at 8:24 PM, Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com wrote:

What we do for Geotools app-schema test data and schema bundles is to
(1) package them into maven artifacts and then
(2) deploy them to the osgeo maven repository.

The advantage of using Maven artifacts is that they are downloaded only when needed and are cached on the build platform. Builds not using the artifacts do not get them.

To create the artifacts, I made pom-only modules that use maven-antrun-plugin to download the artifacts from a third-party and bundle them into jars:
http://svn.osgeo.org/geotools/trunk/modules/extension/app-schema/app-schema-packages
(See the submodules)

These modules are only build manually, never as part of the build. The third-party content never touches source control. You can achieve the same effect building your artifacts manually.

In my view, storing binary dependencies in source control is an established anti-pattern.

On 19/06/11 07:33, Jose Macchi wrote:

Hi people…i were out of office all friday. Just today i was able to check mails. We should remove that, but we also need to define where to place binaries (inside jars, or in a repository, or…dont know. You would determine which is your preference on that).

Jar files for specific OS on a maven repository sounds good

so…let me know and we will proceed with that.
regards

jose

Justin Deoliveira escribió:
I tried to send him a private email but i have yet to hear back. So let’s roll back the commit for now. Or at least remove all the binary libs.

On Sat, Jun 18, 2011 at 11:14 AM, Andrea Aime<andrea.aime@anonymised.comsolutions.itmailto:[andrea.aime@anonymised.com](mailto:andrea.aime@anonymised.com)> wrote:
On Fri, Jun 17, 2011 at 3:44 PM, Justin Deoliveira<jdeolive@anonymised.comorgmailto:[jdeolive@anonymised.com796...org](mailto:jdeolive@anonymised.com)> wrote:

In an attempt to prevent this from occurring again in the future i just
updated the developer guide to include some basic commit guidelines for the
project:

http://docs.geoserver.org/latest/en/developer/policies/comitting.html#commit-guidelines

Please add anything you deem appropriate.

Thank you!
It seem Jose still haven’t removed those files, nor he replied this mail.

Anybody has his mail?
Shall we just go ahead and remove the files? However if Jose puts the back
the situation will get even worse for git users (as you get that commit, like
it or not, since git downloads history, not just current status).

I looked around to see if there is any way to impose a hard file size
limit on commits,
but found none… that would have been the best solution.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.



EditLive Enterprise is the world’s most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev



Geoserver-devel mailing list

Geoserver-devel@anonymised.comsourceforge.netmailto:[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)

https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Great
Since task is done by a team, we need to coordinate “rules & criteria” when adding native libraries, or documents, or testing files, or whatever. While team work, i can organize this kind of information (so we can progress on both sides).

I will be placing all this information on a doc, then you will decide if it’s useful to publish it on community or not (internally i will do it anyway cause everytime we add some person to work on this kind of stuff i would like to match opengeo criteria, and avoid causing troubles)

thanks for help and information you provide !..(this will help to organize team).

regards

On Mon, Jun 20, 2011 at 5:40 PM, Jose Macchi <jmacchi@anonymised.com> wrote:

ok, just asking. Since task is done by a team, we need to coordinate "rules
& criteria" when adding native libraries, or documents, or testing files, or
whatever.

I will be placing all this information on a doc, then you will decide if
it's useful to publish it on community or not (internally i will do it
anyway cause everytime we add some person to work on this kind of stuff i
would like to match opengeo criteria, and avoid causing troubles)

It's actually GeoServer criteria, OpenGeo is one of the companies
contributing to the project, but the project management committee
has a number of people from various organizations.

Ah, if you want to add user level documentation for the plugin you can do
so here:
http://svn.codehaus.org/geoserver/trunk/doc/en/user/source/community/

If you want to extend/clarify the developer guide it's here instead:

http://svn.codehaus.org/geoserver/trunk/doc/en/developer/source/

Both use the Sphinx document generator, we have a brief introduction
here:
http://docs.geoserver.org/latest/en/docguide/

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Thanks a lot Andrea !!!!...

Andrea Aime escribió:

On Mon, Jun 20, 2011 at 5:40 PM, Jose Macchi <jmacchi@anonymised.com> wrote:
  

ok, just asking. Since task is done by a team, we need to coordinate "rules
& criteria" when adding native libraries, or documents, or testing files, or
whatever.

I will be placing all this information on a doc, then you will decide if
it's useful to publish it on community or not (internally i will do it
anyway cause everytime we add some person to work on this kind of stuff i
would like to match opengeo criteria, and avoid causing troubles)
    
It's actually GeoServer criteria, OpenGeo is one of the companies
contributing to the project, but the project management committee
has a number of people from various organizations.

Ah, if you want to add user level documentation for the plugin you can do
so here:
http://svn.codehaus.org/geoserver/trunk/doc/en/user/source/community/

If you want to extend/clarify the developer guide it's here instead:

http://svn.codehaus.org/geoserver/trunk/doc/en/developer/source/

Both use the Sphinx document generator, we have a brief introduction
here:
http://docs.geoserver.org/latest/en/docguide/

Cheers
Andrea