Forum OpenACS Development: Re: Towards OpenACS 5.9

39: Re: Towards OpenACS 5.9 (response to 38)
Posted by Gustaf Neumann on
Just to keep you updated: it turned out that debian packaging become more tedious than in the past. The original goal was to provide a Debian package more or less with stock OpenACS 5.9.0. Hector was starting with this work, but several obstacles appeared. One problem area is the debian conformity checker, which becomes more and pickier. Some of the complaints could be addressed quickly, others are more complicated.

For example, just recently, the checker complains about minified .js files, which are not regarded as source code anymore. So we have to get rid of all minified files in the debian distro (and all references to it in the source). This affects mostly the rich-text editors. It looks to me as if the best solution would be to pull out the editors from acs-core and to make it own packages, which can be installed via "install from repository" in the future (... but that will require same refactoring).

Another problem are is the aolserver package in debian, which is in a very old state, but the the debian maintainers are quite unresponsive concerning bug reports. Hector has started to look into the details, how to getting a NaviServer package into debian (there is some work from the people at we can build upon). But in any case, the cycles are rather slow.

Short message: we are on it, we are getting closer to a release.

40: Re: Towards OpenACS 5.9 (response to 39)
Posted by Michael Aram on

+1 for a stronger modularization with respect to external libraries.

As I have suggested earlier, I sympathize with the idea of having dedicated OpenACS packages for external JS libraries such as jQuery, YUI2, Bootstrap, etc...

These could follow a naming conventions similar to acs-* such as e.g. vendor-*, external-*.

41: Re: Towards OpenACS 5.9 (response to 40)
Posted by Gustaf Neumann on
The actual problem with debian packaging just concerns core, since the js libraries for the richtext editors are embedded in acs-templating. In order to move these out, a better interface than we have now would be desirable, that addresses the needs of the currently used rich-text editors. This might be a goal for OpenACS 5.9.1.

But certainly, better approaches than ajaxhelper to handle complex js frameworks like bootstrap/yui/ext/... etc are as well needed, but that might be candidates for theming packages, since mixing theses is though...