I believe if we are downloading the original jars from Apple, and patching them locally without redistributing the modular jars, we haven't changed the current state of affairs and ought to be in the clear. The erbundle jar is already on maven central, but I wasn't satisfied in that it did nothing to solve split package issues in wonder. So I noodled over this and this is the solution I have arrived at. Having the patches on central isn't even a requirement, it just reduces the friction of building the modular jars a bit. It might not seem like a lot to us wizards of maven and WO, but to people less familiar with one or both, it's more of a hurdle.
Think about it, starting from a clean slate macbook: You need to 1) install java, 2) install maven, 3) install git, 4) run the maven woinstaller, 5) git clone the modular project, 6) maven build and install the modular project. That's kinda a lot, and building patch jars too just adds more steps. A full WOLips product distribution solves 1-3 (https://github.com/wocommunity/wolips/packages/2358858). Maybe once we have womodular working, we can build a ui into wolips that can do 4-6 in one click.... because if the project is alive and moving again, there's going to be new versions of modular webobjects occasionally. Things like sun.security.action.* are going to continue to happen in the future and we will need to deploy patches to handle that. (https://www.whoacommunity.com/article/fdbb5913-aac2-47f5-82bd-c44f33bb3985)
On 11/8/25 8:49 PM, Hugi Thordarson wrote:
That's a daring plan :). I think the only iffy part is whether Maven Central will allow you to publish the jars based on fair use, do you know if they've ever done something ike that before? But honestly, the architectural cleanup you describe would be great either way. Look forward to following the effort! - hugiOn 8 Nov 2025, at 09:36, Ramsey Gurley <[email protected]> wrote: Sort of. The Schrag NSBundle added some API that was not original so that Wonder could do *something* but since I wasn't using that something, and I doubt anyone else is either. I didn't implement it. I stuck to the original NSBundle API. There are a few compile errors in wonder to address before we can make the switch. Also of note, the original NSBundle did caching on every path it loaded. I think that's probably YAGNI so I skipped that. If it turns out that we need to burn that memory to improve some performance, then it could always be added, but it seemed like a premature optimization to me. Since we are discussing it, I'll elaborate on my future plans for wonder a bit and some work I've been doing in the last month or two. In order to remove the split package issues, I've put together a plan to rebuild webobjects jars. To start, there is a project with patches for all the WO classes pulled out of wonder. So the NSArray, NSBundle, EOAttribute, all that stuff re-implemented in wonder is relocated into patch jars. Those patch jars are built as a single project, wopatches, mirroring the WO jars. foundation-patches for JavaFoundation, eocontrol-patches for JavaEOControl, and so on. To solve split package issues, JavaXML is completely removed in the process, and so is the WOWebServices stuff that nobody ever used. I'd still like to get the Java client stuff working if I can, but I haven't focused on that. Shout out to Dave A. I thought Java Client was cool too. Those patches are then maven-shaded into the WebObjects jars in a second project called womodular. Using the moditect maven plugin, I'm adding a module-info to all the original jars. These womodular jars become wonder-modular-foundation, wonder-modular-eocontrol, etc. The intention is to have the patches pushed to maven central, since maintaining working software is a clear fair use under copyright law, but the new modular jars are built locally only, to respect the original Apple license about distributing wo jars. Once that is done, I'll pull out all the patch classes from wonder, change wonder dependencies from JavaFoundation to wonder-modular-foundation, etc. This solves the split package issues. I'm planning to call this release Wonder 8: Infinite Wonder. I'm not an artist, so here's the AI slop logo :) https://i.imgur.com/wMMWZy8.jpeg Some things will probably need to die. Like WOOgnl. That is never being updated. My hope is we can replace it with Parsley. Wonder pulls in a lot of stuff. Sometimes it's an entire stack of stuff for a single wocomponent, and that stack isn't modular. So some things will need to be trimmed down to make this a reality. No offense to any original contributors. My ultimate goal is to make it possible for old projects to update to latest wonder, and migrate to latest java, without needing a ton of refactoring. I think we can do it, but there's no way to know until we try. On 11/6/25 10:08 PM, Hugi Thordarson wrote:Ramsey, I haven't had the time to check out your ERBundle work but it's certainly a great effort! Is it ready in the way that it could already replace ERFoundation and ERWebObjects in Wonder? And is it a drop-in replacement or anything specific I need to know or do in my projects before I try it out as a replacement? - hugiOn 5 Nov 2025, at 23:03, 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
