[ala-portal] Purpose of generic repositories
Hey,
I'm working on an attempt to deploy a living atlas at Royal Botanic Gardens, Kew and I have some confusion around the use cases of the repositories that are prefixed with `generic'.
As part of the demo deployment that can be installed via Ansible the collectory component is the one run by the mainline Atlas of Living Australia.
https://github.com/AtlasOfLivingAustralia/ala-collectory
However, if you leave the variable undefined then it ends up being assigned the name of the generic version.
artifactId: "{{ collectory_app | default('generic-collectory') }}"
Looking at this repository it seem almost identicial but not the same.
https://github.com/AtlasOfLivingAustralia/generic-collectory
In the case of the collectory, my understanding is that the actual work is done with a plugin that both packages make use of so aside from it being a little behind there isn't a vast difference between the generic package and the... official (for lack of a better term) one.
Is there some advice on which should be modified in a new deployment? The NBN Atlas has only forked `ala-collectory' but the atlas that's part of the Swedish Biodiversity Data Infrastructure (SBDI) has forked both.
Does this advice generalise to other repositories listed as generic?
Thanks,
Alex -- Lead Science App Developer Digital Revolution Royal Botanic Gardens, Kew
________________________________
The Royal Botanic Gardens, Kew is a non-departmental public body with exempt charitable status, whose principal place of business is at Royal Botanic Gardens, Kew, Richmond, Surrey TW9 3AE, United Kingdom.
The information contained in this email and any attachments is intended solely for the addressee(s) and may contain confidential or legally privileged information. If you have received this message in error, please return it immediately and permanently delete it. Do not use, copy or disclose the information contained in this email or in any attachment.
Any views expressed in this email do not necessarily reflect the opinions of RBG Kew.
Any files attached to this email have been inspected with virus detection software by RBG Kew before transmission, however you should carry out your own virus checks before opening any attachments. RBG Kew accepts no liability for any loss or damage which may be caused by software viruses.
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
Dear Alex:
First of all, welcome to our community Alex. You'll receive in short an invitation to slack where we discuss these topics.
Meanwhile, I'll try to respond you.
Many LA portals use directory the ala generated artifacts (ala-collectory, ala-hub, ala-bie, and so on). If you don't need to customized grails code or similar, I recommend to follow this option. In Spain we are currently using these repos/artifacts.
Using these approach you can also customize your portal via a custom branding (html/css/js).
Some LA portals use some customizations for the collectory, and hubs, and use some custom fork of the generic-collectory and/or other modules.
We did this in the past, but preferred to come back to the ala artifacts and to generalize our code customizations and send back to ALA code base.
Both options use the collectory-plugin that is where the main collectory code is and is shared (similar occurs with biocache-hubs, bie-plugin,...).
In summary, to start I recommend the first option without any doubt.
Also I recommend to have a look to this new toolkit: https://github.com/living-atlases/la-toolkit that tries to facilitate all these tasks while using the ala-install & ansible and gives initial setup recommendations. You can test a non-functional demo here: https://toolkit-demo.l-a.site/ or a presentation with screenscats here: https://datos.gbif.es/others/la-toolkit-gbif-presentation-2021.html
Please don't hesitate to ask us any other similar question (ideally via slack).
BR,
Vicente J. Ruiz Jurado Technical Coordinator - Living Atlases Community
El 8/10/21 a las 18:11, Alex Melbourne escribió:
Hey,
I'm working on an attempt to deploy a living atlas at Royal Botanic Gardens, Kew and I have some confusion around the use cases of the repositories that are prefixed with `generic'.
As part of the demo deployment that can be installed via Ansible the collectory component is the one run by the mainline Atlas of Living Australia.
https://github.com/AtlasOfLivingAustralia/ala-collectory https://github.com/AtlasOfLivingAustralia/ala-collectory
However, if you leave the variable undefined then it ends up being assigned the name of the generic version.
artifactId: "{{ collectory_app | default('generic-collectory') }}"
Looking at this repository it seem almost identicial but not the same.
https://github.com/AtlasOfLivingAustralia/generic-collectory https://github.com/AtlasOfLivingAustralia/generic-collectory
In the case of the collectory, my understanding is that the actual work is done with a plugin that both packages make use of so aside from it being a little behind there isn't a vast difference between the generic package and the... official (for lack of a better term) one.
Is there some advice on which should be modified in a new deployment? The NBN Atlas has only forked `ala-collectory' but the atlas that's part of the Swedish Biodiversity Data Infrastructure (SBDI) has forked both.
Does this advice generalise to other repositories listed as generic?
Thanks,
Alex
Lead Science App Developer Digital Revolution Royal Botanic Gardens, Kew
The Royal Botanic Gardens, Kew is a non-departmental public body with exempt charitable status, whose principal place of business is at Royal Botanic Gardens, Kew, Richmond, Surrey TW9 3AE, United Kingdom.
The information contained in this email and any attachments is intended solely for the addressee(s) and may contain confidential or legally privileged information. If you have received this message in error, please return it immediately and permanently delete it. Do not use, copy or disclose the information contained in this email or in any attachment.
Any views expressed in this email do not necessarily reflect the opinions of RBG Kew.
Any files attached to this email have been inspected with virus detection software by RBG Kew before transmission, however you should carry out your own virus checks before opening any attachments. RBG Kew accepts no liability for any loss or damage which may be caused by software viruses.
*Disclaimer*
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by *Mimecast Ltd*, an innovator in Software as a Service (SaaS) for business. Providing a *safer* and *more useful* place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here http://www.mimecast.com/products/.
ALA-Portal mailing list ALA-Portal@lists.gbif.org https://lists.gbif.org/mailman/listinfo/ala-portal
participants (2)
-
Alex Melbourne
-
Vicente J. Ruiz Jurado