One thing to maybe consider related to project names. In order to run an sbt command for a subproject, you use sbt <subproject>/command. So for example, to build the CLI:
sbt daffodil-cli/packageBin If we remove the prefix from directory names, it makes sense to also remove the prefix from sbt subproject names. So the above becomes sbt cli/packageBin This seems perfectly reasonable. One minor concern is the daffodil-test project becomes just "test", which is perhaps a bit confusing since "sbt test" is a normal and very common command. So to run tests in just the test subproject, you would run sbt test/test That isn't awful, but does a bit weird? Maybe a new name for the "test" project would also make this more clear, and could also describe what these tests are more about? Similar to test-ibm1 or test-stdLayout? On 10/5/20 11:59 AM, Steve Lawrence wrote: > I'm fine with just removing it completely. As I said, I don't think the > reasons I listed are strong reasons for keeping a prefix. > > On 10/5/20 11:36 AM, Beckerle, Mike wrote: >> A shorter prefix like just "daf-" would bother me less. >> >> It literally becomes screen-real-estate using IDEs because the project trees >> extend from the left of the screen, and they just go too far right before >> you get to the actual files contained. >> ________________________________ >> From: Steve Lawrence <slawre...@apache.org> >> Sent: Monday, October 5, 2020 11:25 AM >> To: dev@daffodil.apache.org <dev@daffodil.apache.org> >> Subject: Re: Subproject names proposed for discussion >> >> Your suggestion seems reasonable to me. Adds a few more top level >> directories by splitting lib and schema-compiler which I'm not a huge >> fan of, but it is logical and reduces the size the lib jars. >> >> The one thing I like about the "daffodil-" prefix is it makes the code >> directories stand out a bit more. For example, the containers, project, >> target, tutorials, etc. directories or more about infrastructure. It >> makes it eaiser to ignore those when scanning through directories (of >> which this change would add quite a few more). I think this is also >> pretty common among java projects, but I don't think they all do it. But >> I'm not sure if either of those are strong reasons to keep it. We have >> had problems with long paths in the past on windows, so removing the >> prefix could help with that... >> >> >> On 10/5/20 11:11 AM, Beckerle, Mike wrote: >>> Some reponses inline below >>> >>> ________________________________ >>> From: Steve Lawrence <slawre...@apache.org> >>> Sent: Monday, October 5, 2020 10:48 AM >>> To: dev@daffodil.apache.org <dev@daffodil.apache.org> >>> Subject: Re: Subproject names proposed for discussion >>> >>> A handful of unrelated thoughts, maybe overthinking things and I don't >>> feel strongly about anything below, but renaming is always pain so it'd >>> be nice to ensure we have something future proof. >>> >>> 1) Is there any benefit organizationally to having all backends being in >>> the same directory? >>> >>> I think the opposite. I think they should be separate and top level in >>> fact, so that we're not tied to say, sbt build system as we are now. >>> >>> 2) From a sorting perspective, it'd be nice if the scala projects were >>> together, so having it be scala-parser and scala-unparser rather than >>> parser-scala and unparser-scala has advantages. >>> Agree. >>> >>> 3) Maybe the scala parser/unparser should be considered the same "scala" >>> runtime, and so parser/unparser should be subdirectories of a >>> "daffodil-backend-scala" subdirectory? >>> >>> There is no reason to keep the scala parser and unparser separate. >>> >>> That was done at one time because compilation time was so long that we >>> wanted to be able to close the unparser project (on eclipse) and not be >>> recompiling it if just doing work involving the parser. This is less an >>> issue now. >>> >>> 4) Is there even a benefit to separating parser/unparser into separatejars? >>> There's so much shared logic between the two, and there's even a >>> bunch of unparsing stuff in the parser jar. Should we just combine them >>> under the same backend? >>> >>> Yes, but one step at a time. First I would do the renaming. I'd do the >>> merging of parser/unparser into one lib separately. >>> >>> Taking all of the above into account, perhaps something like this: >>> >>> ... >>> |-- daffodil-backends >>> >>> I would not add the backends parent. >>> >>> daffodil-backend-scala >>> >>> | |-- daffodil-scala >>> | | `-- src >>> | `-- daffodil-generator-c >>> >>> I would call the above daffodil-c-generator to be consistent. It is >>> important that this is identified as a generator. >>> >>> While we're at it, can't we drop the "daffodil-" prefix on all these? >>> >>> | `-- src >>> |-- daffodil-lib >>> | `-- src >>> |-- daffodil-schema-compiler >>> >>> This is problematic because each back-end is going to have its part of the >>> schema compiler that converts grammar objects into back-end primitives code >>> by generation of code that calls libraries. >>> >>> This should be distinguished from the 100% static code part of the back-end >>> which is statically written and testable independently. >>> >>> | `-- src >>> ... >>> >>> 5) Is there something better than "backend" for describing these. I >>> can't think of anything. Does the DFDL spec have a concept of this? >>> >>> There is no concept of this in the DFDL spec to borrow from. >>> >>> 6) Are there any benefits to using "codenames". My thinking is maybe >>> someday there could be multiple "scala" backends with different >>> goals/extensions, and so "daffodil-scala" is too generic. Codenames >>> would be more like what we have today, except real code names might be >>> easier to remember than "runtime1" and "runtime2". Disadvantage is >>> there's less discoverability, but a README could be added with short >>> descriptions about what the backends try to accomplish. Not sure I like >>> this, but thought I'd throw it out there. >>> >>> Naming backends after "famous runtimes" as in marathons and other road >>> races, .... except those just end up being named after places or people. >>> Might as well use the name or home-town of the person who wrote the first >>> line of code in whatever backend it is. >>> >>> Personally, I find separating them into backend scala, vs. backend >>> c-generator works fine, and if it splits below that, numbering will be >>> sufficient. >>> >>> My summary: >>> >>> daffodil >>> backend-scala-schema-compiler >>> core-schema-compiler >>> backend-c-generator-schema-compiler >>> lib >>> backend-scala-parser-lib >>> backend-scala-unparser-lib >>> backend-c-lib >>> tdml-lib >>> tdml-processor >>> ..... >>> >>> >>> >>> >>> >>> >>> On 10/5/20 10:23 AM, Beckerle, Mike wrote: >>>> +1 from me. >>>> >>>> ________________________________ >>>> From: Interrante, John A (GE Research, US) <inter...@research.ge.com> >>>> Sent: Monday, October 5, 2020 9:28 AM >>>> To: dev@daffodil.apache.org <dev@daffodil.apache.org> >>>> Subject: Subproject names proposed for discussion >>>> >>>> Steve Lawrence and I would like to bring a topic to the dev list for >>>> discussion since not everyone is paying attention to the review of my >>>> runtime2 push request. Steve suggested, and I agree, that renaming some >>>> of the Daffodil subprojects might make their meanings more obvious to >>>> newcomer devs. If we do rename some subprojects after discussing it on >>>> this list, we will do it immediately in its own pull request since mixing >>>> changes with renames makes it difficult to see which changes are just >>>> renames instead of actual changes. >>>> >>>> What do devs think about us renaming some subprojects like this? >>>> >>>> rename daffodil-core to daffodil-schema-compiler >>>> leave daffodil-lib alone >>>> rename daffodil-runtime1 to daffodil-backend-parser-scala >>>> rename daffodil-runtime1-unparser to daffodil-backend-unparser-scala >>>> rename daffodil-runtime2 to daffodil-backend-generator-c >>>> >>>> >>> >>> >>> >> >> >
