[OOTB-hive] Call for contribution: Let's build a comprehensive module of bug patches!
a.steffan at contentreich.de
Fri Aug 26 08:56:29 BST 2016
I really appreciate a bugfix extension, but this script "import" things
raises a few worries here.
I fully agree that the "import tag" is terrible due to it's "IDE
breaking nature". However I consider this one of the few things which
really has to be addressed by Alfresco. I for one would never build any
code relying on this fix applied as a "community patch".
I may have missed it, but are there any policies around the bugfix effort?
Will all things "carried around" be applied no matter what?
I mean pretty much every extension has issues, and I expect this one to
be no exception. If this spirals out of control, one may be better off
not applying it at all.
On 08/25/2016 04:55 PM, Axel Faust wrote:
> As the original reporter of that script import API enhancement I am
> glad this appears still relevant to people, although I don't consider
> this an actual bug to be patched. A nuisance, yes, which is why I
> prepared that contribution all these years back and which is also why
> I included AMD-style module loading in my Nashorn engine module.
> I have updated my example project
> https://github.com/AFaust/irc-alfresco-patching-samples which I had
> started after our discussions yesterday to add demonstrations /
> support of the following concepts:
> - support for configuring Share placeholder values via
> share-global.properties files
> - support for configuring Share Log4J logging via module-based
> log4j.properties files
> - support for configuring Share addons in a method consistent with
> Repository-tier modules (in a structure like alfresco/module/xyz/)
> I have also added a couple of Surf / Aikau related patches for testing
> purposes (all the above has been tested on 5.1).
> Additionally, I have included the slf4j-log4j bridge JAR in my Share
> module so I don't have to use neither the awkward Commons Logging API
> nor any other specific implementation API (I prefer the abstraction
> SLF4J provides).
> @Lutz: Please have a look if you consider the three "support"-concepts
> I listed as acceptable for a patch module. Opposed to what we
> discussed in IRC, I have not yet created PRs for any of this to avoid
> pushing things some people might feel do not belong in such a patch
> @all: During the discussions on Wednesday we also touched on the
> possibility that such a consolidated patch addon might be put under an
> official "Order of the Bee" umbrella, i.e. the main project repository
> could be placed inside the GitHub OrderOfTheBee organisation. At least
> I consider all the current activities a part of "figuring out how such
> a consolidated patch module should work / be maintained".
> 2016-08-25 15:52 GMT+02:00 Lutz Horn <lutz.horn at ecm4u.de
> <mailto:lutz.horn at ecm4u.de>>:
> Hi Benjamin,
> I've added a GitHub issue for your proposal:
> Lutz Horn
> ecm4u GmbH
> Hölderlinplatz 2b
> 70193 Stuttgart
> t: +49 (711) 912 775-73 <tel:%2B49%20%28711%29%20912%20775-73>
> f: +49 (711) 912 775-80 <tel:%2B49%20%28711%29%20912%20775-80>
> ecm4u GmbH - die IT in Prozessen einfach sinnvoll nutzen
> Handelsregister: Amtsgericht Stuttgart HRB 734004,
> Geschäftsführung: Heiko Robert
> OOTB-hive mailing list
> OOTB-hive at xtreamlab.net <mailto:OOTB-hive at xtreamlab.net>
> OOTB-hive mailing list
> OOTB-hive at xtreamlab.net
Achter Billing 14
M: +49 160 4694826
T: +49 40 23943542
F: +49 40 23943542
Contentreich : Alfresco ECM, Clojure, Groovy und WordPress - aus Spaß und für Geld
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OOTB-hive