Ah, right — only the patches! Sorry, misread your intent in the original post.
Yeah, agree it would be very nice to get that onto central. Like you, I'm a big fan of finding every way to reduce friction. - hugi > On 8 Nov 2025, at 23:32, Ramsey Gurley <[email protected]> wrote: > > I assume maven central would take it down if Apple asked them, but again, > it's not anything but the patches. Patches that have already been available > in wonder for a very long time on github. Patches that were sometimes > contributed to the project by people working at Apple. I think if Apple were > going to come after the patches, they would have done so a long long time ago. > > 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! >> >> - 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
