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
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
<[email protected]> 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<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>> wrote:
On Fri, Jun 17, 2011 at 3:44 PM, Justin
Deoliveira<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>> 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
[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Ben Caradoc-Davies <[email protected]>
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.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
