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

[Paolo Predonzani]

Hi Axel,
Thanks, I'll look into your changes to the code and the other examples you
mention.

As to enterprise patches to core file, I guess you're right but we'll
probably have to read the license terms carefully.

Just from a technical point of view, in your review you mention a
regression, due to uploader-plus, from an enterprise patch. If you have
specific examples in mind, what were the affected files/methods?

Regards

Paolo




On 15 March 2015 at 22:25, Axel Faust <axel.faust at prodyna.com> wrote:

>  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.
>
>
>
> Regards
>
> Axel
>
>
>
> *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.
>
>
>
> Regards
>
>
>
> Paolo
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-addons/attachments/20150316/5dde42cf/attachment-0001.html>