undur / vermilingua-maven-plugin

A maven plugin to build WO applications and frameworks
5 stars 1 forks source link

Models don't appear to get "flattened" out of subdirectories #29

Open paulhoadley opened 1 year ago

paulhoadley commented 1 year ago

Part of the old flattenComponents functionality was pulling EOModels out of any folder structure as well. (Hence the option was poorly named: it flattened components and models. It's documented though: "Flatten only the WOComponents and EOModels from Resources or Components folders.")

vermilingua doesn't seem to do this: my models folder is preserved in the .woa bundle, even though component folder structure is dissolved. I don't know whether this affects a deployed app at runtime, though I suspect that it does.

hugithordarson commented 1 year ago

Ah, ok! I didn't know that. And yeah, I also find it likely that EOF doesn't dig into the resource hierarchy so models might have to be extracted and pulled to the root resources folder.

paulhoadley commented 1 year ago

This is going to be harder than it sounds. I presume here in PackageWOApplication, we're going to have to do some more work:

  if( Files.exists( sourceProject.woresourcesPath() ) ) {
    Util.copyContentsOfDirectoryToDirectory( sourceProject.woresourcesPath(), woa.woresourcesPath() );
  }

For reference, this is what wolifecycle will do. Say I have a folder src/main/woresources/models containing Foo.eomodeld (a directory) and Foo.eogen (for WOLips), then:

  1. Foo.eomodeld and Foo.eogen end up in Contents/Resources; and
  2. model, which is then empty, is deleted.

It would certainly be good to replicate that behaviour if we could. As an aside, though, .eogen is one of at least two file extensions that need not be copied to the bundle. (The other I can think of is component .api files.) To be clear, wolifecycle does copy these to the bundle, but they're useless in deployment. Should we special-case these (and any others?) for "global exclusion"—a topic for another ticket, to be sure, but it occurred to me here while considering how to special-case these models.

Finally, "stop doing that" (putting EO models in sub-folders) seems like a pretty reasonable resolution here, if you want to go that way. I do it because it keeps woresources tidy, and I know wolifecycle does the right thing, but it's not going to kill me to stop doing this.

hugithordarson commented 1 year ago

Thanks for looking at the current behaviour! Perhaps the folder copy method could just accept a suffix list that indicates "if you encounter a file/directory with any of these suffixes, copy to root, not a corresponding subfolder". Shouldn't be too hard.

I'm thinking empty directories can just be generally ignored/not copied (whether they're empty to begin with or after "flattening" occurs).

Exclusions for certain files or extensions would be a "nice to have" — but I don't think it's essential. I very much appreciate the plain simplicity of "everything in woresources will end up in Contents/Resources" as far as that's something we can keep. IIRC for example eogen files don't need to be in the same folder as their models, so technically they could exist outside woresources if an exclusion is absolutely desired, is that right?

I'm a little more worried about #34 since it seemingly makes anything other than src/main/resources unusable for EOF projects in development at the moment. Hadn't encountered it since I haven't used EOF in a while. But what I currently believe to be the optimal solution there would require a patched NSMavenProjectBundle (tiny class from ERFoundation) to be added to Wonder.

paulhoadley commented 1 year ago

I was going to try add another variant of Util.copyContentsOfDirectoryToDirectory() taking such a list, but we're not going to be able to do this as a Files.walk(), are we? The .eogen files will work, but when we hit an .eomodeld directory, we want to copy the whole directory. It will need something more like the copyContentsOfDirectoryToDirectoryFlatten() method, with a FileWalker, won't it? Trying to understand how this all works...

hugithordarson commented 1 year ago

Hmmm… Yes, I'd imagine that, i.e. it probably requires walkFileTree() with a FileVisitor.

paulhoadley commented 1 year ago

Oh yeah, FileVisitor. That's what I meant!