Just committed all of the stuff I've been doing to Wonder's main branch, less confusing than having all of those separate PRs.
I also deployed ERFoundation-1.1 to maven.wocommunity.org, which fixes that check for the project's <nature>. It's my birthday so I do what I want to :). Here's a 2 minute video that shows how little "formalities" should now be required for WO/Wonder to work, we start with an absolutely plain java project, no WOLips, no bundle generation or /build folder, just plain WO and Wonder. https://www.youtube.com/watch?v=iDQcMVRUhyk Cheers, - hugi > On 9 Nov 2025, at 07:40, Hugi Thordarson <[email protected]> wrote: > > Thanks for trying this out Ricardo. Sorry, one thing I should have mentioned, > for bundleless to work (generate bundles off and no build folder), > you need to have the old maven nature in the .project file ( > <nature>org.maven.ide.eclipse.maven2Nature</nature> ). > > Fixed in a different PR: https://github.com/wocommunity/wonder/issues/1029 . > > Cheers, > - hugi > > > >> On 9 Nov 2025, at 03:39, Ricardo Parada <[email protected]> wrote: >> >> Hugi, >> >> If I turn off the “Generate bundles” in WOLips : Build, and delete the build >> folder then I get back the exception when I run the application. I’m using >> the java launch configuration. >> >> It does not matter if I set the Working directory as you suggested with >> ${working_dir_loc_WOLips:MyApp} and even if I add >> -DNSProjectBundleEnabled=true in the VM arguments. >> >> However, if I turn the “Generate bundles” option back on and make sure it >> generates the build folder by doing clean and build automatically, set the >> Working directory to ${working_dir_loc_WOLips:MyApp} then it works. No need >> to set -DNSProjectBundleEnabled=true in the VM arguments. It does not seem >> to have an effect. >> >> Then if I remove your ERXApplication changes then the exception comes back. >> >> Then I put your changes back and everything works again. >> >> So your commits definitely fix the problem but I can’t say that bundleless >> works. >> >> Were your commits supposed to make bundleless work? Where bundleless means >> no build folder and the Generate bundles option turned off. >> >> Thank you very much, >> Ricardo >> >> >>> >>> On Nov 8, 2025, at 9:43 PM, Ricardo Parada <[email protected]> wrote: >>> >>> I’ll do more testing and then comment on the pull request. >>> >>> :-) >>> >>> Thank you >>>> >>>> On Nov 8, 2025, at 5:58 PM, Hugi Thordarson <[email protected]> wrote: >>>> >>>> The project layout looks fine at first sight, so I can't think of what's >>>> causing your application to fail in WOApplication launch/bundle-mode. >>>> >>>> But glad to hear that you're up and running! And that the fixes to >>>> bundleless development work. I might just count that as a review and merge >>>> into main :). >>>> >>>> - hugi >>>> >>>> >>>> >>>>> On 8 Nov 2025, at 22:07, Ricardo Parada <[email protected]> wrote: >>>>> >>>>> I’m gonna summarize here. >>>>> >>>>> >>>>>> >>>>>> On Nov 8, 2025, at 3:03 AM, Hugi Thordarson <[email protected]> wrote: >>>>>> >>>>>> - Does your ".project" file contain >>>>>> <nature>org.maven.ide.eclipse.maven2Nature</nature> — and a WOLips >>>>>> builder? >>>>>> - Does your application project contain a "build" folder on disk? >>>>>> (should be getting generated by WOLips). And does it look pretty much >>>>>> like an application bundle or do you see something missing? >>>>> >>>>> Yes, it has a build folder as shown below: >>>>> >>>>> % ls build >>>>> Phynance.woa >>>>> % ls build/Phynance.woa >>>>> Contents >>>>> % ls build/Phynance.woa/Contents >>>>> Info.plist Resources WebServerResources >>>>> >>>>>> - Does woproject/resources.include.patternset properly define your >>>>>> resources? (kind of pointless to ask since your build works with maven >>>>>> so it should be fine — but can't hurt to ask) >>>>> >>>>> It is as follows: >>>>> >>>>> % cat woproject/resources.include.patternset >>>>> Components/**/*.wo/**/* >>>>> Components/**/*.api >>>>> Resources/**/*% >>>>> also In my build.properties I have classes.dir=target/classes. It used to >>>>> be set to “bin”. Do you think it hay has any effect on this? >>>>> >>>>> >>>>>> >>>>>> Launching as a WOApplication should work if you have "generate bundles" >>>>>> enabled. But if you launch as a "java application" (not a >>>>>> WOApplication), you will see the error you described unless you: >>>>>> 1. Set the working directory for the Debug/Run configuration to >>>>>> ${working_dir_loc_WOLips:SW} and >>>>>> 2. Pass in the VM argument -DNSProjectBundleEnabled=true >>>>>> >>>>> >>>>> This worked for my java launch configuration. And I think that is what I >>>>> had when things used to work. When I started from scratch I recreated the >>>>> launch configurations from zero and forgot I was using this. >>>>> >>>>> In my case I set working directory to: >>>>> >>>>> ${working_dir_loc_WOLips:MyApp >>>>> >>>>> This works!!! >>>>> >>>>> >>>>>> -- >>>>>> >>>>>> "Generate bundles" does pretty much what it says on the tin. It >>>>>> activates the WOLips builder, which generates that "build" folder in the >>>>>> root of your project, containing a bundle that WOLips will constantly >>>>>> keep "built" as you make changes. Your WO application will then locate >>>>>> everything from there. >>>>>> >>>>>> The nicer alternative is bundleless development, meaning no generated >>>>>> build-folder/bundles and resources get located directly in the project >>>>>> rather than from the fake bundle in the "build" folder. >>>>>> >>>>>> Bundleles is faster, simpler and better. But there's a bug in project >>>>>> Wonder which prevents you from using bundleless with it when using maven >>>>>> ( https://github.com/wocommunity/wonder/issues/1025 ). >>>>>> It's fixed by one of the patches I submitted yesterday, those patches >>>>>> exactly being meant to ease life for those migrating to maven (everyone >>>>>> hits these problems in the first steps, and I think we should really fix >>>>>> those). >>>>> >>>>> I incorporated those two commits into our fork of Wonder. >>>>> >>>>> We are using Wonder 7.3 which we converted a while ago to use slf4j >>>>> throughout. That was a significant effort. >>>>> >>>>> And we also upgraded jar files in it that had been flagged by the >>>>> security scanning software as having vulnerabilities. >>>>> >>>>> Anyways, I just added your two commits to that version and it fixes the >>>>> problem. >>>>> >>>>> >>>>>> Cheers, >>>>>> - hugi >>>> >
