On Friday, March 18, 2011, Bruno Binet <[email protected]> wrote: > More than 2 months later... ;) > > On 10 January 2011 19:32, Tim Schaub <[email protected]> wrote: >> 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. > > FYI, I have just pushed a new JSTools 0.2 release on pypi with support > for handling both simple directory > exclusions and regexp exclusions. > > Next step is http://trac.geoext.org/ticket/391 > >>> 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. > > > Agreed. > About the choice of being either "conservative" (pull in only what is > obsolutely needed) or "liberal" (pull in more than what is needed), > I'd rather choose the "conservative" way since custom builds are > targeted to advanced users so I think it does not matter that much to > force people to learn a bit about what they really need. > > What does others think about it?
I like the conservative approach much better. And I think this is also the approach we agreed on when discussing during the OL code sprint. -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : [email protected] http://www.camptocamp.com _______________________________________________ Dev mailing list [email protected] http://www.geoext.org/cgi-bin/mailman/listinfo/dev
