cancel
Showing results for 
Search instead for 
Did you mean: 

Global Virtual Hack-a-thon - Spring 2019

kgastaldo
Star Collaborator
Star Collaborator

These are project ideas and teams for the 2019 Spring Global Virtual Hack-a-thon.

The hack-a-thon is scheduled for Friday, May 10th, 2019.

Instructions

For people with a project idea

For each project, you should consider addressing the following:

  • The idea owner(s)
  • A brief description
  • Any prep work for the project, such as developer tools or skills participants should understand

We encourage you to keep your project idea short and provide any additional details in separate document or blog post within the Collaborate space. This may also allow you to coordinate with potential team members via the comments there without being mixed in with any discussions on this page.

For people looking to join a project

Please feel free to add your name to any project(s) you are interested in participating. Don't hesitate to add your name to multiple projects if you are considering multiple at this point. We encourage you to use this platform to contact the owner of an idea to discuss any details you are unsure about or even improve upon the idea.

Apart from any plans you make with the owner of an idea, you are not bound to actually participate in the project you indicated here. When you join the hack-a-thon on the day of the event you can check with other project teams and join a different project, if that turns out to be a better fit for you.

For everyone

The global virtual hack-a-thon is as much a social event as it is a coding one. This means a lot of the attendees for this event often use it to exchange ideas and discuss other matters in the general Alfresco context. To do this, everyone that attends the global virtual hack-a-thon should be prepared to join any of the commonly used communication channels for this event. In the past the main tools have been the IRC chat #alfresco (via chat.alfresco.com or a desktop client), Zoom and Google Hangouts. This year we also have an #alfresco channel on Discord.

After the event has come to an end, we encourage everyone that worked on a specific project idea to update the listing on this page with an overview of the project team and a link / reference to the results of the project (e.g. a GitHub repository, document or blog post in this space).

Projects

<placeholder for project title>

Idea owner: 

Description: 

Prep work: 

Interested parties:

  • You?
  • Or you, ma'm?
  • Maybe you, sir?

Content Services

Prepare release 2.0 of Dynamic Extensions for Alfresco

Idea owner: Daan Kerkhofs

Description: Preparing the release of version 2.0 Dynamic Extensions for Alfresco. This release adds support for 6.0 and 6.1.

Prep work: Build the current master

Interested parties: Daan Kerkhofs Toon Geens

Source Code: GitHub - xenit-eu/dynamic-extensions-for-alfresco: Add OSGi based hot-deploy functionality and Sprin...

Results:

Build Community image(s) to split ImageMagick / LibreOffice / PDF transformers from Repository

Idea ownerAxel Faust

Description: The core of the Alfresco Repository already contains the necessary base classes / support (e.g. RemoteTransformerClient) for Alfresco 6.x to call transformers on a remote host using HTTP. While Alfresco Enterprise 6.0 did provide separate Docker images for running the ImageMagick / LibreOffice / PDF transformations on separate containers (potentially on separate hosts), this was left out of the open core. I see no valid reason for this artificial feature distinction between Community and Enterprise, and it should be quite simple to build a trivial HTTP server and Community image(s) to support the same kind of feature for Community.

This project would not be directly linked to the new asynch transformation queue feature in Alfresco 6.1 (also only available for Enterprise), but could be a stepping stone into providing a similar asynch transformation feature for Community in that version (and all subsequent versions) as well.

Interested parties: Jan Vonka

Source code: 

Take another crack at providing Alfresco base image improvements

Idea ownerAxel Faust

Description: At the Alfresco DevCon 2019 hackathon, a team worked on a project named "Community Reborn" which was to focus on potential improvements, documentations, change requests etc. around the Alfresco-provided ecosystem of Alfresco Docker images. This project would aim to continue on some of the ideas discussed and - in some ways evaluated / attempted - during the DevCon hackathon.

  • Find ways to reduze the size of the base images and provide PRs for Alfresco to incorporate the changes (the first attempt met a roadblock due to legal reasons / angst, but maybe a different approach by using a pre-built JRE (instead of JDK) provided by AdoptOpenJDK would allay the legal concerns)
  • Suggest and prepare PR for a more flexible image configuration approach, using granular environment properties instead of one massive JAVA_OPTS, which would make Docker Compose files and other orchestration methods more maintainable and even allow to provide some default configuration in customer-specific Docker images without having to merge the massive JAVA_OPTS variable. E.g. environment variables with a special prefix (GLOBAL_*) could be processed by a small init script (similar to substituter.sh or entrypoint.sh already used in Share / Alfresco Content Application) and be set in alfresco-global.properties. This would also solve the major drawback of JAVA_OPTS: one can only specify / override any property which has been pre-defined by a default properties file, making JAVA_OPTS useless for composite or other forms of dynamic configuration properties.
  • (the idea of separate images + small HTTP server for remote transformations was already split into a separate project idea due to its scope)

Interested parties:

Source code / results:

Better Trash Management

Idea owner: Axel Faust

Description: Started in the virtual global hack-a-thon project of 2017, this project would continue work on a module for improved management of the trash can in Alfresco. In previous hack-a-thons, the focus was put mostly on making the backend work, since default behaviour and APIs of Alfresco provided an abysmal level of access to trashcan contents (even the new v1 ReST API is abysmal in that regard). In this iteration, work should focus on the user interface aspect. Though work in previous iterations has already resulted in a rudimentary Alfresco Share / Aikau interface, it would be perfectly fine for interested people to join the project who want to create an ADF-based user interface.

Interested parties:

Source code: https://github.com/AFaust/alfresco-better-trashmanagement/ 

OOTBee Support Tools: Upgrade to SDK 4.0 and support Alfresco Simple Modules (JAR) build artifact WITHOUT affecting / changing AMP artifact

Idea owner: Axel Faust (Younes REGAIEG‌)

Description: As part of the preparations of the release of version 1.1.0.0 of the OOTBee Support Tools addon, Younes REGAIEGsuggested adding support for Alfresco Simple Modules build artifacts. This project would pursue four objectives:

  1. Update the project to Alfresco SDK 4.0 to stay up-to-date with the current community dev tooling
  2. Ensure update to SDK 4.0 does not result in loss of compatibility with Alfresco 5.x (due to compilation / library changes)
  3. Add support for Alfresco SImple Module build artifacts in Repository and Share tier
  4. Ensure AMPs for Repository and Share tier remain structurally unchanged / unaffected by support for Alfresco Simple Module (e.g. config / script files should still be contained in AMP in exploded form and NOT inside of the JAR lib)

Interested parties:

Source code: https://github.com/OrderOfTheBee/ootbee-support-tools 

Make Alfresco v1 ReST API Great (Again / Finally / Someday?)

Idea owner: Axel Faust

Description: Considering the strategic importance Alfresco places on the v1 ReST API to support integration with out-of-process extensions and ADF-based (micro-)apps / Digital Workspace, it has laugable / annoying shortcomings in various areas. This project would work on creating PRs to try and address some of these, likely expanding the scope of some operations or merely just fixing known issues. Interested parties might want to add to the following list of "things the v1 ReST API should do better":

  • Support an aspectNames parameter in a multi-part node creation operation (e.g. upload via a form in the browser) to allow marker aspects to be specified
  • Support a variant of the multi-part node creation operation which supports creating multiple nodes (similar to the JSON variant)
  • Support a variant of the multi-part node creation operation which supports specifying a JSON-based node description in one part of the body (instead of the various fragmented parts)
  • Support a multi-part node update operation
  • Support multiple / alternative content streams apart from just cm:content in all node content operations
  • Support missing core types of properties, e.g. d:category (d:noderef?)
  • Support access to dictionary information for discovery / automatic client adaption (instead of all the hard-configuration / -coding currently done in ADF/ACA/DW)
  • Support child QName / XPath-based lookup as pure "relativePath" is unsuitable to support environments of different locales (e.g. path for data dictionary may be "Data Dictionary" in English, but is "Datenverzeichnis" in German, making ReST API useless e.g. for dynamically bootstrapping models via the dictionary)
  • ...

Interested parties: Martin Mueller

Source code / results:

Package deployment for Model Manager export

Idea owner: Bindu Wavell

Description: When you build a model with the out of the box model manager and export, you end up with a zip file that contains a model XML and a Share module component for the forms. Let’s start by documenting how to put these assets into an SDK project and then look at how to automate this. 

Prep work: use model manager to create a model. Design a form for the model. Export the model and look at the assets in the exploded zip. 

Interested parties:

R Package for Alfresco Content 

Idea owner: Roy Wetherall

Description: A simple R module that allows content to be uploaded and retrieved in R via the standard Alfresco REST API.  This would allow data in the form of content to be pulled into R and allow generated reports to be stored back into Alfresco as content.

Interested parties:

Source code: https://github.com/rwetherall/alfr

Photo map - Let’s improve solution from last virtual hackathon

Idea owner: Filip Bruska

Description: Following things can be done:

  • Update to higher SDK version (4 / 3.1)
  • Async action for Google Cloud Vision API
  • Improve ADF app

Interested parties: Alfresco team at Tieto

Source code: GitHub - FilipBruska/photo-map: Tieto Project for Alfresco Hackathon 2018 

Redundancy stopper

Idea owner: Filip Bruska

Description: Quite often the same files are distributed on several place in Alfresco repository. Let's imagine you need to update that fille. Will you do that on all places? It's annoying and it can be very error prone.

The main Idea is to get rid of the same binary files across repository. Let's see if we can utilize fingerprint feature available in Solr6 to identify those files.

Interested parties: Alfresco team at Tieto

Source code: GitHub - FilipBruska/redundancy-stopper: Tieto Project for Alfresco Hackathon 2019 

Alfresco Initializr

Idea owner: Toon Geens 

Description: A quickstart generator for Alfresco projects, based on Spring Initializr. The goal is to be able to quickly bootstrap an Alfresco project - targeting the Alfresco Maven SDK or the Alfred Gradle SDK - but a lot more interactive: pick Alfresco version, dependencies, examples and start.

Interested parties:

Source code: GitHub - xenit-eu/start.xenit.eu: A quickstart generator for Alfresco projects 

Google Cloud Storage Connector

Idea owner: Ana Gouveia

Description: An Alfresco connector for Google Cloud storage. The goal is to use GCS as a content store for alfresco, similar with what can be done with S3

Interested parties:

Source code: GitHub - amgouveia/alfresco-gcs-connector: Google Cloud Connector for Alfresco

Android/iOS app (React Native and Expo) to upload pics to Alfresco

Idea owner: Eva Vasques and Tiago Salvado

Description: Simple app that allows the user to upload pics stored in his Android/iOS device to Alfresco. Basic idea is to have:

  • Configuration (Alfresco and Account Settings)
  • Gallery View that allows to select multiple pictures to upload
  • Pictures that have been uploaded should be marked as such

Interested parties:

Source code: GitHub - evasques/alfresco-upload-app: Simple app that allows the user to upload pics stored in his ... 

Add SDK 3.1.0 and SDK 4.0.0 support to generator-alfresco (Yeoman generator)

Idea owner: Bindu Wavell

Description: SDK 3.1.0 and SDK 4.0.0 were recently released. We would like to add support for these SDKs to the Yeoman generator for Alfresco.

Interested parties:

  • Bindu Wavell

Source code: GitHub - binduwavell/generator-alfresco: A Yeomen generator based on the Alfresco all-in-one Maven a... 

<placeholder for project title>

Idea owner: Name

Description: 

Interested parties:

Source code:

Process Services

<placeholder for project title>

Idea owner: Name

Description: 

Interested parties:

Source code:

<placeholder for project title>

Idea owner: Name

Description: 

Interested parties:

Source code:

Application Development Framework

Facilitating Content Ingestion

Idea owner: Carlo Cavallieri‌, Leonardo Mattioli

Description: 

Starting from ADF components, we want to build a page to permit a rapid search and metadata typing of content. The new page will have 3 columns: the first with the list of contents that need metadata, the second with the preview of the selected document of the first column, the last with the metadata to be typed by user. This page will need a configuration query and the list and type of metadata to be inserted (potentially a subset of all metadata).

Interested parties:

  • Leonardo Mattioli
  • Carlo Cavallieri
  • Cristian Giuliani
  • Giulio Zattera
  • Jessica Foroni
  • Matteo Battisti

Source code: https://github.com/CASTGroup/hackathon19

Saved Searches component

Idea owner: Daniel Fernández

Description: 

We want to add the possibility to save an advanced search for later use in Alfresco and share it with others if desired. We will start with a classic Share functionality aiming to make an ADF component if time is enough.

Interested parties: Daniel Fernández‌, David Martos

Source code: https://github.com/keensoft/alfresco-saved-searches

Hipster ADF - Terminal Mode

Idea owner: mgrunenberg

Description: 

Navigating the document library with mouse clicks is too mainstream. Let's go back to the roots and just use a terminal inside the Alfresco Content App.

This should be a fun project and mainly focus using Angular for building a terminal interface and using the Alfresco Rest API.

Interested parties: mgrunenberg

Source code:

ADF Progressive App 

Idea owner: David Cano

Description: ADF app that works offline by making use of angular service workers. Turn on your router and enjoy your offline app!

Prep work: https://angular.io/guide/service-worker-intro

Interested parties:

Search Services

Language detection during indexing

Idea owner: Angel Borroy

Description: 

Currently, content language is set at Alfresco Repository by using client locale configuration. When indexing, SOLR takes this language from repository to perform the indexation. However, when working on cross-locale environments, some users are uploading content in a different language from client language settings. Having the right language identification will provide better results when searching.

Prep work: 

Detecting Languages During Indexing | Apache Solr Reference Guide 6.6 

Interested parties:

Angel Borroy

Tom Page

Source code:

Autodetect Language for Content with LangDetect Tool by aborroy · Pull Request #1 · aborroy/SearchSe... 

Blog post:

Alfresco Global Virtual Hack-a-thon – Spring 2019 | Programming and So 
 

0 REPLIES 0