I think the concern was the "daffodil-" prefix is a bit long and a bit unnecessary, but it is potentially nice since it helps distinguish code related subprojects from non-code (e.g. tests, infrastructure). So "daf-" is a decent middle ground.
I think the "daf-" was suggested for me, and I don't feel strong about it, so I'm not against dropping the daf- prefix entirely if others don't like it. On 10/7/20 9:16 AM, john wass wrote: > What was the reasoning on the daf- prefix again? > > I looked back through but didnt see what the value add of the prefix was. > > > On Wed, Oct 7, 2020 at 9:09 AM Interrante, John A (GE Research, US) < > inter...@research.ge.com> wrote: > >> I've created an issue (https://issues.apache.org/jira/browse/DAFFODIL-2406) >> to rename Daffodil subprojects for better clarity. I'd like to ask devs if >> the issue has everyone's consensus and ask for a volunteer to perform the >> renaming since I'm going to be refactoring classes and changing code in my >> own pull request (daffodil-2202-runtime2) for at least the next few days. >> >> Does this proposal look acceptable to everyone? >> Phase 1 >> >> * containers >> * daf-backend-c-generator (ignore - not in main yet, but will be later) >> * daf-backend-scala-parser >> * daf-backend-scala -unparser >> * daf-cli >> * daf-io >> * daf-lib >> * daf-macro-lib >> * daf-propgen >> * daf-sapi >> * daf-schema-compiler (was daffodil-core) >> * daf-tdml-lib >> * daf-tdml-processor >> * project >> * test-suite-daf >> * test-suite-ibm >> * test-suite-std >> * tutorials >> Phase 2 >> Merge daf-backend-scala-parser and daf-backend-scala-unparser together >> into daf-backend-scala. >> >
