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! - hugi > On 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? >> >> - hugi >> >> >> >>> On 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
