Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release prep for Goldstandard paper #55

Open
wants to merge 21 commits into
base: master
Choose a base branch
from
Open

Conversation

hlapp
Copy link
Member

@hlapp hlapp commented Apr 26, 2018

No description provided.

hlapp and others added 21 commits March 8, 2018 19:56
From Hong:
> This version supports output the results as a csv file and also output a
> version file writeCSVandVersionFiles.
The Ontology folder in v0.1.0-alpha contains the older fish glossaries
used for processing fish files before, and it was not used in the
SemanticCharaParser experiment for the Goldstandard.
The 4.x release series should have been the one active while this was
developed.
Converting from one type to an incompatible one is no longer allowed in
Java 1.8. Here, a list of FormalConcept (an interface) instances are not
known to the compiler to be instances of Quality at runtime, and so the
conversion is disallowed.

The fix here is simple - convert to a non-generic list type first, and then
back to the desired generics template type.
The code compiles but it may miss resources that need to be packaged.
Although the POM for a Maven-based build of the phenoscapeII subproject is
left in place here, the overall gains from it are minimal, for several
reasons:
- To run the application, both subproject JARs need to be built, and they
  reuse some of the same dependencies. Building only one through Maven and
  the other not yields little to no benefit for the overall list of
  dependencies to store and manage.
- To run the application, all the dependency JARs are still needed at runtime.
  We could instruct Maven to fold each dependency along with the local
  classes all into a single self-contained JAR, but that would require to
  build everything through maven to be really effedctive. And it would
  also require producing platform-specific packages.
- Our objective here is not to create a distributable and executable
  self-contained application, but to have a mechanism to build and run
  the application reproducibly and platform-independently.

Hence, we're going back to simply using the jdk tools to compile and
package, and require platform-specific dependencies to be provided by the
user.
Also adds a reference to this document into the README.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants