[OOTB-addons] Review of Uploader-Plus - Input required

Axel Faust axel.faust at prodyna.com
Sun Mar 15 21:25:49 GMT 2015

Hello Paolo,

yes, unfortunately some override based on copy & modify is unavoidable. And it’s tricky to find the path with the least amount of it.
I have finished my personal attempt to modify uploader-plus to eliminate potential regressions in upload.post.js and provide a cleaner Share extension which is also de-activateable. There are two Surf modules now – one on auto-deploy for the infrastructure and one to be deployed manually for the injecting the modified uploaders into standard behavior. So far I’ve tested this on Enterprise 5.0 – branch as before: https://github.com/AFaust/uploader-plus/tree/customer-extensibility

Personally, I would like to avoid having two version-specific branches of any addon just for proper compatibility – even despite some of the disrupting / incompatible changes Alfresco introduces (e.g. the <facetable> model property).
In our addons, we do use version detection to switch on/off certain customizations. This includes a Freemarker method to optionally render part of Share components and client-side Share constant + comparison function. Unrelated to that, I included version information in my enhanced script environment for dynamic importing based on the Alfresco version, e.g . https://github.com/AFaust/alfresco-enhanced-script-environment/blob/master/framework/share/src/main/java/org/nabucco/alfresco/enhScriptEnv/share/util/VersionInfoContributor.java (https://github.com/AFaust/alfresco-enhanced-script-environment/blob/master/patch-modules/repository/src/main/webscripts/org/alfresco/slingshot/documentlibrary-v2/doclist.get.js and https://github.com/AFaust/alfresco-enhanced-script-environment/tree/master/patch-modules/repository/src/main/config/registeredScripts use this for version specific document list data web scripts)

Regarding compatibility with primary versions, it is impossible (based on http://dev.alfresco.com/resource/docs/java/org/alfresco/service/descriptor/DescriptorService.html and http://dev.alfresco.com/resource/docs/java/org/alfresco/service/descriptor/Descriptor.html#getVersionNumber) to distinguish between 5.0.a/b/c etc., so I would limit it to the latest Community Edition. You can theoretically support multiple Enterprise versions (main release and service pack) based on the version info from the DescriptorService.

Alfresco Enterprise should not have bug fixes for the core libraries that are not eventually merged into the publicly available code base. Anything else would introduce major overhead / maintenance nightmares for Alfresco engineers themselves. Any patch already merged into Community should be unproblematic to copy into an addon to be installed into an earlier version of Community.
Now unmerged patches may be a different matter altogether. Personally, I consider any patches to the core libraries (those that are available under LGPL) to be governed by the same terms – but unless you are a partner / Enterprise customer, you’d not have access to them and could not include them in an addon.


Von: OOTB-addons [mailto:ootb-addons-bounces at xtreamlab.net] Im Auftrag von Paolo Predonzani
Gesendet: Freitag, 13. März 2015 22:10
An: ootb-addons at xtreamlab.net
Betreff: [OOTB-addons] Review of Uploader-Plus - Input required

Hi Axel,
Thanks for reviewing uploader-plus and for highlighting points that can be improved.
As Angel says, clean separation between core and extension is difficult. There are very few extension points in the standard uploader's code, so my only option in many cases has been to "override, copy and modify" the existing methods. This means the code is subject to regressions and, as new versions of Alfresco are released, things are going to be more difficult.

Some ideas on which I'd like your opinion:
Currently uploader-plus has one code base that covers all 4.2.x and 5.0.x versions. When 5.0.x came out I struggled a bit but managed to stay compatible with both. The solution is not pretty, some methods are overridden for one version, others for the other version.
If this approach becomes too hard, I can split the code base in two: one branch just for 4.2.x and one just for 5.0.x.
Or I could create two sets of files and use version detection to chose which one to use, i.e.
if (alfresco.version >= 5) { use these set of overrides} else { use this other set of overrides }
What do you think?

The other question is compatibility within a primary version. 5.0.a, 5.0.b, 5.0.c had differences, but should I attempt to stay compatible with all? Or new features and improvements of the plugin should address only the latest version? After all, if some user is happy to use an old minor version of Alfresco, he should be happy to use an old minor version of the plugin too. Hmmm, maybe. What's your experience?

The last point is community vs enterprise. Since the "override, copy and modify" approach has the word "copy" in it, I suspect there is a problem with licensing if Alfresco enterprise has a bug fix not released in Alfresco community.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-addons/attachments/20150315/089d1cc4/attachment.html>

More information about the OOTB-addons mailing list