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<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@geo-**
>> solutions.it <[email protected]><mailto:andrea.**
>> [email protected] <[email protected]>>> wrote:
>> On Fri, Jun 17, 2011 at 3:44 PM, Justin
>> Deoliveira<jdeolive@opengeo.**org<[email protected]>
>> <mailto:jdeolive@opengeo.**org <[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<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://geo-solutions.blogspot.com/>
>> http://www.youtube.com/user/**GeoSolutionsIT<http://www.youtube.com/user/GeoSolutionsIT>
>> http://www.linkedin.com/in/**andreaaime<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 <http://p.sf.net/sfu/ephox-dev2dev>
>>
>>
>>
>> ______________________________**__
>>
>> ______________________________**_________________
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.**sourceforge.net<[email protected]>
>> <mailto:Geoserv**[email protected]<[email protected]>
>> **>
>>
>> https://lists.sourceforge.net/**lists/listinfo/geoserver-devel<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
