Actually, I was thinking about this autoloads script for an app as it's done with eZP. It could be part of the ezcBase as an independent script. My point was to challenge the ezpublish strategy and see how to integrate it into ezcBase. By the way, I understand the point to normalize that for a whole environment (if I correctly get it) and to follow a policy such as Debian's.
I guess PHP is still the best option for this, but I cannot find a link between the files and the classes (as packages in Java) that can easily do the trick. If we can do that, and that's my next idea, we can purpose some easy extension mechanism using PHP's Reflection or replacing it, following our needs. Max 2010/11/24 Henri Bergius <ber...@apache.org> > On Wed, Nov 24, 2010 at 11:43 AM, Ole Marius Smestad <o...@ez.no> wrote: > > For production environments it makes sense, and we have been toying with > the idea of adopting the scripts to also create a similar list, > > which could work with components. > > In regular situations you probably need two setups: > > * Production: Zeta Components and other classes coming from PEAR or > native packages (I'd love to see Zeta in Debian as soon as there is an > official Apache release) > * Development: Zeta Components and other classes coming from various > Git/SVN checkouts > > The paths are likely to be quite different in these two scenarios. > > For production setups the relevant Debian policies are quite > interesting. I recently packaged OpenPSA (a Midgard-based business > management suite) to Debian and the policies made things quite clear: > http://webapps-common.alioth.debian.org/draft-php/html/ > http://webapps-common.alioth.debian.org/draft/html/ > > > Ole Marius > > /Henri > > -- > Henri Bergius > Motorcycle Adventures and Free Software > http://bergie.iki.fi/ > > Skype: henribergius > Jabber: henri.berg...@gmail.com > Microblog: http://www.qaiku.com/home/bergie/ >