Thank you for the detailed information. We don’t have localized resources. But it sounds very interesting. I will take a look.
Thank you again. Ricardo Parada > > On Nov 5, 2025, at 6:04 PM, Ramsey Gurley <[email protected]> wrote: > > WebObjects has this thing called NSBundle. And everyone is vaguely familiar > with it, because whenever your app isn't working, it's probably because of > NSBundle. > > NSBundle is not actually a bad idea. It's an abstraction layer between your > application and the file system where your bundle resources are located. So > from the app's perspective, you just have to ask NSBundle for ClaimHome.wo, > and it finds it, or a localized version of it. You don't have to know the > path is actually Components/NonLocalized.lproj/ClaimHome.wo or whatever, it > does that part for you. > > The problem is, you actually need to be able to extend the NSBundle yourself > to handle any type of new bundle layouts. Yet WebObjects went EOL in 2008. > NSBundle is written as some really crufty Java 1.5 spaghetti code... because > that's what was available when it was written. It supports a few bundle > layouts already. CFBundles, NSBundles, XCode projects, but conspicuously > missing, is a Maven bundle. > > Mike Schrag and probably some others, modified NSBundle to work with maven > projects and added ERWebObjects and ERFoundation to project wonder to enable > that. It's essentially the same spaghetti code, but with a bundle factory > included where you can inject your own bundle handlers with properties. It's > a product of Apple, donated by Apple, no source code, no real license, > documentation, or anything. It's a little murky. > > So around Jan/Feb of this year, with the goal of getting Project Wonder up > onto Maven central, I took it upon myself to rewrite NSBundle. It's current > form is on github under the erbundles project. It is completely rewritten > using nice things available since Java 8 like the java.nio.FileSystem. Which > means, there's no spaghetti code around whether your files are located in a > folder structure or in a jar. Using the java.util.ServiceLoader, it can load > custom NSBundle adaptors that you can produce yourself by implementing a > single interface. It has implementations for JarBundles, CFBundles, and in a > separate project which you can load conditionally with maven profiles, one > that handles Maven bundles. The Maven NSBundle just reads your pom.xml file > to see where you've located resources, and looks there. No special > configuration involved. > > It turns out that using java.nio.FileSystem was a good idea, because it > should also be able to read the new hotness which are Java Runtime images > with a jrt:/ url too. I've already gotten it working with a new unreleased > Jigsaw bundle adaptor. I want to try to get a simple woapp running as a > GraalVM native image too, which, theoretically, it should be able to handle. > > Back to the question about flattenComponents, I believe if you flatten, and > you have localized components, you're going to lose the localizations. I > could be wrong, but that's what it sounds like. The NSBundle you're probably > using is going to look in the jar under /Resources and /WebServerResources > for stuff. If you do have localization and you want to try it out, you could > try making a custom bundle adaptor for erbundles to handle your custom bundle > layout in the jar without flattening. > > Ramsey > >> On 11/6/25 5:04 AM, Ricardo Parada via Webobjects-dev wrote: >> Hello all, >> >> I’m trying to figure out why some components render no html. >> >> The component lives in the project folder under >> Components/ClaimsProfessional/ClaimHome/ClaimHome.wo >> >> Prior to maven conversion I can see the component is copied to a build >> folder, something like this >> …/build/ClaimComponents.framework/Resources/ClaimHome.wo >> >> And when I debug in Eclipse I see the WOComponentDefinition constructor gets >> called with the path to that file. >> >> In other words it seems like *all* components have been put together under >> Resources folder after it builds the framework which is okay with me. >> >> Now, when I build with maven and look inside the jar file for the framework >> where the component resides I noticed that the components are not flattened. >> The hierarchy of folders is preserved, e.g. >> Resources/ClaimsProfessional/ClaimHome/ClaimHome.wo. >> >> Anyways, I’m not sure if that is the reason why some components render no >> html but my guess is that it is because otherwise WebObjects would have to >> do a recursive search. >> >> If anyone knows whether it is okay for maven to preserve the hierarchy of >> folders under Components or whether it is supposed to copy all components >> and put them together under Resources please let me know. >> >> Thank you >> Ricardo Parada
