On 5/26/10 8:32 AM, David Winslow wrote: > Not that hard; Maven handles artifacts of type ZIP just fine, and > there's a one-line command to publish an artifact to a repo even if the > project that published it isn't Maven-ized. It would be a bit more > complicated to redo the build for the geonode client stuff in terms of > Maven (needed to at least fetch those dependencies) but still pretty > doable. However, this means we would want to set up nightly deployments > or something if we intend to keep relying on trunk features. I don't > see that as a drawback really, but it is worth mentioning. >
Though it will likely lead to a couple more headaches when someone else breaks the underlying builds I think I see it as a positive. Should help the stability of the underlying projects and also identify changes that may affect GeoNode much earlier. > -- > David Winslow > OpenGeo - http://opengeo.org/ > > On 05/26/2010 11:25 AM, Andreas Hocevar wrote: >> Another thought related to this: how hard would it be to build Maven >> artifacts for OpenLayers, GeoExt and gxp? Then we would not need any >> svn:externals at all (at least for the javascript stuff). >> >> Ah yes, and sorry if this sounds stupid. I neither have much experience with >> Maven nor with git at this point. >> >> Regards, >> Andreas. >> >> On May 26, 2010, at 17:15 , David Winslow wrote: >> >> >>> Just a note: we don't actually modify code in GeoServer and GeoNetwork, we >>> simply pull in pre-built artifacts (from OpenGeo's Maven repository for >>> GeoServer, and from an ad-hoc HTTP server for GeoNetwork) and add a couple >>> of extensions to each. We could (should?) avoid cloning these into git. >>> >>> -- >>> David Winslow >>> OpenGeo - http://opengeo.org/ >>> >>> On 05/25/2010 06:49 PM, Ariel Nunez wrote: >>> >>>> Thanks for pushing this up in the queue David. >>>> >>>> >>>> 2 - We mirror all our SVN externals so we can use git submodules to do the >>>> same thing. >>>> Pros - slightly better integration than braid on the client end >>>> (checkout consists of "install git, >>>> git clone, git submodule update --init";) >>>> Cons - maintaining git clones of svn projects, two-tier process to >>>> push changes back >>>> >>>> I like this option a lot, we are using outside dependencies and the >>>> submodule step makes this crystal clear. >>>> >>>> From my conversation with David on IRC, the projects are the following: >>>> { >>>> geoext (we follow trunk) >>>> openlayers (we follow trunk) >>>> geoserver ( we modify ) >>>> geonetwork (we modify) >>>> ext (we follow trunk) >>>> gsconfig.py (we follow trunk) >>>> } >>>> >>>> The idea would be to setup git forks for those repos under the geonode git >>>> account, like this: >>>> github.com/geonode/geoext >>>> github.com/geonode/openlayers >>>> github.com/geonode/geoserver >>>> github.com/geonode/geonetwork >>>> github.com/geonode/ext >>>> github.com/geonode/gsconfig.py >>>> >>>> And put git submodules in this main repo: >>>> github.com/geonode/geonode >>>> >>>> If anybody does not like the fact that we depend on Github, we always have >>>> the option to setup: >>>> git.geonode.org >>>> >>>> 3 - We commit all SVN externals directly to the git repository, kind of >>>> like svn vendor branches. >>>> Pros - even better integration than git submodule, when you checkout >>>> the project you get >>>> everything. >>>> Cons - it takes a bit of digging in the repository to extract diffs >>>> to submit upstream patches, and >>>> even bringing in updates is kind of a pain. >>>> >>>> It is true this option may be the simplest for new users but I don't like >>>> the fact that patches are against "Geonode's version of X project" instead >>>> of the actual project. "Explicit is better than implicit", so #2 is still >>>> my favorite. >>>> >>>> But I'm open to alternatives/arguments. However, let's try and be >>>> git-friendly by, say, Friday next week? I'm not aware of a hard deadline >>>> but at the rate this discussion's been going we'll never get converted. >>>> >>>> +1 The sooner the better. >>>> >>>> Ariel >>>> >>> >> >
