Enable lang selection without need for 'available-langs.properties'

[awoods]

Related PRs:

• Ensure RDF files are assembled into language-specific directories VIVO-languages#57
• Ensure RDF files are assembled into language-specific directories Vitro-languages#24
• Enable lang selection without need for 'available-langs.properties' VIVO#174

Resolves: https://jira.lyrasis.org/browse/VIVO-1848

What does this pull request do?

This pull-request, in combination with the three other pull-requests noted below, does the following:

• makes languages available to be enabled without the need for the previous 'available-langs.properties' file

How should this be tested?

Use the same tests as those documented in the previous pull-request: #160

Interested parties

@VIVO-project/vivo-committers

[gneissone]

Works as intended. Confirmed languages are deployed to the home directory. Confirmed only the selected languages are loaded into the application during runtime. Enabling a language that was not deployed throws a warning at startup before running as normal, as expected.

As noted in Slack, this PR does increase the complexity of the home directory structure. Example of new directory:

rdf
├── core
│   ├── abox
│   │   ├── filegraph
│   │   └── firsttime
│   ├── applicationMetadata
│   │   └── firsttime
│   ├── auth
│   │   └── everytime
│   ├── display
│   │   ├── everytime
│   │   └── firsttime
│   ├── displayDisplay
│   │   └── everytime
│   ├── displayTbox
│   │   └── everytime
│   └── tbox
│       ├── filegraph
│       └── firsttime
├── en_US
│   ├── applicationMetadata
│   │   └── everytime
│   ├── display
│   │   └── everytime
│   └── tbox
│       └── everytime

Since we are always deploying files from the language repo dependencies now, we should be able to do away with the core directory at some point [Edit- perhaps not since there will still probably be language-agnostic RDF to be loaded, but the core files could live within the language dependencies only, not here as well]. One additional consequence of this new directory structure is that if people were overwriting files now in the core directory during deployment using a third tier, they will likely have to rearrange the directory structure in their third tier to match.

For clarity, I think it would be preferable that until the files are removed completely, the rdf files included outside the VIVO and Vitro language dependencies are put into the rdf/core directory within the VIVO and Vitro repos themselves, rather than reorganizing the files during the build.

[awoods]

@gneissone : to be clear, for example, are you suggesting the changes to home/src/main/assembly/home.xml be reverted, and the files in home/src/main/resources/rdf be moved into a new directory: home/src/main/resources/rdf/core?

[gneissone]

@gneissone : to be clear, for example, are you suggesting the changes to home/src/main/assembly/home.xml be reverted, and the files in home/src/main/resources/rdf be moved into a new directory: home/src/main/resources/rdf/core?

Yes, exactly. And likewise in VIVO. I think it makes more sense than the files mysteriously moving into a new directory during mvn install.

[awoods]

The same trickier is also happening in VIVO-languages:
https://github.com/vivo-project/VIVO-languages/pull/57/files

Are you comfortable with that?

[gneissone]

Yeah, I think if it's changed here and in VIVO it should also be changed in VIVO-languages.
I guess the overall question is if it will be more obvious for people with existing installer directories (3rd tier) to add the maven black magic to their home.xml file or create a new core directory. It seems more logical to me that the contents of home/src/main/resources are dropped wholesale into home, rather than this specific directory getting special treatment.

[awoods]

@gneissone : I am happy to make the change of moving the location of files around inside the resources directory... if you/we are generally in favor of the more complex rdf directory structure being introduced in this PR.

[gneissone]

It's fine with me. I guess there are a few alternatives I can think of...

1. Continue to put all language-agnostic/file system files into a core directory, load all of these every time. Return to old file structure otherwise and use filtering logic on these.
2. Return to old directory structure, filter out all files with an underscore if there isn't an enabled language suffix following the underscore.
3. Return to old directory structure, filter out all files with a valid locale (based on Java library) that are not enabled.

I suppose the least disruptive would be options 2 or 3 since custom installer overlays would not need to be reorganized to upgrade. Will be interested to hear other opinions because it's not a big deal to me.

[awoods]

Thanks, @gneissone . I appreciate your articulation of options.
I will wait to hear from others: @vivo-project/vivo-committers ... the community.

[gneissone]

The new directory structure works for me

rdf
├── abox
│   ├── filegraph
│   └── firsttime
├── applicationMetadata
│   └── firsttime
├── auth
│   └── everytime
├── display
│   ├── everytime
│   └── firsttime
├── displayDisplay
│   └── everytime
├── displayTbox
│   └── everytime
├── i18n
│   ├── de_DE
│   │   ├── applicationMetadata
│   │   │   └── firsttime
│   │   ├── display
│   │   │   └── firsttime
│   │   └── tbox
│   │       ├── everytime
│   │       ├── filegraph
│   │       └── firsttime
└── tbox
    ├── filegraph
    └── firsttime

I have concerns about receiving missing string errors on initial startup and with annotations being in the 'everytime' directory, but those both appear to have been introduced in previous commits and are unrelated to this. Additionally, we need to be sure that files in the home directory that have been moved at some point in the i18n sprints (e.g. https://github.com/vivo-project/VIVO/blob/master/home/src/main/resources/rdf/display/firsttime/aboutPage.n3) are well-documented in the upgrade documentation.