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.
-- 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 >>> >> >
