We only discussed shortening the daffodil- prefix to daf-, not eliminating it. We wrote up that discussion in https://issues.apache.org/jira/browse/DAFFODIL-2406. We put off changing any daffodil- module names until Daffodil's 4.0.0 release, however, because changing the module names would be quite disruptive. All schemas' and users' build.sbt that pull in daffodil for testing would need to change not only version numbers, but also jar names. Arguably, longer names that say "daffodil" is good for the jars since we can see a list of jar files in a directory and know which jars come from Apache Daffodil modules and which jars come from external libraries. The "daffodil" in names is only clumsy for developers who have to type those names fairly often.
We also have a wishlist for a sbt plugin to simplify all schemas' and users' build.sbt. I think it's either https://issues.apache.org/jira/browse/DAFFODIL-1679 or another issue. Having the plugin would make changing module names less disruptive even after 4.0.0 comes out. Changing daffodil-runtime2's module name won't affect any schemas or users, however, so it's fine to rename it now. I'm fine with "daffodil-codegen-c" or even "codegen-c" if anyone else thinks we should drop the daffodil- prefix completely. Let's hear more opinions. John -----Original Message----- From: Mike Beckerle <[email protected]> Sent: Friday, February 3, 2023 3:03 PM To: [email protected] Subject: EXT: Re: Rename daffodil-runtime2 to daffodil-generator-c I suggest "codegen-c" as the name and convention. I don't think the daffodil- prefix helps really and just makes all the names long. (Somewhere we had a discussion of eliminating all the daffodil- prefixes. Can't recall why we didn't. ) On Fri, Feb 3, 2023 at 5:31 PM Interrante, John A (GE Research, US) < [email protected]> wrote: > Eventually Daffodil will support multiple code generators. I have > already sent a pull request to generalize Daffodil's CLI so we can > call "daffodil generate <lang>" for additional languages. Now I want > to discuss renaming daffodil-runtime2's module, package, and class > names to new names that are more similar to and yet distinguishable from > other code generators' > modules, packages, and classes. > > Daffodil's developers envisioned that Daffodil would have multiple > backends/runtimes so they used "runtime2" as a placeholder name for > whatever the next backend would be. That turned out to be a C code > generator, but we still named it "daffodil-runtime2" and used "[Rr]untime2" > in many places within it. However, the use of "runtime2" as a name > has to stop if we want Daffodil to generate code for additional > languages. We can't have "runtime2", "runtime3", etc., since users > will have no idea which runtimes correspond to which languages. > > As I see it, there are two choices for the C code generator's new > module name. We can say 1) daffodil-c-generator or we can say 2) > daffodil-generator-c, that is, "daffodil-<language>-generator" or > "daffodil-generator-<language>". I originally was going to say > daffodil-c-generator like how I say "Daffodil's C code generator" in > English but I've rethought that and realized that > daffodil-generator-<language> will group multiple code generators > together, encouraging developers to update them together and > eventually move any common code/TDML tests to "daffodil-generator". > If developers agree, I'll start work on the necessary > module/package/class/wiki changes and send a pull request (after the > OSGi refactoring if it's going to be merged very soon). > > John
