On 1/10/11 4:02 AM, Bruno Binet wrote: > Thanks Tim. > So I forked JSTools in the Camptocamp github area: > https://github.com/camptocamp/jstools > By using this fork, we can now specify exclude regexp patterns. To use > exclude patterns, you'd have to add it in the exclude section of > jsbuild config file and make it start with the pattern "r:" (so that > it will be read as regexp). > So to exclude all OpenLayers dependencies, we need to exclude r:OpenLayers/.* > > Would it work for you?
Thanks Bruno. What do you think about handling simple directory exclusions? I added similar support to the OpenLayers build tools a while ago: http://trac.osgeo.org/openlayers/changeset/10816/trunk/openlayers/tools Basically, any time a given source path starts with a string given in the excludes list, the source is not included. I know regex handling adds more flexibility, but I also think there is value in handling the simplest case first. > I've also created ticket http://trac.geoext.org/ticket/391 which adds > @include to all OpenLayers dependencies. As stated in the ticket, I > was not sure about the dependencies to include when concerning > OpenLayers formats or protocol. Currently, I have included both the > format *and* its default version. For example, for > data/WMSCapabilitiesReader.js, I have added both @include > OpenLayers/Format/WMSCapabilities.js and @include > OpenLayers/Format/WMSCapabilities/v1_1_1.js. But we could also choose > to not include version specific formats so that if the default version > is not used, we won't include unneeded javascript in the build. In > this case, the developer will always have to @include the required > version by himself. I'm sure there are other ways to look at it, but here's what I'm thinking right now: if we are very "inclusive" in specifying our dependencies (pull in more than what is needed) we require app developers to maintain build configuration files with "exclude" sections. Alternatively, if we are conservative in how we declare dependencies, we require app developers to maintain dependency lists in separate build profiles or in their application sources. I like the idea of being able to dispense with separate build configuration files. Perhaps this seems unfeasible, but I'd rather maintain dependency declarations in the source code. I think the "exclude" convention is a bit awkward - and eventually I'd like to be able to only have @require comments in source files. Hard to say though. If we're liberal in what is included, we make it easy for people who don't know what they really need to get it all (more than what they need). If we're conservative, we force people to learn a bit about what they really need. In the case of versioned parsers, as long as decent exceptions are thrown, I don't think it takes that much effort to figure out what is missing. > The patch is now in review. Please tell me your thoughts on this, and > I will update the patch accordingly. > > Note that while iterating over OpenLayers dependencies, I also > commited some missing dependencies to GeoExt.MapPanel, for example > when using GeoExt.MapPanel.guess() or testing "instanceof > GeoExt.MapPanel". Do you think we should rather avoid these > dependencies by testing GeoExt.MapPanel existence before using it? Yeah, I'd rather see us write code that doesn't unnecessarily increase dependencies. Tim > Bruno > > > On 4 January 2011 19:40, Tim Schaub<[email protected]> wrote: >> Sounds great to me. >> >> I'm working on an alternate build tool that will work with the same >> convention (allowing dependencies from multiple "packages"). >> >> Please fork away and run with it. >> >> Tim >> >> On 1/4/11 2:18 AM, Bruno Binet wrote: >>> Hi, >>> >>> Here at Camptocamp, we have started to update JSTools (jsbuild) so >>> that it can build javascript files while excluding paths that match a >>> regexp. This will allow us to add @requires/@include to openlayers >>> dependencies while still being able to build GeoExt as a standalone >>> lib (by using the pattern OpenLayers/.* in the exclude section). >>> >>> If you agree, we could fork JSTools github project in our Camptocamp >>> github area and maintain it. A new version of JSTools should also be >>> published on Pypi (and btw there is no JSTools package on Pypi >>> anymore). >>> >>> If you agree on all this, I will be happy to create a ticket and >>> provide a patch to update GeoExt with @include/@requires to OpenLayers >>> dependencies in all javascript files. >>> >>> Cheers, >>> >> >> >> -- >> Tim Schaub >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://www.geoext.org/cgi-bin/mailman/listinfo/dev >> > > > -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. _______________________________________________ Dev mailing list [email protected] http://www.geoext.org/cgi-bin/mailman/listinfo/dev
