Hi, I have one more alternative version of patch which deals with that problem. In summary: * new class BugtrackerFactory is introduced which deals with bugtracker instance creation & initialization. (Kind of what an unused method Daemon::get_new_bugtracker was doing). * Daemon doesn't create concrete bugtracker instances itself - delegates to BugtrackerFactory * An unused get_new_bugtracker method was removed (this was duplicated method anyway - probably used to fit in read_configuration where BugtrackerFactory now is called).
+ Having this intermediate factory allows us to do the relevant library paths addition before Bugzilla module is loaded. (No BEGIN blocks are used). * I haven't yet payed much attention to any other bugtrackers than Bugzilla - their initialization should be equivalent to what it used to be till now. (I.e. - library paths inclusion is not moved to BugtrackerFactory for RequestTracker yet). Regards, Yavor 2011/3/14 Yavor Nikolov <[email protected]> > Hi, > > 2011/3/14 Thorsten Schöning <[email protected]> > >> Guten Tag Kristis Makris, >> am Montag, 14. März 2011 um 01:17 schrieben Sie: >> >> > I like this patch better than BEGIN blocks, >> >> In general in my opinion BEGIN blocks für compile time initialization >> are easier to understand and read and it's more clear that they are >> just executed at compile time. use lib seems to be a special case, >> though, because one can add to @INC during runtime, but not use the >> proper "use lib" as a full replacerment. >> > > Kristis, are you against to have library initialization in BEGIN block or > you're against the ugly design after my patch? I admit it's a bit messy (we > have kind of circular dependency between Daemon::Daemon and > Daemon::Bugzilla) - it's just an quick proof of concept experiment. Maybe it > would be better to move configuration options into separate shared singleton > Config module and whoever needs some configuration parameter may refer to > it. > > Or all that inclusion of additional library paths could be moved to some > other module which should do it's job BEFORE Scmbug::Bugzilla module is > loaded. > > Actually - the patch which I uploaded here without the BEGIN block - maybe > would work fine if we don't directly refer to any of the modules in > <bugzilla root>/lib. (This should be the most common scenario in fact > > >> >> > though I don't understand >> > why it is necessary to use catdir. >> >> Bugzilla/lib will work with Windows, but using catdir and getting >> Bugzilla\lib looks much cleaner to me, too. File::Spec should be >> available in any perl distribution. >> > > Yes, File::Spec seems to be a standard Perl module (you get it during perl > compilation). catdir is supposed to be portable while I'm not sure how would > " . /lib" concatenation behave on some more exotic platform. > > Actually - after chdir( $bugzilla_root ); we can just use relative paths. > E.g.: > use lib qw(. lib); > > Regards, > Yavor > > >> >> Mit freundlichen Grüßen, >> >> Thorsten Schöning >> >> -- >> Thorsten Schöning >> AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig >> >> Telefon: Potsdam: <0331-743881-0>0331-743881-0 >> E-Mail: [email protected] >> Web: http://www.am-soft.de >> >> AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam >> Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow >> >> _______________________________________________ >> scmbug-users mailing list >> [email protected] >> http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users >> > > Regards, > Yavor >
scmbug_bugzilla_use_lib_with_Factory.patch.gz
Description: GNU Zip compressed data
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
